Shutter motor - how do I make it run?

I would not try 2 yet. Will not work at all with ASCOM. Power supply is fine but when not rotating it drops to a low power mode.. I would replace but need a big fat plug to go into rotator. I do not want to cut the existing plus my other good 12V (5A mean well from Jameco) I use inside house to power camera when I bring scope inside.

Regarding rotator voltate. If you are looking in POTH ASCOM setup->rotator and move the dome there like to calibrate to do a full turn you will the the voltage jump up to 12.6. When it stops it might drop. I'm convinced the power supply is a silly low-energy thing. If you are using 0.5.2.3 there is a tiny change needed in PDMShutterclass.h around if the way typedef struct is used. On line 138 change to:

} Configuration;

Configuration config;

Note the removal of the ; after the } and the next line setting config. without that there will be warnings about typedef when you compile PDBShutter.ino

Rodolphe showed me how to fix.

Just so you know I have tried latest "2.0" and it will not work for me so I stayed back on 0.5.2.3.

Ron

Just an update since I haven't reported here lately. I did replace the Arduino and the Xbee in the shutter motor. Tried it out and found it works! It was a problem with the Arduino that it came with (or maybe the Xbee transmitter?) Anyway, got it working. Still showing 4 volts on the rotator, but it runs, so I'll check out the solder connections on the shield and see if I find something odd.

Quite a learning experience, but I feel I have a good idea of how this thing runs now and learned more about the Arduino.

I tried programming it with Linux, but for some reason I kept getting errors when compiling the software. Put it back on windows and it worked. Still trapped in the Microsoft world for now.

Tom

just a quick post to show what voltage I see if I use test Arduinos that don't have the shield and 12V plugged in :

As you can see these are in line with an Arduino only powered by the usb port and the fact that some of you see there type of voltage instead of 12.xx V makes me think there is an issue with the shield (bad solder points ... ).

Rodolphe

I did just get my new Xbee and Arduino. I'll update that with the latest firmware and probably try putting that into the rotator, or just "shuffle" the cards but leave the current Arduino off since it seems to be showing the wrong voltage. I was trying to program it last night with Linux version of Arduino IDE, but just kept getting errors. I'll give in to Windows again and try that way.

Update! If ASCOM logs show constant "Serial Receive Short message (P)" at connect something is wrong even if ShutterState is returned as 1 (closed). After my re-cal of shutter this goes away. and I just see the constant reporting of that with no Short message (P)..

Hi Tom Hi Rodolphe,

Last night/this morning I had a similar event! Last night there were a couple of weather/cloud closure events and lost the shutter on the 2nd one. This morning I restarted things and looked and in ACP It was reporting ShutterError. Always look in Documents\ASCOM at the log!! The log showed that on dome closing (ShutterState =3) it never completed. Dome was closed but the magnetic switch had not been tripped! Just opened a little with the rocker then re-closed and the switch tripped OK. Now ACP Dome knew about it and all was well. So I opened dome slewed mount/rotator to Casper then ran the weather script manually. Dome put charging tabs on position, shutter closed but once again the state of "closing" never moved to "closed" in logs. So the shutter motor was stopping about 1/8" too high for magnetic switch. Charging tabs still reached.

Now the really witchy part.. We had tons of rain and the little gutter on dome under the shutter was of course full of water. I brushed that out. Now things worked. No way!! Anyway I redid the shutter calibration.. (with rocker open slightly, then close then immediately hold switch til fully open. Closed with switch and things are fine again. Yesterday I did mess with setting raincheck interval = 0 and it totally broke things. I set it back to 30. Maybe stuff got hosed.

For Tom my message is what do the ASCOM logs say when you connect to POTH and then wait about a minute? If you see a constant repeated "Serial Receive Short message (P)" followed by ShutterState Get Value (4) it means the shutter firmware cannot see either magnetic switch and is asking over and over.

Ron

I dowloaded the release 0.5.2.3 (which inside is really version 0.5.2.2 of the firmware) and was looking at this code in our other conversation. The GitHub repo is on version 2.0.0.0 so a lot has changed there.

You would need to checkout an earlier version before the 2.0.0.0 changes we committed (and I'm about to commit my fixes for the XBee stuff).

If you want the 0.5.2.2 from git you need to do :

git checkout d21df2048b9977c12f97d11eb6451bcf949c05ed

This is the commit id of the last version before 2.0.0.0

this checkout will give you exactly the same code as the 0.5.2.3 zip file. You also need to disable logging before uploading or it will break a bunch of stuff as it sends spurious debugging info in the middle of the rest of the commands/responses.

Hello Tom & Rodolphe,

As you both know I have an installation of PDMNexdome which works and Tom has a version which does not work. I clone current Git version and start looking. I do this because in a conversation with Rodolphe regarding homing from ACP issues he referred me to lines in RotatorClass.h. I find the same lines in my WORKING installation at a significantly different line number. This means that what Tom and Rodolphe are looking at differs from what I am using. I had also sent a zip on the versions I installed to another NexDome user and his installation is happily working the same as mine.

There are significant differences in the files of what I will call my working installation and Tom's failing installation. There are discrepancies between Version as sated in file name versus declaration of version inside of the ino files which I am using. FileNAME says 5.2.3 but Version inside the file says 5.2.2. I had offered some time ago to send a zip of the installation which I and at least one other user know works.

My working RotatorClass.h is 761 lines long. The file I get if I clone master from Git is 771 lines long. Side by side in NotePad+ with Compare plugin running there are significant differences. So I offer one last time to put a zip of the files I have been using which I know work properly for the most part someplace accessible.

Finally. I will state once again that IMHO that the driver reporting of rotator voltage is a red herring. My drvier does exactly the same.. Varies between 5.4V and 12.6V typically. YET!! no failures ever!! If the voltage really was being reported properly no way would my dome work. I have also checked the soldering of those 3 voltage divider resistors on the shield and all is fine there. I would offer that something is amiss in the code which is reporting.

Best to all,

Ron

all this info is above my pay grade, but I'd first figure out why you're not getting 1250 ish power. You're way under and nothing will work right without proper power. 12v 4 amp recommended. Once rotator has proper power - then look for connection readings from the shutter.

@Tom Gwilym

So as I was debugging the 2.0 firmware XBee issue I had an idea.. what if the XBee on the shutter wasn't properly configure or was used for something else before it was put on your board and is not on the right channel ...

So one thing to try :

On the rotator code, in the ConfigXBee function in PDMRotator.ino :

ATString = "ATCE0,ID7734,AP0";

ATString +=",CH0C,MY0,DH0,DLFFFF"; <--- Add this line

ATString += ",SM" + String(sleepMode, HEX);

On the shutter code, in the ShutterClass::ConfigXBee method in PDMShutterClass.h :

_ATString = "ATCE0,ID7734,AP0";

_ATString +=",CH0C,MY1,DH0,DLFFFF"; <--- Add this line

_ATString += ",SM" + String(_sleepMode, HEX);

This will force some value back to what is expected.

Compile, update both controller and try it out ...

This is juts a guess.. you still can have a defective Arduino or XBee module, but at least we would have tried our best from the software side.

Love the test rig! My world does work fine but I'll test the ATCE0->ATCE1 change just to get another data point in the mystery. Thinking about Tom's situation.. Looking at the PDMShutter.ino I see how a false positive (or bad wiring) related to the rain sensor could keep it from responding. Just thinking out loud.. I did purchase the rain sensor but decided to not use it because I also have a AAG Cloudwatcher which talks to ACP - handles weather alerts properly - shutter closes - ACP waits til clear then it opens and resumes. I pulled plug on the rain sensor because I did not want 2 pieces of hardware talking to firmware at same time. If the Cloudwatcher goes down the rain sensor is my backup. I might have missed this but Tom if you have a rain sensor disconnect I see what shakes out.

Ron

No need to send me anything .. I have all the versions ;)

in 0.5.x, change :

ATString = "ATCE0,ID7734,AP0";

to :

ATString = "ATCE1,ID7734,AP0";

just for the rotator, if you want to test.

If it works, no reason to change it in your case (if it ain't broken, don't fix it).

I know that on the new 2.0 firmware (upcoming at some point), I've been having countless issue on my test rig with the com between the 2 XBee ( test rig can be seen here : https://rti-zone.org/astro_diy.php#dome ).

As Tom also has coms issue this could help.

Rodolphe

So I just found something .. the rotator XBee is not configured as a "Coordinator".

From what I can read, it's required that at least one XBee module is set as a "Coordinator"/

If you want to test the change, go in the ConfigXBee function in PDMRotator.ino and change the init string to :

ATString = "ATCE1,ID7734,AP0,SM0,RO0,WR,CN";

the change is CE0 -> CE1

This might be the cause of some of the issue we see with communication. I found this that explains the reason for this :

"In ZigBee, there are three different types of devices: end device, router, and coordinator. The key difference between these is that an end device can not route traffic, routers can route traffic, and the coordinator, in addition to routing traffic, is responsible for forming the network in the first place. Every network must have one and only one coordinator. These differences dictate the different features of each type of device."

I did sone debugging on the future 2.0 firmware and there are a lot of issue related to XBee communication. In the CoolTerm screenshot above, it's clear that the shutter arduino sends an Hello but get no response.

When they talk to each other you should see something similar to this on the usb port of the shutter controller :

<<< Command:H Value:

Rotator says hello!

Sending hello

Sent hello back

<<< Command:H Value:

Rotator says hello!

Sending hello

Sent hello back

Asking for rain status

<<< Command:H Value:

Rotator says hello!

Sending hello

Sent hello back

<<< Command:F Value:0

It's not raining

<<< Command:M Value:

M4

>>> Sending M4

<<< Command:M Value:

M4

>>> Sending M4

<<< Command:V Value:

V2.0.0.0

>>> Sending V2.0.0.0

<<< Command:Y Value:

Y0

>>> Sending Y0

<<< Command:T Value:

Get Steps 885000

>>> Sending T885000

<<< Command:R Value:

R1000

>>> Sending R1000

So Xbee com are a constant problem.

If nothing else, I've learned a lot about the Ardiuno system. I did buy one of those "Learning kits" a while back and some books. But this is real world experience rather than just making LEDs count in binary or whatever. :-)

Pat has pushed a new version of the source code to github but it's not finished.

So instead you can just get the code of the 0.5.x version : https://github.com/pmeloy/NexDome/archive/0.5.2.3.zip

Without having to worry about the GitHub code part. Download this then extract it. It will extract into

NexDome-0.5.2.3. In this directory got into PDMRotator , this contains the code for the rotator. You'll need the Arduino IDE to load the PDMRotator.ino file (it will load the header file at the same time) and go to the RotatorClass.h tab to fixe the debugEnabled.

Make sure you selected the correct board in the "Tools->Board:" menu to "Arduino Leonardo" and the right serial port in "Tools->Port:". The you can click on the checkmark icon and the on the right arrow icon to upload the new code to the rotator. After this, unplug the usb cable and power cycle the rotator.

If needed repeat all of this with the shutter code, no need to disable debug on this one.

Pat as apparently been busy with life and hasn't done anything new recently and the new 2.0 firmware is not finished and has a few issues. If nothing happens soon I guess I'll have to dig in it and get it to a working point (some commands no plonger return anything, issues with XBee communication init).

In the mean time let's try to get you guys going with the 0.5.2.x version.

Wow thank you Rodolphe! I think we are all going to have to gain at least a basic understanding of how to use Github in order to advance.

Best,

Ron

I used the github version of the 5.3.x firmware and as I'm the one who designed the shield and wrote the X2 plugin for TheSkyX Pro I was able to make sure the reported voltage was correct after I applied some math correction in my plugin as the one in the firmware is somewhat wrong and reports higher value than what it is ( see https://rti-zone.org/macosx_x2dome_plugins.php#nexdome ).

But 4.80V way out of the expected value but as long as the cutoff is bellow that number you should be fine.

I also noticed that the firmware has debug enabled.. this can also cause problems (my plugin for example doesn't like the debug lines). If you uploaded the plugin from the source, change this :

byte debugEnabled = 1;

to :

byte debugEnabled = 0;

line 72 in RotatorClass.h, then recompile and re-upload the firmware.

I agree the low voltage is very weird but I see the exact same thing! I set the threshold to 1V and everything has run perfectly for several nights now. I was asked to check 3 voltage divider resistor connections on the rotator board and they were fine. I need to change the 12V rotator supply.. it has a strange flashing green led. my other 5A 12V supplies do not have plugs with a large enough center post hole and I need to make an adaptor to rule out the supply. I'm guessing another possiblity is that with the 5.3.2 firmware maybe the wrong pin is being read? Yes it is weird indeed. I'm not inclined to tear things apart looking in my case because it all works very well here in Texas. Eventually will look at code but for me ACP automation is very robust. I do see things in the ascom driver I do not like.. eg if acp homes the dome there is never a response back saying it happened.. So I would "stop motion" (it's sitting at home not moving) then click same button in acp again and it's ready to go. Fortunately manually homing in acp is never part of a workflow.

Thank you Tom for your patience and hard work and thank you Rodolphe for being a hand of guidance so we all can learn.

Ron