Jasem,

I see that the DomePro2 driver is listed in the Dome drop-down menu on the Profile editor screen, but I don't see any mention of it, documentation, or any thing elsewhere. Is there a link to information about the driver?

Thanks for any information.

Read More...

I implemented a simple change to the asi_wheel.cpp file that allows one to use the existing "Tools->Devices->Custom Drivers..." mechanism in conjunction with creating symbolic links back to the standard driver (indi_asi_wheel).

I will create and submit a PR later today and hopefully you will find it benign enough to accept it into the source base.

Read More...

OK, thanks.

I'll play around with the asi_wheel driver for my own purposes and see what I learn.

Read More...

Not a problem - I appreciate your help.

Basically any driver that shows up in the pull-down menu on the Custom Driver screen can be aliased as you described.

However, the code explicitly suppresses from that drop-down drivers marked by mdpd="true" in those XML files you mentioned (in this case indi_asi.xml).

Read More...

I am not actually trying to use two filter wheels at the same time. I basically have one with color-related filters attached to my color camera and one with mono-related filters attached to my mono camera, so depending on what camera I am using on a night I need to distinguish between the color or mono filter wheel.

However, to answer your specific question, I just plugged them both in at the same time and one shows up as "ASI EFW 0" and the other shows up as "ASI EFW 1".

Read More...

Well, let me update: I still thank you, but it actually did not work. It only works in some cases. Apparently MDPD drivers cannot be aliased. I am not 100% sure what a MDPD driver is, but I am guessing it is one supplied as an object file rather than as source. Anyhow, the 'ASI EFW' driver is supplied by ZWO and it tagged as MDPD so it cannot be aliased and I cannot do what I had hoped to do using aliases.

That is where things currently stand.

Can anyone confirm what an MDPD driver is and why it cannot be aliased?

Read More...

Thanks so much. That worked!

Read More...

I could not find this discussed, so posting this question.

I have two ASI EFWs. I use one with my monochrome camera and one with my color camera. I have separate profiles for monochrome and color, but I don't know how to have two ASI EFW config files (namely ~/.indi/'ASI EFW_config.xml'). Consequently I have to re-enter filter names for the filter slots whenever I switch between color and monochrome.

Since the "ASI EFW" name seems to be determined via selecting it from the pull-down menu for filter-wheels when building a profile, what is the proper technique to allow for distinct config files?

Read More...

The skies were not clear as had been forecast last night, but I was able to at least exercise it enough to feel it will be OK.

I submitted a pull request here: github.com/indilib/indi/pull/1540

 

Read More...

Definitely not just baud rate.

I was planning to give a complete report once I know that it is truly working in the field, which will be tonight, hopefully.

However, since you ask, there were definitely at least two bugs:

1. The missing minus sign in the checksum calculation that I mentioned earlier
2. The GET_MTR_POS request was missing a byte.
3. I added code to rigorously clear RTS since if it is left laying around, the focuser hand controller is locked out (that definitely happened to me).

In addition, I believe (and I guess PlaneWave does, too, per their python script) that the better, safer, approach to reading packets is to go byte at a time so as to get the embedded data length, which also allows a check that there is enough buffer space, and then read that many bytes. Also byte at a time allows gibberish, should it appear (as it does when baud rate is wrong), to be discarded safely.

Finally, I added some sanity checks per the python script to confirm that the packet to be used is indeed the response to the request sent.

The vast majority of the driver code is bug-free and correct, and I certainly am extremely thankful for it - all of which is to say it is not a criticism when I say that in its current state I cannot see that anyone ever used this driver on a PlaneWave EFA unit. FYI: DeltaT Dew Heater code works fine.

I will provide you the changes I made via the git process once I confirm that this version works.

Again - extremely heartfelt thanks for INDI, KStars and EKOS... what a joy to use this software.

Read More...