I do own the rain sensor but am not using because I have another weather safety device and until the firmware and driver are a bit more solid I'm keeping it off. In the code the default rain check interval is 30 seconds. Because the ASCOM logs (0.5.2.3) reveal that ShutterState is asked for and received once a SECOND!!!! throughout the night I decided to just see how changing raincheck interval impacts that this morning. (After a fine good night!). In the firmware code the notes say clearly that setting rain check interval at 0 turns it off.
So using the ASCOM driver Shutter setup I set it to 0 and then opened the shutter. The result was quite interesting.. The shutter did open but it's speed was probably 1/4th of normal!! After the shutter was open I set the rain check interval back to 30 sec and closed the shutter. The speed was back to normal.
I have said many times in this forum before that given the occasional munging of sent commands that the shutter state logging of once a second is likely the cause of quite a bit of mischief. Now I see that raincheck is as well. Even so my setup runs just fine in all night automation. The ASCOM logs reveal lots of stuff about the firmware.
Thanks for the update Ron. FYI - I set up my dome rotator power supply from the WebPower switch to disconnect the USB hub along with the 12v power and have had no problems with the shutter for the past few days. Clearly there are a few mysteries lurking in the firmware!
Great news Steve!!
The rain check actually doesn't' talk to the shutter as the rain sensor is connected to the rotation controller. The Shutter controller queries the rotation controller about the rain sensor on regular interval (the one you set to 0 or 30 seconds). In term of who sends commands to who for the rain check :
Computer (ASCOM, X2) --> Rotation Controller <-- Shutter Controller
Changing the check interval shouldn't affect the shutter speed ... unless this actually change the interval at which the shutter queries the rotation controller this slowing dow in run loop, which slows down the stepper.
"ShutterState is asked for and received once a SECOND!!!!" -> ASCOM dos this, not the firmware.. it's probably in the NexDome ASCOM driver. I'm not saying it's right, just that it's not the firmware doing this, the firmware on the rotation controller only replies to command sent by the computer.
Now as it checks once a second (ASCOM), it could interfere with some communication until we figure out the XBee communication issue.
I'll check the code to see why when you set it to 0 it's slowing things down on the shutter instead of stopping the check (sounds like a bug to me :) ).
Awesome thank you for the code parsing Rodolphe! The Driver.cs for ASCOM most likely place for the fast status check. It is also a little odd in structure that the raincheck interval setting resides in the Shutter setup of ASCOM driver setup. Just my observation that when you grep for the raincheck routines/calls it seems very much too often. Not surprising changing a preference could affect shutter performance. Also.. even with the interval preference set to 0 for my experiment the ascom logs showed the normal dutiful once every 30 second rain check and pin report interspersed with a new occasional line stating rain check was off.
So I cheked the code on 2.0.0.0 :
if (Shutter.isConfiguringWireless == false && SentHello == true) { if (Shutter.rainCheckInterval > 0) { RainCheck(); } }no issue here.
In 0.5.2.3 that check doesn't exist in the main loop and a check that seems wrong is done in the Raincheck function, and if it's set to 0 it basically check ALL the time.. thus slowing down the rest of the code. So this is indeed a 0.5.2.3 bug :
void RainCheck() { if (millis() > nextRainCheck) { DBPrintln("Asking for rain status"); Wireless.print(String(RAIN_SHUTTER_GET) + "#"); nextRainCheck = millis() + Shutter.rainCheckInterval; } }nextRainCheck is never initialized so it can be anything.. probably 0 y default after a power cycle.
If rainCheckInterval is set to 0 , nextRainCheck = millis() + Shutter.rainCheckInterval; set nextRainCheck to millis()
Next time around .. if (millis() > nextRainCheck) is always true and check every time.
The rain check log you see every 30 seconds in the ASCOM log is probably from the ASCOM driver, not from the shutter talking to the rotation controller .. these won't show in an ASCOM log.
Awesome! Thank you! Makes good clear sense. It will be good when we get ASCOM driver in sync with 2.0.0 alpha so that we all can check stuff.
Agreed ... someone need to take care of the ASCOM part .... . . . . .
in Driver.cs :
StatusUpdateTimer = new System.Windows.Forms.Timer(); StatusUpdateTimer.Tick += new EventHandler(OnStatusUpdateTimer); StatusUpdateTimer.Interval = 1000; StatusUpdateTimer.Enabled = false;The timer interval is 1000 ms = 1 seconds .. that's why it's doing that shutter status request every seconds.
Gosh Rodolphe! Thank you ! I must be blind. Now I need to figure out how to compile ASCOM!!
Best, Ron
I'm adding a fix for this in the ASCOM code in 2.0.0.0 (you can't even imagine the pain I feel right now .... ASCOM coding :( )
You are FUNNY! I understand. I see the line at 215. Now just so you understand "why". ACP ACP/Scheduler is truly world class software for imaging. I relies on ASCOM and it very strict that ASCOM is correct.
It's funny reading about compiling ascom. according to the help files "most people figure it out" ha.
Same here ... need to figure out how to compile that $h1T
Also changing that value change the overall pull timer for all the dome values.
I'm trying to separate the rotator update from the shutter update.
Looks from logs that rotator of 5 sec ish. now,
ok one idea, move this code :
if (canSetShutter == true) { SendSerial(POSITION_SHUTTER_GET); SendSerial(STATE_SHUTTER_GET); }inside the if (slowUpdateCounter >= 30) under it, this will make it only check the shutter status every 30 seconds.
That is quite reasonable. It takes ~120 sec for shutter to open/close. Not like we are going to miss anything.
Final code should look like this :
private void OnStatusUpdateTimer(Object source, EventArgs e)
{
SendSerial(POSITION_ROTATOR_CMD);
SendSerial(HOMED_ROTATOR_STATUS);
SendSerial(SEEKSTATE_GET);
SendSerial(SLEW_ROTATOR_STATUS);
if (slowUpdateCounter >= 30)
{
tl.LogMessage("Slow update","Get");
if (canSetShutter == true)
{
SendSerial(POSITION_SHUTTER_GET);
SendSerial(STATE_SHUTTER_GET);
}
SendSerial(RAIN_ROTATOR_GET);
SendSerial(VOLTS_ROTATOR_CMD);
slowUpdateCounter = 0;
if (canSetShutter) SendSerial(VOLTS_SHUTTER_CMD);
}
slowUpdateCounter++;
}
This way we still update most thing on a 1 second interval except for the shutter stuff which is then every 30 seconds
I'll spend some brain cells tomorrow trying to sort out ASCOM compile and if I survive will check it out. Thank you for stepping into a painful box Rodolphe!
Ron
The weird thing is that when I load the PDMDome.sln win Visual Studio Express 2015 (I need it to compile my X2 plugin for Windows...) it says the
PDMDome solution is unavailable and doesn't show me any of the file in it and shows an error : [Failure] Could not find file 'E:\src\Dev\Astro\PMNexDome\PDMDome\PDomeConsole\Program.cs'.
So I wonder if some extra ASCOM stuff is needed to do ASCOM dev ... :(
Would there be a way to ask Pat to just do the compile? I could test and have a couple other folks too who are tied to ASCOM world. Anyway thanks to your help I will try as well!
Best,
Ron