I imaged again last night with the scheduler, and had logging on, but the while night was successful, and the meridian flip resumed as it was supposed to this time. I'm not sure what caused the issue previously. I still had crashes when trying to take flats. I recorded logs, but not sure which one it is. See attached.
File Attachment:File Name: Archive_2019-09-14.zip
File Size: 59 KB
Scheduler performed ok tonight. It did the flip and resumed guiding. Must have been a fluke the first time.
One other issue I see is that turning off the Fits viewer preference does not seem to save between restarts of KStars/EKOS.
Interesting. I do think something is going on though. I used the scheduler in 3.3.6 last night, and my guiding did not resume after a meridian flip. I had to turn it back on. But the flip went correctly otherwise. I think this is possibly a new bug in 3.3.6.
I ran an image sequence all night last night and experienced a few issues. (I'm on a Mac if it makes any difference).
First thing was setting up the scheduler.
I created a sequence, and manually got my framing correct for the object I wanted to image. I took a sub to use as a plate solve for the scheduler. I went into the scheduler and selected the image for plate solving, choose my sequence and pick startup and shut down procedures, then tried to add it to the schedule. It wouldn't add because there were no RA/DEC coordinates. I had to pick a nearby star for the scheduler to go to first, then it ran the plate solve. I don't think it should run like this.
It should be able to solve the image first, then go to the correct coordinate, and not have to rely on me choosing an object from the database, as this object wasn't in the database.
The second issue during the evening, was the automated meridian flip would not resume guiding after the flip. It did the flip correctly, but I had to manually start the sequence again to get guiding to start and for the sequence to resume.
The last issue I encountered was in the morning trying to take flats after the scheduler had finished. I added a new sequence for the flats, and hit start. I got a crash to the desktop every single time after the first image to save. It will adjust the ADU value, but as soon as it saves one of the images, KStars/EKOS crashes to the desktop. I rebooted, and tried several more times to take flats, and it crashed every time.
I finally loaded up 3.3.4 and took my flats.
Sorry, I don't have logs, I forgot to turn it on! I'll have it on tonight when I run it again. I'll see if it can capture the scheduler resume guiding issue after meridian flip.
My Powerbox V2 just came in. I've yet to try it out. I don't have a good way to mount it yet, but I plan to at least run the cable sand see if it works.
What's the best way to set this up in the profile? Do you set it up as an AUX device? Or do you set it up under focuser?
I believe in the latest version they removed it from the capture module, and it’s now only in the mount module.
Logging is enabled now. At first the button wouldn’t depress to turn it on. But after subsequent reboots and starting KStars again it now appears to be on. I’ll check this afternoon when i’m back home to see what logs are in the folder and post the relevant ones to the thread here.
Ok, after a few more nights of testing, it seems the scheduler will correctly send the goto command for the meridian flip. The nights where it did not flip were coincidental crashes of KStars.
It appears that what was happening in one case, guiding images stopped, then the scheduler automatically stopped before the flip happened. The second time, there was a crash.
When my mount hits the switch axis limits, KStars doesn't know what to do and it crashes. I made an assumption this was from no meridian flip, since I didn't see any flipped images saved, and my mount tracked past the meridian until the limit was hit, and KStars crashed. It appears now that it crashed before it got to flip two nights in a row.
I've since confirmed it can properly issue a flip with the scheduler, as I watched it now twice since this original report.
I still can't explain the video properly, other than I had rebooted the laptop, and started up everything again. Sent a goto command to the mount to an object near the meridian so I could watch it, and that's what it was doing. It should have been tracking properly. So I can't really explain what was going on there.
Despite KStars/EKOS doing really well for me feature wise in 3.3.4, there are still random crashes that are not very easy to explain. I've almost got my setup to the point that I can try the Linux version with a RPi device, and can remove my laptop from the equation. Just waiting on a power device to be able to hook it all up. I'll be able to see if the stability/crashes are related to the Mac or KStars at that point.
A quick update. I turned on logging and decided to run a few tests of objects with the scheduler and meridian flip.
First thing, logs were not being saved. The folder is empty, despite turning on logs.
Second thing, I took a video of the screen. The Meridian timer starts at the correct time when the scheduler is tarted, however, the seconds of the timer oscillates between the next and previous number, and never counts down. This is only happening with the scheduler running.
Sorry, I don't have logs. But two nights in a row, only while using scheduler did the meridian flip not activate on my Mac laptop. Then my mount hits the mechanical limiter in one of the axis, and this causes KStars/Ekos to crash to the desktop. I'll be sure to turn on logs tonight or try to run a test with logging enabled.
The meridian flip does activate when using only the camera tab.
The main camera.
I have the PHD2 log, but since I had a fresh install of EKOS, I had forgot to turn on EKOS logging. Here's the PHD2 log. Ignore the first few bits, I was trying to run guiding assistant.
File Attachment:File Name: PHD2_GuideLog_2019-08-13_205022.txt
File Size: 999 KB
Interesting, I had a slightly different problem using PHD2 last night. The meridian flip did occur, and guiding did resume within PHD2. However, I told the system to automatically park by 6:00 am, which it did. But it didn't abort captures, so it continued to keep capturing images in the parked state. Maybe it's a related issue with PHD2 not responding with the slew or something like that.
This issue did not occur for me when using the internal guiding software. Only when switching to PHD2 did things react differently.
Awesome, I can try this. I also just learned through other forums that the CGX has an issue with RA out of the box due to the gear mesh being too loose causing too much wobble like I’m seeing. Turns out there’s a built in adjuster, and I just have to take the gear cover off and adjust the RA to mesh better. I’m pretty positive now that this is the issue, as it’s widely reported, and I only need to do a search on RA and CGX to find it.