Merdian Flip Failure CEM60

Sequence Generator SGPro Support
1

Description

I had this trouble before with a CEM60-EC. I would get this SGP error:

ASCOM Telescope: Failed to flip because starting pier side and ending pier side are the same!

To cure this I was instructed to set the CEM60-EC in iOptron Commander to 2° (8 minutes past as 1° sidereal = 4 minutes) past meridian, with flip at meridian behavior as ‘Flip’, not Stop. I then set SGP Auto Meridian Flip at 7 minutes past meridian. This assured that SGP was controlling the flip, and that the target center was surely past meridian. All worked fine.

But now I have a CEM60 (Non-EC) and it repeatedly fails to flip. Same error as bolded above. I have tried 6,7, and 8 minute entries in SGP without success. (I’m testing now, during the day, if you want an idea tried right away.)

The mount WILL flip when it hits the 2° (8 minutes) set in the Commander. But, again, will NOT flip in SGP.

It there something that causes a time miscommunication? My computer and Commander are time synced. The time difference between the mount (and computer) and Commander is less than one second. So I don’t believe it is a time-lag problem.

The mount successfully searches zero. Goto’s after a three point calibration are perfect. I can find nothing that would cause this in the mount or program function. The mount is used so there might have been a pier collision in its past. Would this knock something out if alignment? (As I said, it searches Zero Position successfully and returns there once searched.)

If you happen to use both a CEM60 (Non-EC preferably) and SGP, can you post your settings you have in Commander (or Hand Controller), and SGP? Actually any sequence program’s setting that work would be appreciated.

I have installed all newest firmware, mount and HC. Commander and ASCOM are the latest versions.

The log below is just a simple daylight meridian flip test, coordinating with Stellarium for daylight star crossing the meridian.

If you need anything further, please let me know.

EDIT: I reverted to an earlier ASCOM driver for the CEM60 and the flip went perfectly.
The failed driver is the one included in the latest ASCOM update for iOptron mounts:
iOptron_ASCOM_DriverInstaller5750. This driver passed Compatibility with ASCOM apparently as they have the compatibility file posted.

The (old) driver that I reinstalled and got me working is: iOptron_ASCOM_DriverInstaller5731

The is apparently some mismatch among SGP, ASCOM, and iOptron.

EDIT EDIT: — NEVERMIND! The flips are failing again with that driver installed.

Link to Logs

Useful Info

I am using this profile:

OS: WIN 10 64bit
Ver: SGP 4.0.0.617

2

My CEM60 would not flip , similar messages , I contacted Ioptron support for advice as their web site gave no solutions , and I was running the “latest firmware” , Iopton had a later version that cleared the issue. current firmware

MB 190716
RA 190716
DEC 190716
HC 200113

3

These are the firmware versions I reinstalled yesterday.

And to add to matters, I can’t get a good flip now…even though I had one (and posted above). Back to square one.

Still CAN’T Merdian Flip!

4

Let me add to the mystery. I just got a good flip using an older driver:

iOptron_ASCOM_DriverInstaller5731

But SGP locked up. Might be right on the flip but wrong language in some places. Still looking into it.

5

None of the three drivers mentioned above will flip the mount I have tried numbers from 0 to 8 minutes (CEM60) and 0° to 2° SGP. I cannot get the mount to flip.

I don’t have any other sequencing to try at the moment.

7

I haven’t had any flip issues with my CEM60 (although I do not have the EC version…and this is likely key). With my CEM120EC I had a TON of problems all stemming from bad firmware. It seems that they finally worked them out about a year ago but for approximately 1 year I could not flip the mount with any reliability…

Here are the values I’m running … the firmware and ASCOM driver are likely out of date but given the issues I’ve had in the past I’m reluctant to change as this combination is working quite well with SGP. I’m not sure if these will convey to the CEM60EC or not.

image
image829×455 55 KB

Jared

8

Thanks for the reply Jared.

From my initial post:

“But now I have a CEM60 (Non-EC) and it repeatedly fails to flip.” I have a CEM60 NON-EC. So we’re talking the same mount.

I cannot go that far past meridian (14°) because of pier collision. I have a limit of 2°. But that setting worked before with SGP set at 7Minutes past meridian.

I still fail at all 27 (9 x 3) settings from:
SGP 0 - 8 minutes and Commander 0 - 2°

I have not tried the “Stop at Designated Position” yet. I am not at my pier site so it will be a little while until I can try that.

But WHY am I getting the “Same Side of Pier” error? I am definitely not East Side of Pier (looking West of meridian). My scope is West Side of Pier (looking East of meridian) where any flip is supposed to occur.

Sporadic success (as mentioned in my original post here) only clouds the issue.

As a subscriber to SGP V4, am I to revert to an earlier version?

Can we fix this? Is there any additional info I can provide to solve this?

9

From your log it looks like your mount only took 3 seconds to report that the slew was complete? That doesn’t seem right:

[10/18/20 15:07:59.855][DEBUG][Telescope Thread][SQ;MF;] ASCOM Telescope: Pier side is West
[10/18/20 15:07:59.855][DEBUG][Telescope Thread][SQ;MF;] ASCOM Telescope: attempting pier flip using slew
[10/18/20 15:07:59.858][DEBUG][Telescope Thread][SQ;MF;] Telescope: Slewing to J2000 RA: 15.9278641607723 (15h55m40.31s) Dec: 72.3943206442625 (72°23'39.55")
[10/18/20 15:07:59.858][DEBUG][Telescope Thread][SQ;MF;] Telescope: Slew received J2000 coordinates, mount requires JNOW, converting...
[10/18/20 15:07:59.858][DEBUG][Telescope Thread][SQ;MF;] Telescope: Slewing to JNOW RA: 15.9239222243759 Dec: 72.3383499999986
[10/18/20 15:08:03.048][DEBUG][Telescope Thread][SQ;MF;] Scope reports it is done with synchronous slew, verifying...
[10/18/20 15:08:03.059][DEBUG][Telescope Thread][SQ;MF;] Telescope: Slewing has completed
[10/18/20 15:08:03.059][DEBUG][Telescope Thread][SQ;MF;] Telescope: Settling for 3 seconds
[10/18/20 15:08:06.060][DEBUG][Telescope Thread][SQ;MF;] Telescope: Settling has completed
[10/18/20 15:08:06.561][DEBUG][Telescope Thread][SQ;MF;] ASCOM Telescope: Failed to flip because starting pier side and ending pier side are the same!

It seems like you have SGP set to flip 4 minutes (1 degree) past the meridian and have Wait For Meridian enabled … all that seems good. I’d also set Commander to STOP tracking at 2 degrees past the meridian…but hopefully you wouldn’t hit that case.

From what I can glean from your log it seems that:

  • The mount reports the flip/slew is complete in 3 seconds
  • SGP asks for the side of pier
  • Mount states it is still on the west side of pier
  • SGP determines flip has failed as Start/End pier side are the same

I’m guessing that the driver is reporting that the slew is complete well before the slew is actually done. It’s likely that the flip is even technically successful (eventually) just that the driver is telling us that the mount is already done at the wrong time. Unfortunately there isn’t a lot that SGP can do in this case if we’re getting incorrect data from the driver.

Sadly I have reset my laptop since the last time I used the CEM60 so I’m not even sure what firmware/drivers I was using at the time. I’ll try and mess around with it some evening this week and see what results I get. But I’m guessing it is likely to be firmware/driver dependent if my trials and tribulations from the CEM120EC are any indication.

Jared

10

Thanks for the quick reply Jared.

To be clear, I was doing a number of daylight flip tests so the log you got may not be indicative. Then again, it may be exactly what’s happening. I can provide an actual imaging sequence log if it would help.

It’ll be interesting to see your test results when you get them. As I said, it will be at least a few days before I can get to my pier site. But I’d like to go loaded with alternatives to test.

As I mentioned, I did have sporadic luck dropping back to earlier drivers for the CEM60. I didn’t try (or know if I’m able) to drop ASCOM back. They may have archived drivers on the ASCOM site. And I have previous SGP versions’ install files, so I can try those again. I HOPE it’s not a recent WIN 10 update that is fouling up the works. That’ll be a bit riskier to drop back, but I will if that’s what it takes.

BTW, the CEM60 does flip when it hits the 2° setting, proceeding on from the failed flip.

Thanks again, and keep in touch, please.

Dan

11

As mentioned we see the same weird behavior with complete different setups, it used to work, but due to computer crash I had to reinstall everything, and see the exact same behavior. To make things more bizar, if I reset the sequence, and start the sequence the mount flips, if I resume the sequence, it stays stuck in the flip routine and abondons immediately…
I know it shouldn’t be but one of the changes is going from 3.1 to 3.2 …

12

How does SGP get the mount to flip? The only way that I know of is to instruct the mount to command a slew via the ASCOM driver to a particular RA and DEC. The driver then working with the firmware figures out that the target is west of the meridian. Then, if the mount is east, commands a flip. If that’s correct then this has to be a problem of some difference in time between the PC and the mount. These mounts get their time from the GPS but I think that SGP gets it’s time from the computer.

13

Any progress with your personal tests or ideas on the failed flip Jared?

I appreciate your time…

14

It will be quite difficult to determine the cause of failure without actual logs representing the failure (unless I misunderstood, the logs attached were from daytime test runs). In addition to that, you should also include logs from the mount so we can see the entire story during a failure. Viewing just the SGPro half can often leave more questions than answers.

15

Well…the flips worked fine during daylight tests. Of course, clouds rolled in the defeat any real time testing I could do.

I’ll report back when I do get (or fail) an imaging sequence flip.

I’ll include links to all logs (SGP and Commander) failure or success, to help diagnose failures that might happen in the future.

Here are two links I posted on Cloudy Nights of SGP log exerpts…one failure log and one successful. The failure had SGP set at 1 minute past meridian. The success had SGP set at 7 minutes past (where it had worked before this latest trouble started). Bot had the CEM60 flip set at 2° past meridian.

Failure

Success:

Thanks for your help, as always.

16

As if things couldn’t get more confusing…

Last night (11/1) I ran two targets, SH2-175 and NGC 2359. The targets had Declinations of (+64° 46’ 05") and (-13° 13’ 36") respectively. The RA shouldn’t matter, but they were (00h 28m 58s) and (07h 18m 30s), again respectively.

The first target, SH2-175, failed the meridian flip at ≈ 20:42hrs (DST) including the setting of 7 minutes past meridian in SGP, and 2° (8 minutes) in iOptron Commander past meridian. After the fail I reset the failed sequence and the CEM60 then happily slewed and centered on the target and resumed imaging.

The second target, NGC2359, while I sat at the laptop ready to reset the sequence, successfully flipped at ≈ 04:41hrs (CST…time switch!), including the setting of 7 minutes past meridian in SGP, slewed and centered, and resumed imaging.

ALL SGP SEQUENCE, IOPTRON COMMANDER, and PHD2 setting were unchanged in the least between these two flip attempts. No equipment changes were made (cables, alignment, zero position, balance, etc). I believe it states in the logs that I was using SGP v. 4.0.0.617, but I’ll mention it here.

I haven’t studied the logs yet…(still recovering from hurricane Zeta’s tirade) …though I did read through them and DIDN’T see the “Same Side of Pier” error that plagued earlier attempts.

I am at a loss to explain this.

The SGP, iOptron Commander, and the PHD2 logs for the failure AND the success are here in a zip file (7 logs):

https://www.dropbox…201851.zip?dl=0

Do you see any suspects?

17

Frustrating. Did you remove the alignment data that is stored in the mount?

18

I did clear the alignment and ran the same sequence. (Told ya’ I was going to try everything suggested =^) After that I couldn’t get the scope to plate solve. I reran the alignment before imaging. Got great plate solves and a 50% chance on a meridian flip! If it was the alignment

Frustrating is the word. Hopefully Ken or Jared will see my updated post with the log links.

19

Ken? Jared? Do you have any input on this problem?

20

You have the right idea with the log types you included, but the log file labeled FAILED FLIP sg_logfile_20201101201851.log does not actually attempt a flip (ends at 20:22). Fwiw, that log file does attempt to point the mount at the first target and fails from what looks like a sudden disconnect.

21

Thanks Ken. I’ll be more careful to include the appropriate logs. It will be next week before I can try again. I’ll try multiple actual night time targets that include a meridian flip so we can hopefully determine what’s going on.

I am replacing all data cords with high quality cords to eliminate any connection problems at that point. I’ll get back with new logs.

Thanks for your time.