Discussion in 'STX and STXL Series Cameras' started by Mark de Regt, Aug 12, 2020.
Ok; we'll do that, and I'll report back.
To put the problem in perspective:
I just finished the bulk of the processing on an image for which I took L, R, G, B and Ha images. Including images I tossed, I took around 45 Luminance images, and well over 100 images with the various other filters. There was a total of about twenty images that falsely claimed to be taken with a filter other than the L filter, but actually were taken with the L filter. Eight of those I could re-purpose into L images, since they were of the same duration.
So it's not a debilitating issue, yet; merely annoying.
Yeah, but it shouldn't happen.
We just did the test, and it threw an error message every time. I have attached a screen shot. It would go to the first filter, then, when going to the second, give the error message "CFW Error; Error occurred in the Query State; Bad CFW Command."
When I checked "random moves" and "continuous moves," I got the error message (also attached) "CFW Error; Error occurred in the Goto State; CFW Busy."
I would double-check the cable. If it looks good then you may have to send the wheel in for service. Contact @Bill, email@example.com
We've changed the cable; no difference.
I'll contact Bill.
I sent the filter wheel in to Bill, who put it through its paces, and found no problem. It's back on the imaging rig, and doing the same thing--randomly, a one hour plan in ACP (a "plan" being a set of images with the same target, filter and duration) will use the L filter, although it's labeled as having used another filter.
I'll cross-post on the ACP forum, but it's a significantly annoying problem!
I have attached the Maxim log, FWIW.
This is a problem that affects only one of our customers, Mark de Regt. ACP sets property CCDCamera.Filter to a known correct filter number for his wheel, and logs that fact (log attached):
02:05:14 Switching from L to SII filter for imaging
then we see in the MaxIm log that the property-set call has been received and accepted without error:
02:05:15*4 Filter wheel moving to position 4
However the filter "sometimes" or "occasionally" does not move. On my advice, Mr. de Regt sent the filter wheel to SBIG and it was found to be OK.
There are some other errors in the MaxIm log (attached) that appear to be related to guiding??? I'm guessing here
02:11:05#5 Error - Error in plugin callback (400) - Could not activate relay - already active
multiple of these are logged during each exposure (7 - 12 within the half hour exposure). I'm guessing that these aren't related to filter switching.
However, could these be an indication of a hardware/USB/power supply problem? If so could that be a possibility on the occasional filter changing failures?
I'm going to ask Mark to step in for me and follow through on this. I don't have much more to add as the call from ACP is clearly being received and understood by MaxIm.
Here's the DC-3 Dreams Comm Center ticket on this issue
Uh oh... I was unaware of this thread when I posted a thread for Mark over on the MaxIm section (since that's my "point of view" ha ha). While I was working on this today he posted the above here. I'll go back and let him know it's on two threads. Feel free to merge them. My only contribution is to match my Property set of the filter to the corresponding MaxIm logged receipt of that and what looks like a successful change. More detail on my other thread.
Ugh, this is being worked on another thread. https://forum.diffractionlimited.com/threads/selecting-wrong-filter.7386/page-3#post-41628
These are routine, do not indicate a problem, and can safely be ignored.
Because of internal structure they're technically reported as errors, but they're really just info status. The plugin sends a command to move the mount, and then sends another before the previous move is determined to be finished. Mount state in the software can lag reality by a substantial amount, depending on poll rates in various parts of the machinery (not just the Observatory poll rates).
A more advanced system of asynchronous push-notifications would have to be developed to completely mitigate this sort of issue.
Filter wheels are notoriously bad for lying about their state. Problems with them may have similar architectural explanations, but they'll be completely independent of the ones that produced this particular error message.
- Owen -
I've merged the threads.
Owen said, "Filter wheels are notoriously bad for lying about their state."
Am I just stuck with a very expensive, unreliable system? Given that I've been imagining with SBIG cameras and filter wheels for almost 20 years, and never before have experienced this problem, I hope there is something that can be done about this!
Owen was speaking generically about filter wheels, from a software perspective. Wheels tend to be pretty simple devices; sometimes excessively so. Many don't report back what slot they are at. Some older ones don't even report back whether they are moving or not; after sending a command you have to wait long enough and then assume they've finished turning.
We haven't had major reliability issues with our SBIG filter wheels. Of course like anything there's an occasional failure, but in general they've been extremely reliable.
The callback 400 error doesn't relate to filter wheels at all. It's also a transient condition, which self-corrects and doesn't impact operation of the driver.
OK, good you guys are working this. If I can supply additional info please ask.
So I'm getting nowhere on solving this, after several months; as I write this, it's busy taking an hour of luminance images that it's pretending are green-filtered images. What is the logical next step?
Mark, could we schedule a TeamViewer session to remote in to the system?
I could have a look and see if there is any hint of why this is happening and what is special about your setup.
The assumption is that the system is internet-accessible, and I would need access to the desktop, not just ACP web console.
Of course! When?
I'm on EST (UTC -5). Am available today until 2pm. There is a possibility I could be available after 7pm as well.
Tomorrow pretty much any time.
Ideally, I'd ask you to power up the equipment but not the software, have Teamviewer client installed and running.
Send me a PM with the credentials. Include a telephone number where you can be reached in case of connection problems.
Separate names with a comma.