EQMOD and park issue

[swag72]

I mentioned in another thread that there was a problem with the mount no longer responding to EQMOD movements via the handset and serial adaptor. I was hoping that with a proper cable this would be sorted out. Anyway, it's still an issue, so I wonder if anyone has heard of this and can help.

I am now using the Shoestrind USB cable. The mount has been slewing around happily using the handset to get final alignment, as well as general checking etc. Everything has been slewing well for about 2 hours in total.

SO then I decide to set a park position for when the roof is closed. All fine. Then when I unpark by pressing the 'unpark' button and then slew to a target, the mount does a quick groan and then that's it. It won't move with the gamepad either.

I have now realised that this only happens AFTER I have put the mount into park. So I switched off the mount and CdC and restarted it all, but no joy, the same thing.

So I've packed up for the night, and will have a go tomorrow at unparking. But as it stands at the minute, the mount seems to stop responding to the gamepad and CdC in general once the mount has been parked. I have to say that thinking about it I didn't try to slew with the EQMOD keys on the PC.

Prior to this I was able to revert to the handset and everything moved fine. So I am absolutely 100% happy that the issue is NOT with my mount. As it ONLY seems to happen after a move to the park position (defined) I think it's a software issue?

I would welcome your thoughts on this as apart from this I have to say that it's all worked fantastically well and I'm glad I tried it. Never thought I'd be saying that!!!

[perfrej]

Parking with EQMod is a random event. I have found that unparking from the driver connection dialog instead of from the pad window is more reliable. My problems have shown themselves when I start my session, unpark and then try to slew somewhere. "Illegal while parked"... Park it from the connection dialog and it will say "Already in the desired state", after which you can unpark it from ther and then everything works.

What do you think? Related problems?

/per

[swag72]

Cheers Per, I'll look at that if I need to tomorrow.

So maybe there is some kind of 'park' glitch?

[swag72]

Have been out this afternoon, switched on the mount and CdC, connected the telescope, unparked it than it slewed around on the gamepad quite happily, and would park and unpark again with no problems.

Interesting and annoying - Although not something that will be a problem or noticeable even if I park at the end of a session and unpark the following night. Perhaps this is a problem that is around, but as most people don't park and unpark and expect it all to go again straight away, it's not something you'd notice. Indeed, I'd not have noticed it had I not been trying to set a park position prior to watching Chris' video!

[chrisshillito]

Hi Sara,

Sorry to be late picking up on this one. I'm can't say I'm aware of any general park/unpark issues - no such issues reported to the EQMOD group recently.

Just to be clear: what happens is you park, then unpark, then issue a slew but it fails and the mount doens't respond to gamepad movements either. Does it respond to slews form the EMQOD user interface itself? The mount hasn't parked itself again has it? (an emergency stop would do this). Next time it happens have a look in the EQMOD message center and see what messages have recently been posted there. Also, try disconnecting CDC from EQMOD and reconnecting and see if that has any effect.

Given that its working ok today I wonder if it only happens at night when other equipment / software is active

Chris

[swag72]

Hi Chris - I'll have a look at this tonight again - Correct in that I park and unpark and issue a slew and there is no response and the gamepad won't control the mount either. I will try the EQMOD interface to see if that will slew. And do as you suggest with disconnecting from CdC and trying again.

When I went out there this afternoon, I parked it and unparked it numberous times and the gamepad continued to work. It onlt seems to be an issue after a period of time.

Anyway, hope to report back tonight. Thanks for answering and looking at it for me.

[swag72]

Out again thie evening and the same happens. Look around and for some reason it was hitting a 'limit' when I took it off park and told it to slew to Jupiter. Unticked the limits and went fine!

So I must have my altitude wrong of something as it thinks it's below my horizon. I can live without any limits at the moment.

Thank you Chris!!

[chrisshillito]

Ah, that makes sense. I did think about limits but had assumed you would have noticed EQASCOM flashing "LIMIT" at you I guess you keep it minimised.

The limits define the known safe operating region for the mount. If you initiate a slew from an out of limit position then, yes, EQASOM will immediately perform either an emergency stop or a park to your active park position (depending on how you've set up the limits). The emergency stop is itself a park at the current position and this would explain why CDC could no longer command the mount.

The solutions are many :

1. remove the limits.

2. Keep the limits but after unparking manually slew the mount back to a within limits position before initiating a goto.

3. Keep the limits but define an unpark that moves the mount back to an in limit position.

4. Set the mount limits to match the available range of movement you have and provided the park falls within that range there will be no problem.

Chris.

[lukebl]

If you're permanently mounted and using EQMOD and CdC, I just wonder why you feel the need to park the scope at all?

I just turn my scope off at the end of a session, without bothering where it's parked. Next time I use it, I just loosen the clamps and swing it back up to roughly align it, then turn it on and do a single 'slew' and 'sync'. I used to get hung up about parking it, but realised that if it's permanently mounted and properly aligned, then it takes no time to do a quick single-star sync at the beginning of a session and away you go. Even observing things in the daytime isn't a problem, as you can use the sun (screened, obviously) or the moon to do the single-star sync.

[swag72]

I hadn't explored that possibility Luke. I just assumed that I would have these loads of alignment points along the way and I'd park the scope to remember them and just unpark at the start of a session and it's ready to go.

This is all new, so I'm sure I'll change my methods over time!!

@Chris - Yep keep it minimised, didn't notice the 'flashing limit'!!!!

[chrisshillito]

If you're permanently mounted and using EQMOD and CdC, I just wonder why you feel the need to park the scope at all?

I just turn my scope off at the end of a session, without bothering where it's parked. Next time I use it, I just loosen the clamps and swing it back up to roughly align it, then turn it on and do a single 'slew' and 'sync'. I used to get hung up about parking it, but realised that if it's permanently mounted and properly aligned, then it takes no time to do a quick single-star sync at the beginning of a session and away you go. Even observing things in the daytime isn't a problem, as you can use the sun (screened, obviously) or the moon to do the single-star sync.

Well that's an interesting twist on things . If you're going to do things that way you would have to use "dialog mode" alignment to ensure the sync just shifts the existing model rather than adding a new point. Observing thing sin the day won't be a problem at all if you parked the previous night and I really wouldn't ever recommend using the sun, moon or planets as sync points.

Personally I would recommend that folks with permanently sited mounts use the Park and Unpark procedure (many with roll off off observatories will need to position the mount in set position at shutdown anyway). Parking not only ensures that the alignment model and PEC remain in synch over power down but it is also, as Sara has found, is a "safe state" whereby other applications cannot trigger moves, slews or tracking without first unparking (and usualy this requires some user intervention).

Chris.

[chrisshillito]

@Chris - Yep keep it minimised, didn't notice the 'flashing limit'!!!!

Ah, in that case perhaps you may want to consider assigning some sounds for the "parking", "parked", "stop" actions etc then EQASCOM will be able to tell you what its doing even if you can see for yourself. wav files of all the necessary phrases (English only) can be found here

Chris.

[lukebl]

Well that's an interesting twist on things . If you're going to do things that way you would have to use "dialog mode" alignment to ensure the sync just shifts the existing model rather than adding a new point......

I fear you've lost me there. All I know is that a quick single-star sync in CdC on startup works perfectly for me, so I don't need to park it. Everything after that is perfectly on target, although I usually sync every time I move to an object to refine it. I don't feel the need to make things more complicated than they need to be, but would welcome advice as to what I'm missing here!

[chrisshillito]

Hi Luke,

Perhaps I've misunderstood what you're doing. I had assumed that you as you have a permanent mount you would be saving you alignment model and re-using it each night. Perhaps you don't and start afresh every night and that initial sync is simply th efirst alignment point in your new model rather than an attempt to resynch an existing model (which is what I assumed you were trying to do)

The benefits of Parking and Unparking are that it allows you to load up a previously saved alignment model so your gotos are accurate right from the start. This doesn't make things more complicated - it simplifies things by removing the need to re-align every session. What's more the saving and loading of the model can be configured to be automatic so you just power up, unpark and go.

Chris.

[swag72]

Chris, can I ask - Will the alignment be more accurate the more alignment points you have?