Primaluce ARCO rotator

Sequence Generator SGPro Support
#1

Hi,
I am using the latest stable SGP, Sequence Generator 4.0.0.700 (64-bit).

Equipment: 294MM, EFW, ESATTO,ARCO, RC8, Avalon Linear. ESATO and ARCO using firwmare 3.0

Everything is working fine except the new added ARCO. I am using the latest firmware and the rotator connects. When I go to platesolve, SGP moves the rotator to X angle, takes the plate solve image (rotator still moving) and even if I abort the platesolve, the rotator doesn’t stop until I stop it from the control panel (other tab).

I tested the rotator with another software, using the same platesolving software (astap), and the rotator is functioning flawlessly. Obviously, I would prefer to keep using SGP. I also tried the latest beta and the issue is partially solved (usually image taken when the rotator stops), but it never finds the correct rotation. I.e. rotation error 70 degrees, next step it will be 90, then 75, then 130, etc…

Here are some logs: sg_logfile_20220212012626.log - Google Drive

#2

In beta 4.1, we have made some changes to the way we handle rotators. Can you please give that a shot. The beta for 4.1 is very close to release and is pretty stable at this point.

https://www.sequencegeneratorpro.com/downloads/#1589668528967-44caedd2-746d

#3

Hi Ken,
I tried Sequence Generator 4.1.0.740 (64-bit), which is the release where SGP at least waited for the rotator to finish, but it was moving it in all sort of directions and never getting close to target.

I think the logs I’ve shared were from Beta actually. The non-beta, it just continues taking platesolving images while the rotator is moving (and never stops)

#4

They were from the beta, but from a beta that does not have the changes for the rotator I referenced (in beta 742)

#5

Hi,

Can anyone confirm that this new version solves and Arco issue ?

#6

I am still waiting for clear skies to do the test, currently hit with a storm for another week or so. I will report back if the latest beta solved my issue or not

1 Like
#7

Unfortunately the rotator is not usable with SGP still, even with the latest beta. I tried PLL ASCOM 3.0 driver as well as the unreleased 3.1 from PLL. As soon as I connect the rotator it starts to rotate for no reason.

I stop it, platesolve so it updates the current angle, then platesolve one of the targets, it never stops rotating while it goes ahead and takes an image, I have to stop it again manually. ASCOM logs attached: https://drive.google.com/file/d/1A0Ye1eYjPUGUwvQnjatcivQTHsbSu5JE/view?usp=sharing

#8

We can take a look, but ASCOM logs may be better interpreted by PLL. In any case, we would also require the corresponding SGPro logs over the same period.

#9

I sent the same logs to PLL. Here are the logs from sgp, fresh install, only used it for the test: https://drive.google.com/file/d/1z8WaqukiKpmQYTWfsw0CVz36ySOBca1u/view?usp=sharing

#10

Im not certain exactly what the problem is, but I know where it’s coming from and we can use an alternate method to check if certain rotator functionality is supported. Changes will be in the beta released a bit later today.

I should note that there is actually probably a PLL bug in the driver initialization, but I can’t be certain. The old method would test a rotator’s ability to move to a mechanical position by requesting the rotator moves to the current mechanical position. This should be a net 0 movement in all cases, but the fact that it is not seems fishy. That said, I think we can get away with not doing this during connect.

#11

If it will be available in the next couple of hours then I can test it, or it will be early next week till we get a clear night again.

I suspect the issue is from their end, and I’ve provided them with the logs. But, another SGP “alternative” is working fine without any issues with their 3.0 driver, and not so fine with the 3.1 beta driver.

In any case, I hope we can get to the bottom of this with SGP, feels like home :slight_smile:

#12

PLL released a new ASCOM driver which I’ve loaded (3.1, newer than the beta I had) but unfortunately it is still problematic. I tried it with the latest 2 Beta and the stable SGP. It doesn’t take an image while rotating anymore which is good, but it is not finding the right angle. I tried several also reverse corrections (not something I needed with the other software, but just for testing).

Note that this is working fine with NINA still.

SGP logs: sg_logfile_20220325183746.zip - Google Drive

ASCOM: Logs 2022-03-25.zip - Google Drive

#13

I dont understand what you mean by “not finding the right angle”. What is the observed behavior? Are you attempting to rotate to a mechanical angle or rotate to a target (sky) angle? What happens during manual control of the rotator? In the beta, in the Rotator control area, two different angles are displayed.
Is one of those angles the desired angle? Maybe they are switched? Understanding this will help us to parse the log file.

#14

All my tests are during platesolving. The issue before was that SGP would take an image while it was rotating, or it starts rotating as soon as I connect the rotator. This is not happening anymore, it seems to be fixed, I think by the new PLL driver.

However, “center and rotate” is moving the rotator inconsistently. Let us say I start with 70 degrees error, then it goes to another attempt, 50 degrees error, then 20 degrees, then again 90 degrees. It’s all over the place. I abort the “center and rotate” but it hangs and the rotator keeps moving and I have to unplug it to stop.

#15

I am trying to read the logs, not sure if I got it right. I did a manual platesolve:
[03/25/22 19:09:15.738][DEBUG][Telescope Thread][PS;] Syncing the rotator to 89.68 degrees…
[03/25/22 19:09:15.814][DEBUG][Telescope Thread][PS;] ASCOM Rotator: Sync complete. Camera angle is 89.68; Reported rotator position: 16.93

then went for “center and rotate”

[03/25/22 19:09:39.644][DEBUG][Telescope Thread][CE;] Performing auto center step 3 (rotator)…
[03/25/22 19:09:39.646][DEBUG][Telescope Thread][CE;] Moving rotator to 101.0…
[03/25/22 19:09:39.647][DEBUG][Telescope Thread][CE;] ASCOM Rotator: Moving rotator to 101
[03/25/22 19:09:39.647][DEBUG][Telescope Thread][CE;] ASCOM Rotator: Sync offset is 72.75

[03/25/22 19:09:49.216][DEBUG][Telescope Thread][CE;] ASCOM Rotator: Move is complete. Requested 101; arrived at 101

I think after that you can see that it never hits the right angle until I abort and remove the cable. This is in the last file.

#16

I have verified the numbers and it seems that a request to move your rotator in the clockwise direction is moving counter-clockwise. SGPro identifies your initial target / sky angle to be 90 degrees (and mechanical angle of 17 deg). You have requested a target angle of 101. SGPro issues a command to move to 101 (note that SGPro does not issue relative commands… this is an absolute command to move to 101 deg). The error here (101 - 90) indicates that SGPro should rotate ~11 deg clockwise from 90 to 101. SGPro does indeed move the rotator clockwise by 11 degrees because the rotator now reports 28 deg as its mechanical position (mechanical position moved from 17 to 28). BUT, the next plate solve shows that the rotator, regardless of its reported mechanical position actually moved counter-clockwise because the next plate solve shows your target / sky angle at 78 deg which is exactly 11 deg counterclockwise of the original position of 89 deg.

It seems like there is either an error in the driver or that maybe there is a setting which causes the driver to behave this way (to reverse commands)?

#17

I did notice that, and in one of the other logs maybe, it was going the other way with exact degrees. I think it is the same logs you’ve seen.

I tried the reverse setting in the SGP control panel but it made things worse. The driver doesn’t have any settings to have reverse settings, nor any other settings for that matter. I connected to it with the PLL Play software, the only option is to calibrate it (tried it) and the other software where this works doesn’t require that I set corrections to be a reverse order. I went from the SGP session where you saw this behavior, to the other software and centering/rotating worked fine.

Maybe there is a requirement for the software to get something from the rotator before it issues commands? to know which direction to take? I am just brainstorming out loud, this is beyond me…

#18

One of the differences I can see from the ascom logs.

SGP uses Rotator/MoveAbsolute-set

Other SW uses Rotator/Move-set

examples.

SGP:
19:09:38.526 Focuser/Position-get 307058
19:09:39.100 Rotator/MechanicalPositio requested
19:09:39.130 Rotator/MechanicalPositio 16.93
19:09:39.616 Focuser/Position-get 307058
19:09:39.648 Rotator/MoveAbsolute-set (ASCOM) GoTo 28.25 deg
19:09:39.649 Rotator/MoveAbsolute-set (PLL) GoTo 28.25 deg

Nina:
19:31:31.842 Rotator/Position-get (PLL) ABS_POS -60.88 deg
19:31:31.842 Rotator/Position-get (ASCOM) ABS_POS 299.12 deg
19:31:31.889 Rotator/Move-set req to move by -229.12 deg
19:31:31.889 Rotator/Move-set (PLL) GoTo 70 deg

I am also checking ascom documentation:
Move: Causes the rotator to move Position degrees relative to the current [Position] value.
MoveAbsolute: Causes the rotator to move the absolute position of [Position] degrees.

Also SGP uses Position-get for the focuser but not the rotator (uses mechanicalposition), while other SW uses Position-get for both. If you check the ASCOM logs shared before, the 1908 is SGP, 1931 is the other SW. I hope this helps?

#19

SGPro does not offer an option to reverse rotation direction. In any case, it only uses absolute movement commands so it wouldn’t matter anyhow.

It’s a reasonable thought, but SGPro moves with absolute commands like MoveTo 101 and not relative commands like Move 11 from current position. The rotator is deciding which way to move to get to the position we asked for. It’s worth re-iterating though that the rotator does think it’s in the position we asked for, but it seems to have moved the other direction.

How many mirrors do you have in your imaging train? Is it possible that the images we are plate solving are flipped?

It seems like NINA is using relative movements and determining the rotation direction some other way. I can’t be certain, but a user of the driver should not need to do this… the request to move to an absolute position should be more than sufficient since we let the driver itself determine which way to go.

#20

So the main differences here are the ascom commands, either using relative position VS absolute position. I think we’re getting somewhere. And it seems that the absolute movement is not being handled properly by the driver? Maybe it doesn’t support absolute changes and only handles relative changes? I dropped an email to PLL about this update.

Is it possible to have a solution from your side meanwhile? Maybe a setting to choose between absolute and relative?

I am using a TS Optics (GSO) 8" RC.