×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

Digital Dome Works - does this work?

  • Posts: 472
  • Thank you received: 165
Hm, the log doesn't show the sequence I was expecting, it should have printed "Dome already moving, latching the new move command" and not "Please stop dome before issuing any further motion commands." which comes from the base class. Have to trace things a bit more as I haven't had this issue with my own dome (different driver, but also mine). Might be I'm not resetting some state correctly when the motion ends.
3 years 1 month ago #66912

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

  • Posts: 472
  • Thank you received: 165
3 years 1 month ago #66931

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

  • Posts: 126
  • Thank you received: 2
Ran some tests with your last night's drop and my telescope. Telescope was just about dead centered in the slot all around the sky.

On several occasions, as the dome neared the scope az (say a couple of degrees), it would complain about not being able to sync with a constant flow of error messages. It then occurred to me to raise the sync parameter in the dome slaving page from 1 to 5 degrees. After that, syncing was no longer a problem. Still had to abort the dome before moving the scope.

I'll give your latest a test in a bit.

Bob
3 years 1 month ago #66935

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

  • Posts: 126
  • Thank you received: 2
Looks like we took a step back.

I kept getting the message "WARNING Unknown shutter status" whenever I attempted to slave the dome to the scope. The log would say "dome moving to <some az> but the dome would never move. I could move the dome manually via the az setting.

One other thing I noticed is that the DDW manual says the control box attached to the dome will issue beeps before executing a command. I had not heard those beeps until this code drop. I do hear them when using the DDW supplied software.

I don't think it should make a difference. However, my gear box threw its chain today. I thought I was toast. Luckily I got it reattach. No wiring was involved.

If you find the reason for the dome warning let me know. Another thing I can try is to re-install you build from a couple of days ago and see if things work as before. I got carried away tonight and blitzed it by mistake.

File Attachment:

File Name: dome5feb.log
File Size:40 KB
3 years 1 month ago #66942
Attachments:

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

  • Posts: 472
  • Thank you received: 165
The unknown shutter status warning is a "feature" of the controller which I didn't expose before, it reports the shutter status as open/closed/unknown. Upon reboot it doesn't seem to know the status until an open or close command has been issued and completed. I'm not sure what I should do about it, but at least I can make it less spammy by not setting the state to the base class if it already is the same so it would trigger the print only once. But there also seems to be some bug in there as the status should be valid after you have opened and closed the shutter but the warning is still printed. From the log it seems the status numbers are incorrect in the documentation.

After opening:

DEBUG 127.478333 sec : GINF packet: V4,690,25,3,29,0, --> 0 <--,1,0,20,31,0,128,255,255,255,255,255,255,255,999,3,0

After closing:

DEBUG 1151.965279 sec : GINF packet: V4,690,25,3,25,0,--> 1 <--,1,0,20,31,0,128,255,255,255,255,255,255,255,999,3,0

but documentation says:

/* GINF packet structure:
Field Content Note (each datum is separated by comma)
1 V# Denotes Version Data. E.g., V1
2 Dticks DTICKS is dome circumference in ticks 0-32767. Value is sent as a string of characters, e.g., 457. Leading zeros not transmitted.
3 Home1 Azimuth location of the HOME position in ticks 0-32767
4 Coast Coast value in ticks (0-255)
5 ADAZ Current dome azimuth in Ticks 0-32767
6 Slave Slave Status 0=slave off 1=slave on
7 Shutter Shutter status 0=indeterminate, 1=closed, 2=open <---
8 DSR status DSR Status 0=indet, 1=closed, 2=open
9 Home Home sensor 0=home, 1=not home
10 HTICK_CCLK Azimuth ticks of counterclockwise edge of Home position
11 HTICK_CLK Azimuth ticks of clockwise edge of Home position
12 UPINS Status of all user digital output pins
13 WEAAGE Age of weather info in minutes 0 to 255 (255 means expired)
14 WINDDIR 0-255 wind direction (use (n/255)*359 to compute actual direction), subtract dome azimuth if weather module is mounted on dome top.
15 WINDSPD Windspeed 0-255 miles per hour
16 TEMP Temperature 0-255, representing -100 to 155 degrees F
17 HUMID Humidity 0-100% relative
18 WETNESS Wetness 0 (dry) to 100 (soaking wet)
19 SNOW Snow 0 (none) to 100 (sensor covered)
20 WIND PEAK Windspeed Peak level over session 0-255 miles per hour
21 SCOPEAZ Scope azimuth from LX-200 (999 if not available)
22 INTDZ Internal “deadzone”- angular displacement around the dome opening centerline within which desired dome azimuth can change without causing dome movement.
23 INTOFF Internal offset- angular distance DDW will add to the desired azimuth, causing the dome to preceed the telescope’s position when a slaved goto occurs.
24 car ret
25 car ret
*/

So I think I'll change that to match what the hardware actually sends instead.

Beeping I'm don't know anything about, haven't done anything to produce those or not, I just send commands :)

As for slaving I'm not sure what the problem is as it seems to always calculate the scope azimuth as 0 in your log and thus not move anywhere:

DEBUG 247.678610 sec : JD: 2.45925e+06 - MSD: 11.4864
DEBUG 247.678695 sec : MC.x: 0 - MC.y: 0.07 MC.z: 0.34
DEBUG 247.678723 sec : HA: 6.00029 Lng: -107.985 RA: 334.307
DEBUG 247.678808 sec : OTA_SIDE: -1
DEBUG 247.678832 sec : OTA_OFFSET: 0.33 Lat: 32.4878
DEBUG 247.678852 sec : OC.x: -2.48124e-05 - OC.y: -0.10725 OC.z: 0.0616431
DEBUG 247.678874 sec : Mount Az: 0 Alt: 32.4878 <
DEBUG 247.678892 sec : OV.x: 0 - OV.y: 0.843506 OV.z: 0.53712
DEBUG 247.678917 sec : Calculated target azimuth is 360.00. MinAz: 336.84, MaxAz: 23.16
DEBUG 247.678938 sec : MoveAbs (359.998827)
INFO 247.678976 sec : Dome is moving to position 360.00 degrees azimuth...
DEBUG 247.679024 sec : Dome is syncing to position 360.00 degrees...

There aren't any snooping messages either so probably something to do with that or with slaving parameters. Also I didn't do any changes that would change these calculations lately (and they are made in the base class anyway).
3 years 1 month ago #66964

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

  • Posts: 126
  • Thank you received: 2
OK. It was kinda of windy last night and what I have been doing is opening the shutter just a little before starting the dome exercises. So let me try running the test with the shutter either completely open or closed.
3 years 1 month ago #66966

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

  • Posts: 472
  • Thank you received: 165
Ah, that would explain it, as the controller doesn't then actually know the state of the shutter if it's in between. I already pushed an update that changed the value,but I reverted it now. But now I avoid sending the state multiple times so it doesn't print that warning more than once. Pushed to github.com/jpaana/indi/tree/ddw_shutter_state_fix and github.com/indilib/indi/pull/1349
3 years 1 month ago #66968

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

  • Posts: 126
  • Thank you received: 2
Opening the shutter all the way eliminated the Shutter Unknown state problem. However, still have to abort the dome before issuing the next Tel Sim go-to command.
3 years 1 month ago #66970

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

  • Posts: 472
  • Thank you received: 165
Ok good. The slaving issue is a bit harder to figure out as the movement state should now be correct. Could you take logs of both the dome and scope for this sequence:

- starting both from park state
- unpark dome
- unpark scope, dome might move to match the scope azimuth, wait until it reaches target
- slew to somewhere south-west-ish
- wait until scope is idle and if dome doesn't move with the scope, hit abort if that helps
- wait until both scope and dome are idle
- slew to somewhere south-east-ish (scope should flip, dome shouldn't go around but use the shorter route)
- again wait until scope is idle and hopefully dome has followed
- park scope first, wait until it has parked and then park dome

The KStars log would be nicest as it has both device logs in the same file and in correct order, but separate logs work too.

Thanks!
3 years 1 month ago #66972

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

  • Posts: 126
  • Thank you received: 2
Basically no change.

After opening the shutter, I aborted the dome. When I connected and unparked the tel-sim, the dome went to the scope az. After that, I had to abort the dome before moving the scope if I wanted the dome to follow automatically.

The dome log is partial. For some reason, the log Enable gets reset by I don't know what. I have to remember to go back and check on it every once in a while.
3 years 1 month ago #66974

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

  • Posts: 472
  • Thank you received: 165
If you run KStars/Ekos, it overrides the logging settings done via INDI panel, which is a bit confusing, but you should enable them from the Ekos logging panel:
3 years 1 month ago #66977
Attachments:

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

  • Posts: 126
  • Thank you received: 2
Did you want me to make another test run using the combined Ekos logs before you made a code update?
3 years 1 month ago #67069

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

Time to create page: 2.565 seconds