Tested Latest 2.0 Build

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.

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 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.

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?

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

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.

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.

Progress!!

Well Steve's idea to explore ASCOM is a winner here! Sending commands in CoolTerm results in rotator which could not be smoother! So the stutter is the way ASCOM interacts with the firmware.

CoolTerm is fun!!

Thanks Rodolphe.

I still have to test all this again for real in the observatory. Just waiting for a clear night, and some reasonable temperatures, a day where I can sweep the snow out of the inside (darn gaps!), and hook it all up and reconfigure all the USB, Serial ports, new guider camera...etc.

Wow good instincts guys! If anything shakes out for testing just point me at the files. Thanks so much.

That's interesting. But maybe a side-effect of the shutter attempting to remain closed after it doesn't hear from the rotator?

Both of my motors rotate smoothly. However, they do emit a "tick" (definitely not a thump) from the gearbox approximately once every couple of seconds but it does not affect the rotation velocity.

I am using non-default rotation and acceleration values and have just assumed that every couple-hundred calculations the stepper controller either gets a number that "doesn't compute" or the Arduino is so busy it misses a step-command.

I also got tired of waiting for the shutter to open so I changed the micro step setting on the shutter TB6600 to 4 micro steps and 800 pulses/rev which opens the shutter in less than a minute :-).

The values I gave above for the steps per rotation is the default value from the firmware .. in case the eeprom data were set to bad values from previous firmware(s).

If other people run into non smooth movement the next step would be to use interrupt to step the motor (I might run some tests). I would also need to add an interrupt for the homing if the stepping is in another interrupt to make sure we do stop on homing.

And I thought I was done ... "little did he know ..."

So let me know if the "pulsating" is an issue everyone sees .. which would me I need to fix this (I don't see it on my test rig).

Rodolphe

Is one of these the new ASCOM driver vs. the old one? I was using the one called

PDM NexDome driver" before. Now I also see a "NexDome Driver" in the list. Seems clear tonight, so maybe I'll go out and try to home it on the magnets, set to 5000/5000 and 440800 then try the calibrate and see what happens.

Installed the new drivers and firmware. Is it normal for the motor to pulsate when it rotates? It runs for about 1.5 seconds, stops for a moment, then runs again. --Repeat.

Ron files updated, release done :

https://github.com/nexdome/Automation/releases

The zip file (Automation-v2.1.zip) also has the installer in ASCOM_Driver_Releases and the firmware in Firmwares.

Oh....well I guess I'll just hold off on that then. I'm not even sure what TSX is.

Tom

Hey Tom,

Now for the bad news... Unfortunately, v2.1 firmware only works with TSX and is not compatible with the old ASCOM driver. Frankly, that's the rub - seems like the "new guy" Babak hired could have at least started there.

Steve

Good catch Rodolphe!

Just to be clear, this only needs to be done if/when replacing one or more of the XBee radios?

Steve

Since this is a watchdog for lost communications I'd say something like 3 cycles of the normal 30 sec rain-check. Comment the line well with notes for low and high valid readings in case it needs adjustment.

So today I did more cleanup in all the places where millis() was used and replaced them with a stopwatch class. This simplifies the code and makes it more readable. I've tested this and it works well for me.

I also did more cleanup in the code.

Let me know if you find some issues.

I'm making a few more changes.

Ron pointed out that the millis() function on the Arduino was used and will roll over and this could create issue (after 49.71 days). So I'm fixing this as this has been solved already by countless people and just require a small change.

I jus fixed the Rotator code and will soon fix the Shutter code for this.

Just did a small commit to set both firmware version to 2.1 , no other changes.

I made a new change as apparently on Hello we still miss the 2 first commands somehow.

This fixes a few issues I saw with the ASCOM driver.

New firmware code is there : https://github.com/nexdome/Automation

@Rodolphe

So I figured out why you aren't getting half-speed when finding home on your test rig. As I mentioned earlier, when I compared the times for my dome slewing to a point via a goto versus returning to home from that point, I found them to be about the same. The only difference between your settings and mine was that I had the rotation speed set to 8000 in my firmware.

I had a bit of time to waste this afternoon so I decided to experiment with different rotation speeds. Here is what I found when comparing a GOTO AZ 270 to a "Find Home" from AZ 270 (using a stopwatch this time):

As you can see, the GOTO (normal slew) rotation speed tops out at a setting of 5000 in the firmware. However, the "Find Home" speed continues to increase with increasing rotation-speed settings until it finally tops out at the same maximum rotation speed as a normal GOTO slew. So it looks like the stepper controller can't go any faster than an equivalent setting of 5000 in the firmware.

Who knew...

That's great news Rodolphe!

I'll probably change the final version to 2.0.1.0 or something more like 2.1 (we don't need 4 digits !!! ).

Also Baback created an official NexDome github account with an Automation repo in it and move all the latest code over there.

I need to probably rename a few things and update the Readme.md to add the new info in there, but this will be the new official location of the firmware and ASCOM code.

https://github.com/nexdome/Automation

I plan on creating a develop branch in addition to the master branch so that master always point to a working version (once we release 2.1) and develop point to what I'm testing and is not ready for prime time.

Rodolphe

For what it's worth, despite Pat's excellent efforts, v2.0.0.0 never really "worked."

Before your started working on it, I had so many communication issues with the shutter that it was completely unreliable for dome automation (which is the whole point of automation software)!

Now, thanks to your efforts, we at least have firmware that works! So, thanks again for getting us to this point!!! Maybe it's time to change the version number to 2.0.1.0?

Well, in that case, it must just be my imagination! I am rarely in the dome when it is actually busy slewing - I generally only go in to upload the shutter firmware and then go back in the house to test it :-). I just happened to test the latest firmware from inside the dome this last time because I was making some equipment changes. So, the previous "sound" I recall from the motor is from several versions ago and based on solely my (often unreliable) memory.

The good news is that everything is working! I will continue to put the firmware through it's paces starting in a couple of days when the weather improves. I just swapped OTAs and am hoping to collect a bunch of data in Jan/Feb.

Thanks Rodolphe!!

I went all the way back to when I introduced the half speed and it behaves the same way.

It's not really half speed as we've seen so the behavior has been the same from version

b5897dc8eeb7a3dd3055442f70b8be968d79a3ef

That's interesting. I timed my dome yesterday for a slew from Az 165deg to Az 270deg and then for a "find home" from Az 270 back to Az 165; and they both took 28sec.

Has the maximum slew speed changed at all? The reason I ask is that with the last version of firmware my rotation motor was very smooth and quiet during a normal slew; however, it had a periodical (about 2x per second) "clicking" (like the motor wasn't quite happy with the stepping rate) noise from the gearbox during the slower, "find-home" slew. Now, the clicking noise is occurring during both normal and find-home slews and the rotation definitely seems slower during normal slews than it was previously. I haven't changed the rotation speed so I'm not sure why the motor would sound different with the latest version. When the weather clears I may reload the previous version to make sure it's not just my imagination.

As for a colder-temp stepper controller, that would be nice, but the weakest link in my system is not the (-10C rated) TB6600 stepper because many of the electronic devices in my dome are only rated to operate down to 0C. Frankly, I am surprised everything works down to -15C! So far, the first thing to fail when it gets too cold is my filter wheel.

I check the code and homing and calibrating are supposed to be done at half speed.

I'll do some test on my side.

Edit :

I did a test, even though I call the stepper.setMaxSpeed with _maxSpeed/2 it's not quite going at half the speed. I did a goto 90 on mu test rig.. 8 second, find home from that position ... 12 second

So not quite half, more like 2/3rd. Not sure why the AccelStepper lib does this. I know it doesn't use a timer so it's not as precise as it could and it also depends on the number of time you call the run() function for the stepper object.

So I didn't break anything.

The more I look at the AccelStepper lib the more I thing a proper stepper library that uses interrupt timer to driver the stepper steps and state would do a way better job. But at this point we seem to have a fairly stable version, not issues with XBee as far as we know and all my changes seems to work and help make the whole thing more stable.

I found one more bug in the shutter firmware while working on the ASCOM driver. It's now fixed.

Unfortunately, CCDAP just waits for the slew to timeout. After it times out, CCDAP does another plate-solve and it always shows that a slew actually completed and the mount has been tracking the last 5 minutes. Here is an example from the log file:

06:00:00 Solved RA: 05 36 18.3, Dec: +34 08 23, PA: 89.9 (2.1s)

06:00:00 Plate Solve Time: 11.7 sec.

06:00:00 Pointing error (arcmin): RA -0.2; Dec 0.1

06:05:03 Correcting slew failed. TheSkyXAdaptor.RASCOMTele.1 says Receive time-out. Error = 209.

06:05:03 Plate solving...

06:05:03 Telescope RA: 05 37 32.5, Dec: +34 09 02

06:05:13 D:\UserData\Pictures\CCDWARE\SyncImages\Sync_20181121_060503.fit

06:05:15 Stars: 37, FWHM: 9.0 arc-sec.

06:05:15 Solved RA: 05 36 18.1, Dec: +34 08 27, PA: 89.9 (2.1s)

06:05:15 Plate Solve Time: 12.1 sec.

06:05:15 Pointing error (arcmin): RA -0.1; Dec 0.0

06:05:15 Try 1 slew error: 6.2 arc-sec

Anyway, the firmware seems to be working well and I also agree the small-moves problem seems to be fixed and the above slew errors probably have something to do with TSX & CCDAP not working well together.

Bottom line is it looks like great progress!

@Rodolphe

Great timing, I just about to give you a quick update on your last firmware commit. The great news is that, after using it continuously for the past week, I am happy to report that is has been completely stable and seems to be working perfectly. The dome has been connected to TSX continuously, and I have run imaging sessions every night but one without any issues with the shutter.

The only weirdness has been an occasional non-fatal, “correcting slew failed” error from CCDAP. As you may recall, I originally surmised these errors were caused by the firmware struggling to accommodate very small moves arising from the closed-loop slews CCDAP uses to acquire and maintain targets. However, just for fun, I performed over 50 closed-loop slews using TSX directly as well as another 50 random manual slews of less than 10 arc-sec and could not reproduce the error in TSX. I also swapped OTAs the other night and performed a 75-target T-Point pointing-model run without any slew errors.

Because I haven’t had any slew-errors using TSX directly, I suspect some sort of issue with the scripting interface between CCDAP and TSX. I contacted the author of CCDAP and, unfortunately, his response was “use the ASCOM driver instead of the X2 plugin.” I pointed out that the only reason I was using CCDAP was due to its tight integration with TSX and the ability to use a single control program; and, if I had to use ASCOM, I would probably switch to something else like SGP or even try PRISM. Unfortunately, he didn’t seem particularly concerned...

At any rate, the slew errors in CCDAP are not fatal, and the system recovers when the slew times-out in 5 min. Also, they don’t occur every night and, when they do occur, I am only seeing one or two in a session.

Hope that helps!

So, no failure report so I guess this is a good sign :)

I'm going to make a few more changes this weekend.

Currently when the rotator Arduino get a Hello from the shutter it sends commands to get all the data, all at once, without reading the response and expect they'll be waiting in the serial fifo or the XBee fifo for the next check. I think this is causing some of the communication issue I was seeing and I've made a change to make this more synchronous (send command, read response, send next command, read response ...) instead of the way it's done right know to avoid fifo buffer overruns.

I'll test this on my local rig and if it works I'll push the new code sometimes this weekend.

In my W10 world.. for build :

https://github.com/pmeloy/NexDome/tree/69017e505f485f9a4d5784b2bd99ff23cedaa9ae

Shutter compiles fine but Rotator fails to compile.

Looks like a path thing but Rotator PDMRotator folder is sitting right in the Arduino folder. When I compile I always put the folders directly there and avoid nesting. I can put my current 532 PDMRotator folder there instead and things are normal. Since the new PDMShutter.ino compiles fine it might be something in the Accelstepper.h. Which library version should I be linked to?

I am using the same Arduino program I've been using since the beginning. I'll enable verbose messages.. Here is the short story.

Errors follow.

##

Arduino: 1.8.8 (Windows Store 1.8.19.0) (Windows 10), Board: "Arduino Leonardo"

C:\Program Files\WindowsApps\ArduinoLLC.ArduinoIDE_1.8.19.0_x86__mdqgnx93n4wtt\hardware\arduino\avr\cores\arduino\WString.cpp: In member function '__base_ctor .constprop':

C:\Program Files\WindowsApps\ArduinoLLC.ArduinoIDE_1.8.19.0_x86__mdqgnx93n4wtt\hardware\arduino\avr\cores\arduino\WString.cpp:98:1: internal compiler error: Segmentation fault

}

^

Please submit a full bug report,

with preprocessed source if appropriate.

See <http://gcc.gnu.org/bugs.html> for instructions.

lto-wrapper.exe: fatal error: C:\Program Files\WindowsApps\ArduinoLLC.ArduinoIDE_1.8.19.0_x86__mdqgnx93n4wtt\hardware\tools\avr/bin/avr-gcc returned 1 exit status

compilation terminated.

c:/program files/windowsapps/arduinollc.arduinoide_1.8.19.0_x86__mdqgnx93n4wtt/hardware/tools/avr/bin/../lib/gcc/avr/5.4.0/../../../../avr/bin/ld.exe: error: lto-wrapper failed

collect2.exe: error: ld returned 1 exit status

Multiple libraries were found for "AccelStepper.h"

Used: C:\Users\roncr\Documents\Arduino\libraries\AccelStepper

Not used: C:\Users\roncr\Documents\Arduino\libraries\src

exit status 1

Error compiling for board Arduino Leonardo.

This report would have more information with

"Show verbose output during compilation"

option enabled in File -> Preferences.

##

Hello Again.. One other question.. What if anything do I do with the XBeeConfig files?

ron

If this thing is ready where can we find it? I think I answered my own question: https://github.com/pmeloy/NexDome/tree/69017e505f485f9a4d5784b2bd99ff23cedaa9ae is this correct?

Thanks for all of the hard work!

Steven

...83978 = AOK. Congratulations Rodolphe, as far as I can tell, you didn't break anything!! Awesome work!

all == true from the rotator code are gone

47038cc4247c3e8fedda1ca0f485e2c1789b6aee

so next change will be more important.

There are a lot of

if(variable == true)

in the code... that I'm going to replace with

if(variable)

as it's the same and get better optimized by the compiler.

Then I'll do all the

if(variable == false)

and replace them with

if(!variable)

same reason.

I uploaded and tested ...8fc2: the good news is that you haven't broken anything yet!

shutter code also done, commit id 163b366b3c5ff22f84ec0cbe8f70e03a09f58fc2

Next I'll start some stack usage optimization.

@Rodolphe

Between the two of us, we can probably break just about anything! At any rate, the good news is the shutter firmware is uploaded and working fine!

Another giant leap for mankind - well, at least a small step for NexDome users.

As always, thanks a million for your continued efforts to get this firmware to the point we can forget about it :-) !!

Still won't compile on my side - any suggestions?