PDM Driver Homing Issue

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.

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; ??

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.

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

Er so sorry! Rodolphe!!

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.

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

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

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

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

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

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

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();

}

}