I’m a brand new SGP user. I bought the software a year or so ago but I’m just getting around to trying to use it.
I connected my FLI Centerline filter wheel, and I tried to define the filter list, and it seems like there aren’t enough filter options for the Centerline. In other programs (Maxim, TheSkyX) I need 17 filter positions, but SGP only appears to allow up to 12. A quick search of the forum doesn’t show any topics related to the centerline. Is anyone else using the centerline? Anyone experienced this issue? Any help would be appreciated.
The CenterLine filter wheel uses two independent wheels, each has 5 slots. They overlap in the middle, so you are always shooting through two filter slots. You typically never want to shoot through two filters, so you leave one slot in each wheel empty. All of the possible combinations of the two filters overlapping is one “slot” for the wheel. The first 5 slots are LRGB-Blank. Then the next 27 slots are all of the remaining combinations of the two wheels. The end result is that you need I need to use the first 17 “slots” (combinations) in order to get to each individual filter (I’m using the same filters everyone else is - LRGB and Ha O3 S2 - nothing special, just 50mm astrodons for a 16803 proline). The reason the CenterLine is designed that way as I understand it is so it doesn’t introduce an imbalance in the image train. Its center of gravity is closer to the optical axis than with other oblong/teardrop shaped filter wheels.
Anyway… It sounds like this might prevent me from using the software for now, until this filterwheel is supported. I’m a little surprised. I wouldn’t think that I was the first one to try to use this filter wheel with SGP.
EDIT: I didn’t answer your question - yes this is just casual AP using a portable setup in my backyard. I’m using a TeleVue 127FLI scope, which is designed around the FLI Proline camera, CenterLine filter wheel and Atlas focuser.
@jbalsam It’s not a big deal for us to support this. I guess I really just don’t understand why the ASCOM driver behaves this way. Wouldn’t you want to make the complexities of the filter wheel fairly transparent to the user? In other words, since you are only using 7 filters, why not map these combinations to reasonable indices like 1 - 7 or 0 - 6 instead of forcing odd FW positions like 16 or 17? Position 7 might be decoded in the driver for S2 to mean wheel 1, blank and wheel 2, pos 3.
Maybe I just really don’t understand how the driver is implemented?
I’m the wrong person to ask about the finer points of the ASCOM driver. I agree, it’s not an intuitive system. But it is what it is I suppose.
If you watch how the wheels move, it makes more sense. Positions 1-5 in the driver are the five positions on the first wheel while wheel 2 is on position 1. Positions 6-10 are, as I recall, positions 1-5 on wheel 1 while wheel 2 is on position 2, and so on. It would be a bit nicer to work with if the driver controlled the two wheels in the way you described.
Are you saying that you simply do not have a way to physically install your filters so that they all map to a position between 1 and 12? If not, this means that certain positions between 1 and 12 are simply invalid right? Just trying to make sure I understand its operation correctly.
Either way, we can make an easy modification so you can use your filters…
All the 25 filter positions are valid combinations of the two 5 position wheels but it looks as if it will be difficult to get 8 different positions with at least one wheel on an empty position in the first 12. 6 or 7 are possible, especially if you allow two compatible filters to be used, such as L and O3.
The names and focus offsets of the filters are provided by the ASCOM driver so the application can discover the number of filter positions, what names have been set, and the focus offsets. Each filter position corresponds to a unique filter combination, just as if you had a 25 position wheel.
Just as applications should not need to adapt to particular hardware requirements drivers should not need to adapt to particular application requirements. The contract that ASCOM defines applies to both.
Yes, what you said is accurate - I can’t install my filters in such a way so that I can uniquely address my 7 filters within the first 12 positions without (as Chris suggested) having filters overlap. I would rather not have filters overlap, even if they are nominally compatible (like L and other filters). Chris’s explanation of how the filter combinations work looks a bit better than mine was.
Chris -
From your title (ASCOM developer) it sounds like you are the person to go to about this issue. I didn’t fully understand what you meant in your post though. Are you saying that the way SGP looks at the CenterLine’s ASCOM driver is not correct, in that it isn’t trying to discover how many filter positions it has? Or are you saying that there’s an issue with how the CenterLine driver is written? I’ve only used the CenterLine’s ASCOM driver in two programs (Maxim and TSX). I defined the filter names and positions in Maxim. As I recall, when I connected TSX to the filter wheel for the first time it correctly copied the filter names and positions without me needing to re-define them (Just a recollection though… I couldn’t swear to that).
Anyway, thanks to both of you for looking at this issue.
Technically SGP is probably wrong here. If the filter wheel exposes 17 “filters” we should be able to handle these. It’s not up to us to determine if overlapping filters is “weird”, really we shouldn’t even care that they’re overlapping. We just see that there are 17 slots and we should allow you to access those. However we want users to be able to create profiles/sequences without their equipment connected and this is where the problem arises.
At some point we have to make an assumption about the number of filters that can be connected or allow you to enter a the number of filters that you want to connect and we can draw a form with that many “slots”.
Thanks Jared, that makes sense. The problem does get a bit more complicated if you want the ability to set up sequences without equipment attached. Your idea to have a user input for the number of filter slots might be a good one. It might also be useful to have the option to read the information from the ASCOM driver, though that might require a bit more work than just adding the user input option.
If you want to set an upper limit on the number of filters that can be used, the CenterLine ASCOM driver appears to have 32 filter positions, though I think it only really makes sense to have 25 because that’s the total number of possible combinations from two 5-slot wheels. FLI also has a 20-slot conventional filter wheel (the CFW-3-20, it uses 28mm filters and one large wheel).
Looking forward to being able to use SGP once this functionality is modified. Thanks again to everyone for your responsiveness.
The user inputed “filter count” would still need to be validated when the equipment is connected. We currently do this. But the form just isn’t created dynamically. For instance I only have a 5 position filter wheel but I could activate all 12 filters. Then when SGP connects to the hardware it will check the filter wheel and will disable all filters above 5.
So I believe we’ll be able to support the Centerline in the same fashion, we just need to make that form more dynamic so we’re not “punishing” folks with “normal” filter wheels and forcing them to see 32 slots (that scroll off the screen) when they only have 5.
Also I agree with Ken in that it would be nice for the filter wheel to only expose sane combinations of filters. But at the same time we shouldn’t care. It just makes it more annoying for the users of this filter wheel to know which combinations are valid.
Is there a need to make an assumption at all? If you use something like a flow layout panel then couldn’t you keep adding filter controls for as many as are available? The panel would scroll as required.
From a look at the FLI manual it looks as if it might be possible to set it up so that particular filter combinations correspond to particular index positions. Wouldn’t that solve this problem?
Thanks for pointing me to the user manual for my filter wheel. Maybe it would help if I read that completely before asking questions here? =P I don’t think I ever read it through, because it explains very clearly how to set up the filter index so you don’t need to use 25 positions (or 17 in my case). All I have to do is use a piece of software they have (which I already have installed on my laptop as I recall), and I can map the different filter combinations to the ASCOM indices. So I should only need the first 7 slots, like everyone else.
If I ever start using one of FLI’s 20-slot filter wheels, I’ll come back to this problem.
Well that was too good to be true, it seems. The functionality described in the Centerline Manual that I linked to doesn’t seem to be available. I have the current version of the FLIFilter software installed on my computer, but the instructions about how to re-assign the filter positions seems to refer to a functionality that doesn’t exist. I sent an email to FLI about it. I’ll update when I hear from them. Should be tomorrow I expect.
Problem solved. FLI doesn’t have a direct link to the version of FLIFocus that centerline users need. For anyone having this problem in the future, here’s the link to the correct version of the program: http://flicamera.com/downloads/CenterLine.zip
Just unzip that file and run the version of FLIFocus that is inside from that location (there’s another file in there which is needed apparently). Works like a charm. I was successfully able to re-map the filter positions so now I only need the first 7 slots.
So there’s no need to redesign how SGP works on my behalf. You might still want to do it on the principal of the thing (some day, someone will want to use 20 filters…), but I’ll leave that up to you.