added darklight cover calibrator driver

[iwannabswiss]

indi_documentation.zip

The DarkLight Cover/Calibrator (DLC) is a versatile DIY solution using an Arduino Nano or compatible microcontroller. The latest iteration of the DLC features a modular design that offers options to exclusively drive a 12V light panel, no servo required, ideal for a wall-mounted setup, or a servo with no light panel, ideal for taking sky flats. This means you can build a device to operate a servo motor, a light panel, or both, serving as both a dust cover for remote telescope users and/or a calibration panel. The DLC offers both an ASCOM and INDI driver, ensuring seamless operation via the DLC Windows application, any automation software compatible with the ICoverCalibrator driver in ASCOM v6.5 or newer, or the INDI platform.

[iwannabswiss]

Added additional commits to resolve errors

[knro]

Thank you for the driver! It needs to implement both INDI::LightBoxInterface and INDI::DustCapInterface. Please see Flip Flat driver for an example.

[iwannabswiss]

Thank you for the driver! It needs to implement both INDI::LightBoxInterface and INDI::DustCapInterface. Please see Flip Flat driver for an example.

The problem with DustCapInterface though, is it that it doesn't provide an option to halt cover movement.

[knro]

Yes it's just unpark and park, I'll add ABORT to the interface soon.

[knro]

Both DustCap and LightBox interfaces are now updated. Please check and let me know of any further issues.

[iwannabswiss]

Both DustCap and LightBox interfaces are now updated. Please check and let me know of any further issues.

Will review and keep you posted. Thanks!

[knro]

@iwannabswiss Any update on the PR?

[iwannabswiss]

@knro

Thanks for checking in. The changes have been made, and they appear to work in a 'virtual setting.' However, I’m not thrilled with the UI operations of the DustCapInterface and am still working through it, in an attempt to improve it, along with a few other details. Unfortunately, work has kept me busy, so I haven’t yet had a chance to test the changes on an actual device before committing.

[knro]

Alright, let me know if you need any help in any part of the driver.

[iwannabswiss]

@knro

Even though Park and UnPark use ISR_1OFMANY, is there not a way to "reset" the buttons, so if Abort is selected, both buttons turn "off"?

[knro]

There is no third state. It's either parked, and for any motion it becomes unparked. Status could be BUSY or ALERT, but the switch status is Unparked.

[iwannabswiss]

@knro

Thank you for the explanation. If the DustCapInterface is structured with only two discrete states, that doesn’t quite match the flexibility my design requires. In my setup, users can initiate either opening or closing of the cover, and they can interrupt this movement at any point using an Abort command. Once stopped, the cover could be partially open (not suitable for telescope use) or partially closed, depending on where it was halted. The user then has the option to resume movement in either direction, giving them more control based on the situation.

This flexibility in direction control doesn’t align well with Park and Unpark, which seem to imply fixed states rather than active directional selection. Due to these limitations, I don’t want to implement the DustCapInterface, as it doesn’t support my design’s requirements.

[knro]

You can always introduce your own extra property to report this. INDI::PropertyLight for example to indicate whether the cap is fully opened, fully closed or in-between. Or even introduce INDI::PropertySwitch to resume. There are no restrictions on add extra properties to a driver.

[iwannabswiss]

I'm sorry for the misunderstanding. I already have a property in place that indicates whether the cover is open, closed, or moving. The issue is with the Park and UnPark buttons; they don’t allow the user to control the direction of movement once it’s been aborted, as my design does.

Here’s how my system currently works:

• If the cover is closed, the user presses the Open button to start the opening process.
  

• If the user wants to stop the movement at any point, they press Abort, leaving the cover partially open.
  

• When they want to restart the cover, they have two options:
  

1.     Press the Open button again to continue opening the cover,
   

2.     Or press the Close button to move it back to the closed position.
   

With Park and UnPark, this flexibility doesn’t exist. If the cover is closed and the user presses UnPark to start opening it, then aborts the movement, the system reports Parked. However, when the user tries to restart the movement, pressing UnPark again won’t give them the option to choose whether to continue opening or to reverse direction and close the cover. UnPark will simply start the motion without regard to the previous aborted state, which doesn't align with my design.

This lack of direction control is why I can’t implement the DustCapInterface in its current form. Does that make sense?

[knro]

You can implement your own Open and Close property logic, and simply call Close on Park, and Open on UnPark. This way clients that rely on this interface have a consistent method to control it for automated operations.

[iwannabswiss]

I'm sorry, I'm a bit confused. You mentioned, "It's either parked, and for any motion it becomes unparked." That means Park equals the Open, Close, and Stopped position and Unpark is for any movement. If so, I don't understand how I can implement my own Open and Close property logic and call Close on Park and Open on UnPark? Either way, when restarting an Aborted move, whether I want to move to Close or Open, I would have to call UnPark because the cover is now in motion, whether to the Open or Closed position.

[knro]

1. Parked: State is IPS_OK and PARK switch is ON.
2. Unparked: State is IPS_OK and UNPARK switch is ON.
3. Unknown: State is IPS_ALERT or PARK/UNPARK are not toggled.

[iwannabswiss]

@krno Thank you so much for your patience, I really appreciate it. I hope this doesn’t come across as rude, but I feel like I’m not getting a clear answer to my questions. Either I’m misunderstanding what you’re implying, or I’m not explaining the issues clearly enough. Would it be possible to arrange a Zoom, Skype, or Google Meet session to discuss this in more detail and resolve it more quickly?

[knro]

Sure I'm traveling right now so it would be difficult to set up a meeting, but hopefully next week after I'm back we can arrange for a meeting.