Resolved Selecting Wrong Filter

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.

 

Agreed!

 

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."

 

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 -

 

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!

Mark

 

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?

 

Of course! When?