Hello,
I saw that Rodolphe had committed items a few days ago and today I cloned from Git and want to report back. Both PDMRotator.ino and PDMShutter.ino compiled cleanly and upload fine. The usual stuff to get shutter working after a power off.. open a little with rocker then close with switch til it stops. On first connect to POTH after that shutter showed as Unknown. Just clicked Close and all was then well.
So far as I can tell everything if fine function wise. From ACP issuing a Home homes the dome but exactly as before leaves a lingering slew which must be stopped from ACP's control button. Failure to do this and then asking for another slew results in the Rotator having to be power-cycled to function again. I suspect something in the ASCOM driver side here. I do have workarounds in my ACP startup/shutdown/weather scripts which keep everything happy. There remains something funky in Dome.FindHome and reporting of athome. No different than before.
I also noticed that from POTH using setup rotator shows as version 2.0.0 and shutter version is blank. Also!! Now in Rotator settings the dome calibration numbers are what was in the new ino not my values. Doing a home then calibrate proceeds normally but values are not updated. Not a problem as my numbers were only 30 steps different than what is there now.
Also in POTH setup shutter both speed and accel are 0. Set does nothing.
So it does appear that the latest Git commit has ASCOM driver and the firmware slightly out of sync. I have no ill effects functionally myself but felt it important to report.
I have slewed/slaved all over the sky and run weather safety and shutdown/startup scripts mimicking an observing run and all has been fine. So my report is that all is OK with a bit of out of sync with ASCOM driver. I do not know how to compile ASCOM so will need to rely on installers as they update.
Thanks everyone for the hard work!!
Ron
Here are the DIP switch settings.
Steve
Glad you got it working!! The "factory" setting should have been switch 2 & 6 ON - all others OFF which is 8 micro steps and 2.8 Amps. Switches 1-3 are the micro step and pulse per rev settings; and switches 4-6 control the current.
Tom,
That sounds like it may be an ASCOM issue? I say that because using Rodolphe's X2 driver, my dome completes a full rotation in just under 2 minutes. However, a complete calibration-rotation will normally take up to 2x longer because the firmware divides the rotation speed setting by 2 during calibration (and finding home) for better accuracy.
As Rodolphe points out, changing the rotation speed to a value greater than 5000 will have no effect on the normal rotation speed. However, a rotation speed value of greater than 5000 WILL increase both the "find home" speed as well as the calibration speed all the way up to a value of 10000, at which point dividing by 2 gives you the maximum rotation speed of 5000. My rotation home-sensing switch is quite close to the magnet and can easily tolerate the full rotation speed during calibration and finding home, so I leave the dome rotation value set to 10000 - which means the dome calibrates and finds home at full-speed.
To Rodolphe's point about doubling the rotation speed by lowering the micro-stepping value. I actually tried that setting and it did seem to work OK, although it moved so quickly that the mount became the limiting factor in a slew so I ended up leaving the stepper set to its original value of 8. However, I also changed the micro-step value in the shutter stepper and am very happy with the speed at which the shutter opens and closes (under a minute!).
Steve
Thanks for the update. Does this make the dome accelerate faster or does it make the rotation faster also? Mine is VERY slow with 2.11E. I'll give it a try!
I just fixed a small bug on the rotator firmware. It was not properly forward the command to change the acceleration on the shutter. I pushed the new code to github and tagged it as 2.11.2
I did manage to get the new firmware and ASCOM drivers running last night and was able to use the observatory with no problems. At first I couldn't get the shutter opened, and then finally saw that the voltage was down below 12V on the battery - that explained it! I set a lower threshold and it opened fine. I tried to turn it off once open to save on the battery, but then noticed that the rotator ran with a much stronger "stutter' without the shutter in the loop. Plugged it back in and it smoothed out. I'll put the battery on charge before trying again (I run my observatory on an extension cord when using it).
I'll probably be going back and forth between this and the old 1.1 in my attempts to get the Kstars/Ekos running on my Raspberry Pi. Another one of the "Rons" who I've been conversing with on the FB group has his running and it's been doing pretty well.
Thanks again for the work on this, it's running well!
Tom
So looks like with the latest ASCOM code with the shutter enabled by default, it might be causing issue for people without the shutter : https://www.nexdome.com/forum/observatory-automation/rotator-slave-takes-minutes
So I guess we need to figure out why when it was disabled by default and the user enables it , the settings doesn't stick (even though the ASCOM profile get saved with it enabled).
Worst case we need to build 2 version of the ASCOM installer, one with shutter enabled by default and one with shutter disabled by default.
So you tested with a serial terminal and said it replies to 'v' .. but it should only reply to 'v#'
You can also check if it sees the shutter arduino. Send "H#", It should reply with H#. Then after hat send a 'V#' (this is capital V in this case as opposed to lower case v) and it should reply with 'V2.11#'
Here is what it looks like for me in CoolTerm on my test system :
v#v2.11#H#H#V#V2.11#
Once we know that the firmwares are working we can try to figure out with the ASCOM part is not working.
If the shutter doesn't reply we can also force a XBee configuration with the 'x#' command on the rotator and you will need to do that via USB for the shutter
OK thanks. I'll try putting that one back in and hope I can rotate and open. I think I am also following too many forums and pages sometimes, so I know you are a different Ron. Ha!
I've had zero luck with 1.1 and the INDI platform getting the sync to work and controlling the shutter.
I went back to my windows machine and installed the 2.1 drivers on both the motors as well as the newest ASCOM drivers. It says it connects, but nothing happens. I don't see the version numbers ont either the shutter or rotator when going into the setup window either. I did install the 2.11 version. I first had the 2.11E on there, and went to 2.11, hoping that would work. Nothing.
Any ideas what I can check? It does show up fine on the COM port and connects, but nothing else.
The 90 second home timer is working fine, since the dome tries to rotate back to home, so that is working.
I was really hoping to get something going with INDI and Stellarmate, but went back to Windows for a sanity check now nothing works.
Any ideas?
I'll give that a try. I didn't realize that there could be some residual "stuff" left over. I figured the new code upload would totally replace the old.
I'm thinking I have the same setup that Ron is running, but he got his opening, syncing, and rotating at a decent speed.
After a lot of testing we finally have a release version of the new firmware and ASCOM code.
Thanks to Ron Crouch testing on the ASCOM side I made a full release.
The firmware need to be upgrade on both Arduino.
This will reset ALL the settings to default on the Arduino so you'll have to recalibrate, reset your voltage cut-off and speed and acceleration.
The shutter watchdog is set by default to 90 seconds after losing communication with the rotation Arduino. The ASCOM setup dialog doesn't have a way to change the settings but if you need to it can be done in a serial terminal (including the Arduino IDE serial console) using the I command followed by the value in milli seconds and a #. So I300000# would set the watchdog to 5 minutes (300 seconds).
The ASCOM driver has been tested by Ron over the last 2 weeks.
I've also tested this firmware with the X2 plugin for TSX and have not seen any issue with my test system.
The firmware are at the usual place : https://github.com/nexdome/Automation
And the latest ASCOM driver : https://github.com/nexdome/Automation/blob/master/ASCOM_Driver_Releases/NexDome%20Setup_211E.exe
For people who are having issue with the watchdog .. you probably have been using multiple versions of the firmware (0.5.2.3, 2.000, 2.11 ... ) and have some corrupted value in the EEPROM.
I committed a new version that has a new signature for the EEPROM and will ignore all the previous values.
Using this version means you have to reconfigure the whole thing (calibrate to get the number of ticks per rotation, set the speed and acceleration to what you had before, reset the voltage cut-off, ...) as it resets everything to default settings.
This version is in the develop branch and is being tested. If all goes well it will be pushed to master with the new ASCOM driver install.
Rodolphe
INDI is much better than ascom. What happened to the original nexdome INDI author? He still have a nexdome? I suspect after Tim Long gets the offical releases done we'll just one a indi update. HOWEVER I hear rumor there are people currently using the indi driver. I'm trying to figure out what firmware they're using. WATCHDOG - ya know - mine was fine - for about a hour. I was playing/texting Kstars and indi setup and the shutter closed for seemingly no reason. And I've not gotten it to work since. EVen later I went to manually open the shutter. If I let go of the button it would close. As it opened all the way it stopped and it started to close. I had to pull the power cord out of the battery to keep it open. You think this is that watchdog code? Whats the chances of the old INDI driver being compatible with the 2.1 firmware?
This is great news. Spring is just around the corner (although you would never know it here) and there are a lot of people waiting for an ASCOM solution!
LOTS to read up there (sorry I skipped to the chase). My shutter doesn't connect very often at boot up. I was thinking of swapping to a new xbee card (if I knew what to order and where). Is there some other fix in all this work mentioned above?
My problem is - I might have to boot power off and on shutter and or rotator 20 times to get them to connect. Once they do, if I can LEAVE THE ROTATOR POWERED the two will stay connected (weeks to prove it). but we've lost power recently in wind and I can't get the shutter to connect again. Any way to force it via some code or what do you think about me swapping it. (when I have no clue what that entails).
LOTS to read up there (sorry I skipped to the chase). My shutter doesn't connect very often at boot up. I was thinking of swapping to a new xbee card (if I knew what to order and where). Is there some other fix in all this work mentioned above?
My problem is - I might have to boot power off and on shutter and or rotator 20 times to get them to connect. Once they do, if I can LEAVE THE ROTATOR POWERED the two will stay connected (weeks to prove it). but we've lost power recently in wind and I can't get the shutter to connect again. Any way to force it via some code or what do you think about me swapping it. (when I have no clue what that entails).
I found another bug in the shutter firmware which I fixed. It's only on the develop branch for now as I wan to release both the firmware and the ASCOM code at the same time. So I'll wait for Ron to be back for this.
The issue regarding the shutter is that the state was only updated when opening or closing. So if your app queries the initial state it was getting a state of ERROR (or unknown) even if the dome pas properly close or fully open. This can me an issue if for some reason the Arduino is power cycled as it would think it's closed when it might not me. Now the state is properly updated and set to it's proper initial state by checking the open and close sensor/switch state when the arduino starts.
Let me ask this to make sure I'm still up to date. The last release 2.1.1 is for TSX users? So regular windows users running dome/scope/camera/etc. devices using Starry Night, Sky Safari, SGP, etc should not use this driver for dome control and we should continue using NexDome Dome ASCOM driver 5.2.3?
Thanks,
Steven
I posted the latest ASCOM driver compiled by Ron after the changes I made.
It's in the develop branch (as opposed to the master branch) :
https://github.com/nexdome/Automation/tree/develop/ASCOM_Driver_Releases
If this works better we can keep digging in there and try to fix the stutter.
And then do a 2.11 release.