CONTACT US

BE FIRST TO KNOW

Questions? Comments or like to contact us? Use this form to message us.

Email: sales@nexdome.com

Tel:    +1.604.421.2835

Sign up for our newsletter to get informed about NexDome news or new products.

Oct 12, 2018

PDM Driver Homing Issue

15 comments

Hello!

I have found that in ACP if I in something like a weather script ask for the dome to home it in fact homes but does not report back to ACP. My workaround is to just slew dome to where home should be. That is fine. Following is my current working prototype ACP-Weather js script (comments are longer than the code). The comments describe the behavior. I've asked Bob Denny (ACP) for his advice on what response back is expected.

 

//is a comment line..

 

 

function main()

{

if(Telescope.Connected) {

Console.PrintLine("Weather Safety Script..");

Telescope.Tracking = false;

Util.WaitForMilliseconds(2000);

Console.PrintLine("Positioning shutter over charger tabs...");

//Only reason to move dome at all is in case weather stays bad from rain.

//Might not be able to open and turn. Need to avoid rotator gear running

//over the charging tabs

//Following three lines home dome but PDM driver does not report back to ACP.

//Only recovery is to disconnect all and power cycle rotator.

//Dome.FindHome();

//while(!Dome.AtHome)

//Util.WaitForMilliseconds(2000);

//This Alternate to above 3 lines seems ok

Dome.Slew(0);

while(Dome.Slewing)

Util.WaitForMilliseconds(2000);

Dome.CloseShutter();

Console.PrintLine("Closing shutter...waiting 120sec for it to complete....");

Util.WaitForMilliseconds(120000);

 

Console.PrintLine("Done.");

}

}

Oct 13, 2018

I had time between rain storms to test on actual hardware. The js at bottom does seem to work. The one in previous message fails with the dome closed and safe but the rotator reporting a lingering non-event slew which killed further action until power was cycled in the rotator arduino.

 

For whatever reason this now seems to work meaning I can run it and the dome moves over charging tabs, scope park/dome closes. When down it quietly sits "parked". In ACP to mimic a cleared weater event I just opened dome and unparked SCOPE. Then I could slew/slave just fine. I ran through things about 5 cycles with no failures.

Of course I need an actual session to try.

 

Every line of this little script was important except maybe the final 2nd "Dome.Park();

 

Note that Dome.Home(); while(!Dome.AtHome) will not work. That is something bad in the driver.

 

Best to all,

 

Ron

 

 

function main()

{

if(Telescope.Connected) {

Console.PrintLine("Weather Safety Script..");

Telescope.Tracking = false;

Util.WaitForMilliseconds(2000);

Console.PrintLine("Positioning shutter over charger tabs...");

 

Dome.Park();

while(!Dome.AtPark)

Util.WaitForMilliseconds(4000);

 

Console.PrintLine("Parking telescope and closing shutter....");

Telescope.Park();

Console.PrintLine("Done.");

Dome.Park();

}

}

Oct 13, 2018

One thing I've noticed is that when homing (on my test rig), if it turns too fast, it will pass the home sensor and the test fails as it goes too far after the home sensor as it takes too much time to go from full speed to stop. I had to slow down the rotation to make sure it properly detect the home sensor and stop in time for the Dome.AtHome test to work.

You can also make sure the magnet and sensor are close enough when they cross each other (I'll even say try to get them as close as possible).

 

Oct 13, 2018

Thank you Rodolphe! I'll give that a try when I can and report.

Good news is that the last example of ACP-Weather script works properly! Dome is safe and closed and remains in a state quite happy to continue if weather clears. Having Dome.Home(); rather than Dome.Park(); would be much better because that way the charger tabs are always in good position. How slow did you go?

 

I'm copying the same snippet of ACP-Weather into my ShutdownObs script so that everything also get turned off power-wise. If I could get Dome.Home to work things would be very nice indeed.

 

I might look into magnetic sensor switches a little too. Seen inductive ones but they are more for really high speed.

 

Seems like the Dome.Home routine should do something like get within 20 degrees or so then slow down internally to the firmware. That might be something I could do.

 

Thank you again,

Ron

Oct 13, 2018

As this is done on a test rig in my case (I don't actually have an observatory), my values will probably not be correct for you. So you'll need to do a few test until you find a value that works.

The find home code doesn't assume any position for the home position as this is meant to re-sync the done on the home position.. so it can't slow down 20 degree before an unknown position.

The park position is know, as well as the goto position so it can indeed decelerate before reaching the end position (park or goto), not so much on a find home (this is really a find home more than a goto home as it looks for the home sensor and not a given position).

Rodolphe

 

Oct 13, 2018

I just moved dome about 3 degrees from home. On home from POTH it is fine but on home from ACP there is the lingering slew issue. Now ACP has been running domes all over the world for years and the creator of ACP is of course also the starter of ASCOM. (Bob).. I assume the ACP code is tight but there is something different here in conventions.

 

Thanks for your comments above. Trying to learn.

 

Best,

Ron

Oct 13, 2018

I wonder if ACP does a GoTo to the home azimuth instead of a find home. If the dome hasn't been home at least once, it won't be synced and will go to a position that was the power up position (0 Deg.) + home Az (just guessing here as I never used ACP as I do everything on OS X with TheSkyX Pro).

Oct 13, 2018

Wow yes I'll try this. There is an ACP startup option when Dome is connected to home on connect. I'll turn that on.

 

Best,

Ron

Oct 14, 2018

Hello Again Rodolfo,

 

I do have working "Weather Safety" and "ShutDownObs" scripts which play nicely between NexDome and ACP. What I have found is that the action "Home" by any means in ACP results in a NexDome driver state of "At Home" but in ACP there is a residual slew which needs to be killed. Even asking to Home from a state of home does this. So there is something a bit amiss in the Home routine on the NexDome side most likely. Done manually..meaning I push the Home button in ACP there is no problem because I can then hit Stop Slew.. But! In a script the situation is fatal! In that case the script hangs and the slew is also pending.. So one has to be there to first abort the script and then kill the slew. I would of course be asleep so these sorts of hanging issues cannot be allowed to happen. I have workarounds with a small cost that the charging tabs might be a tiny bit off. I can just look in on my webcam or if I power up the dome look at shutter battery level to deduce if it is likely on the tabs or not.

 

The dome is not moving for any of this. Worse of all it means that a client automation like ACP cannot do the right thing and set a preference like "Home Dome on first Connect".

 

The fact that in POTH -> Setup -> Rotator the state of the dome such as never homed or at home is shown but somehow that information is being kept to itself. All in all I'm really really happy. We have a few items to clean up is all from my perspective.

 

Shifting the thread here to Tom's problem with maybe the XBee. Might a PC's wifi accidently mess with that if unlucky about channels?

 

Ron

 

 

Oct 14, 2018

I checked the code of the 0.5.2.3 version and if you ask it to home and it sees the home sensor it does nothing (aka it's already home and you ask it to home):

if (_isAtHome == true) return;

So not sure where that extra slew comes from.

It certainly doesn't do this when I test with my X2 plugin for TheSkyX Pro (I send the find home command and check if it's at home and report complete when home is detected and the dome is no longer moving).

In my X2 plugin I have added an option to home on unpark.. and this also works as expected. My code doesn't do anything magic.. it unparks, then do a find home (send 'h#' to the controller). My code does as little as possible and expect the controller to do most of the work (finding home, updating its own state, ...). It would be interesting to see a log of what commands are sent to the dome from ACP (or ASCOM).

The home state has indeed multiple value :

  • NEVER_HOMED (The controller hasn't seen the home sensor yet an is not at the home position, this value is 0) ,

  • HOMED (it has seen home but is not at the home position, this value is 1).

  • ATHOME (the sensor is being detected in the current position, this value is 2).

The XBee doesn't use WiFi per say. The frequency used are also not on any of the official WiFi channel on the 2.4GHz band.

 

I hope this clarifies some things.

That being said, with that extra slew on home, I agree that automation is going to break and we should try to find what's going on there.

Oct 14, 2018

Thank you for looking at the code Rodolfo. I agree I need to find what ACP sends. Fortunately I can get away fine without having to home as part of the automation in the meantime. Yes you clarified a lot in my mind and taught me useful items at the same time.

Oct 14, 2018

Er so sorry! Rodolphe!!

Oct 14, 2018

Hello Rodolphe,

 

could use please point me to which file/files _isAtHome is located? I do not find it in the PDMrotator.ino or in hte first few of the PDMDome files I searched.. It's kind of hard to get started.

 

Best,

Ron

Oct 14, 2018

the line I referenced above ( if (_isAtHome == true) return; ) is at line 456 in RotatorClass.h

bool _isAtHome;

is defined at line 165 in that same file.

 

Oct 14, 2018

Thank you! I see that at line 474 in the file I am looking at.

I have a question. Should the line be if(_isAtHome == true) return ATHOME; ??

Oct 14, 2018

No, this line is exiting the StartHoming() function.. it's not supposed to return anything (the function is of type void).

The way it works:

- 'h#" command received, start the homing process by calling StartHoming(). This will either return immediately if the dome is already home, or set _seekMode to HOMING_HOME if not.

- The Run() function is call from the loop fonction in PDMRotator.ino . This function check the _seekMode against some values, one of them being HOMING_HOME :

if (_seekMode == HOMING_HOME && digitalRead(HOME_PIN) == 0) // We're looking for home and found it

This is line 692 in RotatorClass.h . If the above is true, the code issue a Stop() call and reset some variable.

The code then check to see if the stepper is still running ( if (stepper.isRunning()) return; ) and exit if it is.

If the stepper has stopped, the code recheck for the home sensor ( if (digitalRead(HOME_PIN) == 0 ) // Not moving but we're at home ), and set some variable if that's true, including _isAtHome = true;

So if the motor has gone too far and stopped the code above is false and doesn't report that the dome is not at home.

 

New Posts
  • This is the process i go through to get to the speed settings for the shutter, so a few questions: First I open ascom dome control panel I click connect. Of course it doesnt let you change values unless its disconnected, so i disconnect and reopen the nexdome ascom server monitoring window, hit setup: Seems no matter what values i put below, here 600/1500 etc, the speed of the shutter is the same. I had tried lowering these at first to see if it would help with the motor sticking. Is this the right procedure to lower the values and test? Also, i know there is a much longer thread here about updating the firmware on the shutter/rotator, but, what does the update firmware button here do? At one point i clicked it when only the rotator was connected, it claimed it updated? How do i know if i even need to update either? Both came brand new recently? Thanks in advance
  • I've completed the motor install (although i may be missing parts on the motor related to this, the set key that holds the pin in place was missing, found an m4 for now that seems to hold it but the pin doesnt go in fully, see this thread for more details) https://www.nexdome.com/forum/observatory-automation/shutter-motor-missing-key-set-screw-locking-pin-wont-go-in-fully-track-shredding First issue (or maybe not), when i push the motor and it moves up, i think when the panel that has the band through it goes under the first panel, half way up, it sticks for a half second, flexes and pops and keeps going. After this at times on the way up, even during the first half, sometimes the motor stalls briefly. The biggest issue is after its up fully and you bring it down, the first 16" or so going back it stalls and moans repeatedly, however, interestingly i can work it forward by doing an on off real quick multiple times, OR by pressing upward on the motor. Here is a video clip of the stalling (most of it near the end): https://www.youtube.com/watch?v=nCtvALmB6zU At this point i took all the wheels off the rear, added washers, so now they have quite a bit of flex available. The retention bracket is installed, but i had my son work the motor while i pulled back on the bracket and wheel on one side only, no change. When you pull the panels in the rear when its up there, apart, you can see grinding marks on each panel on the sides. So at this point i'm left with removing the retention brackets on both sides as a final test, and to be able to get the panels apart to add antifriction tape someone recommended. It appears the front panels will need to come off (not the rear solid non moving one), then apply tape as here: Here is an external view of the situation: https://www.youtube.com/watch?v=rNHI3KzOkbw This is the antifriction tape i've ordered (1" x 15 feet, two rolls,TapeCase 423-5 UHMW) : https://www.amazon.com/gp/product/B00823JF0S/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&psc=1 I dont know what else to try, other than what i have planned at this point. Pretty frustrated. Incidentally, i have the inside dome rotation working pretty solidly, so this is the only sticking point, pun intended. Thanks in advance.
  • Im breaking my shutter issues into multi parts here, in this one, i seem to be missing the set screw on the part by the gear as in this image: The part circled was naturally coming out. I'd like to get the official part to fix this, however in the meantime i've added what seems to mostly fit but not flush, m4 set screw and the locking pin goes in a tad further: Any suggestions here? From someone else, it appears that pin should slide all the way inside (i dont know if this could be related to the motor stalling/sticking issue i have (sep thread))