×

INDI Library v2.0.7 is Released (01 Apr 2024)

Bi-monthly release with minor bug fixes and improvements

EQMod : "Can not change rate while motor is running (direction differs)."

  • Posts: 24
  • Thank you received: 1
I've just had a look and there's quite a few read errors on mine too. Sometimes just before the spike and some not. Communication error in the eqdirect wire? Could also be voltage drops from psu? What psu are you both using?
3 years 5 months ago #63658

Please Log in or Create an account to join the conversation.

  • Posts: 535
  • Thank you received: 109
Initially, I had a 10A medical grade PSU that I used to run everything except the dew heaters. I later moved the mount to its own PSU as well, and have been running with that dedicated PSU ever since. Looks like I should put a voltage meter on it. It sure would be nice if the mount would report voltage.


All of the entries in the syslog are from the ASI camera usb port, and they are WARN of reset. I will open this in another report, because I don't think it should be happening after every exposure, but it does not seem to be hurting anything. They are consistent as well; as long as there are guider images coming in, there are the USB reset WARNs.
That is it though. There are no other system/OS reported USB errors to go along with those timeouts that INDI is reporting as a COMM error. It has become pretty apparent though, that these are the cause of the large spikes and failed guiding. If there were a cable or port problem, I would hope there would be an error indicating such.

Other notes:
My issues seem to be primarily in RA. Any time the mount "drifts away" DEC looks fine, but RA RMS goes high.
The direction that RA goes does not seem to matter. It has drifted both positive and negative, so doesn't seem like "drift" in that case. It seems more like a correction was issues and it times out trying to stop it, so the correction keeps going.

Edit: I looked last night and the current supply is a 12v 5A supply, dedicated to the mount.
Last edit: 3 years 5 months ago by Jim. Reason: more info and observations
3 years 5 months ago #63660

Please Log in or Create an account to join the conversation.

  • Posts: 535
  • Thank you received: 109
I need to come back to this thread, because that last evening, two nights ago, was quite frustrating. I checked the connections, everything seems tight and clean. The power supply is a regulated 12v 5A, which should be more than enough, but it could be getting weak. To address that, I just bought a 13.5v 90w medical grade PSU, and the custom GX12-2 connector to solder directly to the PSU to get rid of any connections on the way to powering the mount. While this might not be the solution, at least it is one less thing to worry about. The other thing that could be a problem would be the EQdirect cable, and I do have a spare that I will try, but if that was faulty, I would expect that there would be more problems than just this one. That statement goes for the PSU as well. At this point, it feels more like timing issues in talking to the mount than it does hardware. It looks like a few clear-ish nights coming up, so will keep trying.

@knro, any thoughts on this ?

Any updates from other eqmod users that have had problems with timeouts?

Jim
3 years 5 months ago #63761

Please Log in or Create an account to join the conversation.

  • Posts: 11
  • Thank you received: 0
Well, we have drifted away from the initial subject ;) But since you're asking, I've faced many, many issues with the EQMod driver and kstars/ekos. At the point where it is sometimes barely usable and I lost tens of minutes if not hours of valuable time trying to make the mount answer my godamn orders correctly.

For instance, almost every time I use the "Sync" context menu item from kstars, the mount refuses to move afterwards. Strangely enough, using sync from the alignment module or the mount control does not produce this behavior.

Also sometimes the mount would move in the opposite direction of where it's supposed to go. When it does, the scope pointer in kstars is generally doing some crazy stuff, like going "out" of the sky or jumping from one point to another part of the sky for no reason. The only thing that works in such situations is to completely reset the mount to factory settings using the synscan remote **and** purge configuration data. Sometimes even a reboot is needed despite the previous steps.

One time also, kstars refused to set the mount to a precise coordinate. When moving the mount, the coordinates were just "jumping" above a few arc minutes while the mount itself was moving normally. Again, a complete factory reset / configuration purge did the trick.

There is probably more to it I can't remember...
Last edit: 3 years 5 months ago by Bertrand Lemasle.
3 years 5 months ago #63768

Please Log in or Create an account to join the conversation.

  • Posts: 535
  • Thank you received: 109
My bad. I was looking to keep it in the context of the initial subject of guiding. It does sound though, like you should be opening another post for some of the other errors. I have not tried `sync` from the context menu, but I do not have the other problems you speak of.
3 years 5 months ago #63774

Please Log in or Create an account to join the conversation.

  • Posts: 535
  • Thank you received: 109
Without even starting tracking, the mount is throwing the COMM errors. Hoping it is a bad cable at this point. I do happen to have a spare. Going to change it out. I am using a EQdirect type cable.

<code>[2020-12-03T20:01:25.396 CST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[COMM] read error, will retry again... "
[2020-12-03T20:01:34.795 CST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[COMM] read error, will retry again... "
[2020-12-03T20:03:25.696 CST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[COMM] read error, will retry again... "
[2020-12-03T20:03:31.770 CST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[COMM] read error, will retry again... "
[2020-12-03T20:04:20.921 CST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[COMM] read error, will retry again... "
[2020-12-03T20:05:24.364 CST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[COMM] read error, will retry again... "
[2020-12-03T20:06:24.481 CST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[COMM] read error, will retry again... "
[2020-12-03T20:06:38.370 CST DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[COMM] read error, will retry again... "
</code>

At this point though, the subject of the initial post about the (direction differs) warnings seems to be related to the guiding settings vs the INDI mount eqmod settings. After I made the adjustment to the eqmod settings, I do not see those warnings anymore, just the timeouts.
Last edit: 3 years 4 months ago by Jim.
3 years 4 months ago #63837

Please Log in or Create an account to join the conversation.

  • Posts: 535
  • Thank you received: 109
I may have finally resolved the timeouts last night. It entailed moving equipment to different USB ports. There was something strange about my combination of devices on a USB bus, so re-shuffling them made the error go away. When the timeout went away, so did the nasty guiding spikes. The (direction differs) seems to just be a warning that a large guiding change was requested in a reverse direction. I hope this is helpful for you both.

Jim
3 years 4 months ago #63922

Please Log in or Create an account to join the conversation.

  • Posts: 11
  • Thank you received: 0
It could, be there is definitely something wrong with the driver/PHD2.

I bet you'll stumble across the warnings again doing a PHD2 star-cross test (even without actually shooting, just do it inside during daylight). The reason for it seems to be that a call to StopMotor is issued, but StopMotor does not wait for the motor to actually stop and returns immediately.

PHD2 then tries to reverse direction, which fails because the drivers still thinks (and it's probably right) that the motor is running (DERunning haven't been updated since the command was issued). That mess the star cross test every single time on the last part (returning to the original position on the DEC axis) and skips every step. So far I've seen this on two different mounts.

I'm not sure whether the problem is with the driver itself or commands issued by PHD2. I haven't been able to trace the call back in PHD2 code.

So to me, these are two different issues.
Your read errors can certainly be attributed to miscommunication as, in your case, maybe ReadMotorStatus was failling and so DERunning was not properly updated during guiding.
The star cross test on the other end is easily and consistently reproducible and pinpoint to either a driver issue or a misuse from PHD2.

Glad you've sorted it out though :D
Last edit: 3 years 4 months ago by Bertrand Lemasle.
3 years 4 months ago #63927

Please Log in or Create an account to join the conversation.

  • Posts: 24
  • Thank you received: 1
Did you end up sorting the issue? I reckon it's the cable and comms issues with it. I'll see by connecting my hand controller usb instead of the eqdir cable

Another thing I notice is that the align point randomly moves then back to the target itself at times. Sometimes that causes it, other times not

Edit: Oops, I didn't read your latest post. My bad lol. I've personally tried shuffling the ports about but to no avail
Last edit: 3 years 4 months ago by Matt Baker.
3 years 4 months ago #64600

Please Log in or Create an account to join the conversation.

  • Posts: 535
  • Thank you received: 109
github.com/indilib/indi-3rdparty/issues/358

A better analysis of the problem than I did. I may have had two problems, but the research here is certainly worth a read.

Jim
 
3 years 1 month ago #69297

Please Log in or Create an account to join the conversation.

  • Posts: 11
  • Thank you received: 0
Hi,

Thank you very much for the update and the investigation.

I somehow didn't get the notifications from Cloudy nights forums.

I gave up on the issue after that thread being dead (and the one on cloudy nights too) and was using ST4 guiding since then.

Thank you again !
3 years 1 month ago #69380

Please Log in or Create an account to join the conversation.

  • Posts: 24
  • Thank you received: 1
I've just tested the latest nightly build after seeing the changes merged on GitHub and can confirm that the initial results are very promising.

I haven't done a lot of imaging recently due to having to throw away a lot of exposures due to the "backlash" issue. One of my problems was actually related to my PSU which I upgraded to 13.8v, and now that's fixed.

I was imaging a couple of nights ago on the latest stable update and that reported 6000ms of backlash, now with the fixed driver, I get 1500ms and the star cross test works but produces a lowercase t shape which I'm not sure about.

Matt

 
Last edit: 3 years 3 weeks ago by Matt Baker.
3 years 3 weeks ago #69943
Attachments:

Please Log in or Create an account to join the conversation.

Time to create page: 2.490 seconds