Javier,

I think your changes are fine and on point for personal use. They have been requested more than once.

Since I do not agree that the driver is the place for these functions I do not plan to do the PR. I would prefer that the functions be tied to the Observatory. Or if too difficult put them in a new observatory oriented utility driver. That could be combined with any of the dome/rolloff drivers. If the developers think the changes should reside in this driver so be it.

I'll just list some of my objections to extending the rolloff driver which was intended to remain the same while any changes are restricted to the remote end. That keeps changes out of the INDI environment and keeps the driver ignorant of what is going on to operate the roof. It is defined by what it does not do as much as by what it does.

We have to imagine that any change to the driver will be running against old remotes

Adding implied functions to the driver might result in support issues. Hopefully not and the existing Arduino implementations out there reject the use of new functions. But we should not break existing installations with protocol conflicts or pin overloading. We can define the purpose of relays and assignment of pins in our own implementations but not in general, it is not under our control. Some years ago a person wrote their own implementation, no clue as to what that involved. The next auto update of INDI should not disturb that install.

With existing installs the driver interface will imply that the check boxes do something but there is nothing on the other end to act upon them.

In the same way the driver does not deal with switches, relays or pins, we do not know what the driver is talking to. It does not have to be an Arduino, it could just as well be a Python script. My own implementation is an Arduino but does not have any relays and most of the pins are covered by a TFT shield. All I'm interested in seeing come in is open close and are you done yet messages. At the present time we can provide for a turn key no coding required solution to a completely personalized implementation. But the driver remains the same by restricting its function.

While it is easy and convenient to drop things in I do not care for it.
Why somebody is having a problem with their camera, power supply or they are locked out of their observatory is not a core concern of the roof driver.

Regards
Tom

Read More...

If you apply a PR, don't edit the rolloff.ino.standard as shown. Add an additional example sketch with your changes. The rolloff.ino.standard needs to retain the original relay polarity and pin numbering to match the standard Uno relay shield. That helps those who do not want to be involved with any code editing get on-line without any software changes.

Limiting the number of relays was intentional to limit it to just the purpose of controlling the roof. There was some discussion at the time of the Observatory being extended. Rather then put other observatory like functions in the individual roof/dome drivers. In the meantime there were 3rdparty drivers able to read and set particular pins.

Read More...

Agreed I seem to have a more general problem. When I went to get things set up after dark using the 'new' profile the limit issue had returned along with others that ended the session.

Read More...

Thanks Bill,

Made me define a new profile with the same devices. The same unwanted values showed up but now changes are retained. Don't know what it means but guess I'll go ahead and customize that profile instead of my usual one.
/Tom

Read More...

KStars 3.7.0
The limits settings on the Ekos mount tab do not seem to be retained across Ekos starts.
I can change the settings but they get set back to those shown the next time Ekos starts.
Purge all configuration doesn't reach it. I have been looking around for a save option and in the KStars database but can't see a way to manually edit the selections.

Hello Hy,
Thanks for the response and helpful suggestions.

The issue was in the capture tab with my Format definition field. I had used a %t target in the directory portion of the definition. Target was not used/defined in the capture tab so it worked. However the scheduler asserts the 'Polaris' target and the directory does not exist. After cleaning that up in the capture tab (for each filter) the scheduler accepted the definition.
/Tom

Read More...

KStars 3.7.0 Stable
I have not been a user of the scheduler and am having a time of it trying to define a simple job. The .seq file selected runs as expected using the capture module and should take about 30 minutes. When trying to reference it in the scheduler it almost always results in a message like: "Greedy Scheduler: empty plan". Attaching screen shots hoping there is something obvious that I am missing.

Read More...

Comparing the log with mine, they seem to match until I get to the following.
Yours:

[2024-04-07T11:21:43.851 MDT DEBG ][ org.kde.kstars.indi] - ZWO CCD ASI2600MM Pro : "[DEBUG] CCD ID: 1 Width: 6248 Height: 4176 Binning: 1x1 Image Type: 0 "
[2024-04-07T11:21:43.856 MDT INFO ][ org.kde.kstars.indi] - ZWO CCD ASI2600MM Pro : "[INFO] The CCD Temperature is 0.000. "
[2024-04-07T11:21:43.856 MDT DEBG ][ org.kde.kstars.indi] - ZWO CCD ASI2600MM Pro : "[DEBUG] setupParams ASISetROIFormat (6248x4176, bin 1, type 0) "
[2024-04-07T11:21:43.856 MDT DEBG ][ org.kde.kstars.indi] - ZWO CCD ASI2600MM Pro : "[DEBUG] Pixel format 0 is supported by SER recorder. "
[2024-04-07T11:21:43.856 MDT DEBG ][ org.kde.kstars.indi] - ZWO CCD ASI2600MM Pro : "[DEBUG] Pixel format 0 is supported by RAW encoder. "
[2024-04-07T11:21:43.856 MDT DEBG ][ org.kde.kstars.indi] - < ZWO CCD ASI2600MM Pro >: < CCD_CONTROLS >
[2024-04-07T11:21:43.861 MDT DEBG ][ org.kde.kstars.indi] - < ZWO CCD ASI2600MM Pro >: < CCD_CONTROLS_MODE >
[2024-04-07T11:21:43.861 MDT DEBG ][ org.kde.kstars.indi] - < ZWO CCD ASI2600MM Pro >: < FLIP >
[2024-04-07T11:21:43.862 MDT DEBG ][ org.kde.kstars.indi] - < ZWO CCD ASI2600MM Pro >: < CCD_VIDEO_FORMAT >
[2024-04-07T11:21:43.863 MDT DEBG ][ org.kde.kstars.indi] - ZWO CCD ASI2600MM Pro : "[DEBUG] Frame ROI x:0 y:0 w:6248 h:4176 "

Mine:
[2024-04-08T12:55:10.520 EDT INFO ][ org.kde.kstars.indi] - ZWO CCD ASI2600MM Pro : "[INFO] The CCD Temperature is 0.000. "
[2024-04-08T12:55:10.520 EDT DEBG ][ org.kde.kstars.indi] - ZWO CCD ASI2600MM Pro : "[DEBUG] setupParams ASISetROIFormat (6248x4176, bin 1, type 0) "
[2024-04-08T12:55:10.520 EDT DEBG ][ org.kde.kstars.indi] - < ZWO CCD ASI2600MM Pro >: < CCD_COOLER_POWER >
[2024-04-08T12:55:10.520 EDT DEBG ][ org.kde.kstars.indi] - < ZWO CCD ASI2600MM Pro >: < CCD_COOLER >
[2024-04-08T12:55:10.521 EDT DEBG ][ org.kde.kstars.indi] - < ZWO CCD ASI2600MM Pro >: < CCD_CONTROLS >
[2024-04-08T12:55:10.524 EDT DEBG ][ org.kde.kstars.indi] - < ZWO CCD ASI2600MM Pro >: < CCD_CONTROLS_MODE >
[2024-04-08T12:55:10.524 EDT DEBG ][ org.kde.kstars.indi] - < ZWO CCD ASI2600MM Pro >: < FLIP >
[2024-04-08T12:55:10.524 EDT DEBG ][ org.kde.kstars.indi] - < ZWO CCD ASI2600MM Pro >: < CCD_VIDEO_FORMAT >
[2024-04-08T12:55:10.525 EDT DEBG ][ org.kde.kstars.indi] - ZWO CCD ASI2600MM Pro : "[DEBUG] Frame ROI x:0 y:0 w:6248 h:4176 "
[2024-04-08T12:55:10.529 EDT DEBG ][ org.kde.kstars.indi] - INDI Server: "2024-04-08T16:55:10: Client 27: new arrival from 127.0.0.1:60650 - welcome!"
[2024-04-08T12:55:10.529 EDT DEBG ][ org.kde.kstars.indi] - INDI Server: ""

Your log does not contain CCD_COOLER or CCD_COOLER_POWER attributes.
I don't know how to explain their absence. There is the ~/.indi ASI2600mm file you might see if anything in there looks out of place.

Read More...

Sorry, trying to watch the Liverpool game while responding. I see you already posted a log.
The ramp value is disabled throughout the log. Can you set it and try again.

Read More...

Bill,
It probably is not the particular model of camera, I do have the mono version. Can you post a screen shot similar to what I posted? If you post the log file perhaps something can be gleaned from that. ~/.local/share/kstars/logs/
Hopeless I know, but do make sure the 12Vsupply is working and connection is still firmly seated.
/Tom

I have a 2600 so gave it a try, not similar hardware or symptoms.
Clicking the green button turned the cooler from off to on. It seemed like it wasn't working.
selected the blue tear drop and needed to provide a Ramp value - just in case.

Read More...

> If i am right...My question now its... A0,A1,A2,A3 pins from arduino board, where should be connect in relays >module?

Yes that seems correct. The A0 - A3 pins are not for the relays (output), they are predefined to be input pins.
If you are just playing, any old on/off switch can be used to test the input pins. Connection outlined in previous reply.
Send a open request from the driver, that should result in the N1 relay activating. wait a bit then close the switch connected to A0. You will see the INDI driver change to the opened state.

Read More...

Javier,
The arduino.cc Uno Rev 3 is the one I was thinking of.
The arduino.cc Relay shield you linked will provide the easiest installation. It uses fixed assigned pins on the Arduino Uno. Those pin numbers are used by default in the rolloff.ino.standard.
For a one button controller use relay 1, for two button use relay 1 for open and relay 2 to close. The normally open relay connector is used along with the common.

On the input side the default pins will be A0 to indicate fully opened and A1 for fully closed. You can see these definitions at the start of rolloff.ino.standard. The uno's builtin pullup resistors are used so switch opened will be pulled up to the positive value. When the switches are closed your connection will be from the pin via the switch to one of the ground pins.
Given these hardware selections you will not need to make any changes to the ino code. Rename the sketch to rolloff.ino and place it in a sub directory named rolloff. Then use the Arduino IDE to load the sketch onto the board. Then you get the USB connection from the driver working.
Could bench test when you get the controller or get the controller working safely and reliably on the roof and then introduce the uno connection.

Read More...