Hi community,

I have adapted the given scripts to my needs, but one question came up. What actually shall abort.py do? And how can I recognize the state after an abort?
My idea would be to count runtime of the motors. But how to transfer this information to the driver or client? 
How actually works status.py? It needs 2 arguments but who is sending this path information?

thank you in advance 

ggtux
 

hi Gunter,
in my case (it's a roll off roof, not a dome) abort.py is meant to immediately stop the roof motion.

About the state, what kind of communication you have from/to the device? I mean it's over http, local serial/usb port?
If it's http for example, status.py could be used to poll the device status as the protocol is asynchronous and to update the /tmp/indi-status file.

As these template scripts are executed outside of Ekos, any return value like the parking status (roof open or roof close) must be send to Ekos in some way.
In park.py, if parking is successful, the file 'indi-status' stores the value '1 0 0' ( '0 0 0' if roof open) then Ekos reads this value and so is aware of the parking status.

Btw if the protocol is http  I found more efficient that status.py periodically read/write the /tmp/status-indi while park/unpark/abort just manage to issue commands to the device.    

If you want a more stable integration of your device (roof or dome) with Ekos consider writing a new INDI driver and not to rely on these scripts only*. My approach (it's the third time so far)  is to use the scripts at first and in the meantime write and test the INDI driver. 

* one big  issue with the scripts (in the roof case) is that only parked / unparked states are sent to Ekos. There's no way as far as I know to tell Ekos that the roof  is moving opening or closing etc. 
Ferrante

Hi Ferrante,

thank you a lot for your answer.
My roof is split in half and both parts sliding apart from each other while opening and vice versa while closing.
Each half has its own drive. I use shutter motors with internal end switches.
In order to control the roof I have a dedicates raspberry pi (“Allsky”). Via relais I connected those drives. On this Pi runs a indi server with the indi-scripting host driver. Another Pi (“RPI41”) controls the Astro equipment and is linked to “allsky”.
I mean in setup equipment you could find “@allsky”. That means to use all drivers on “allsky” like the dome scripts, GPSD, SkySafari.
As client I use a kubuntu laptop. From inside the house I can control the equipment. That works well but the the status of connect or disconnect can not be set because I don’t know the most important parameter. It’s doesn’t seems to be the values in /tmp/indi-status. I’m not sure about the status.py script. It needs two arguments but what software delivers it?
Maybe it is not important for my issue with connection status. Even if I fake the connected or disconnected Staus it would help. But again I can not find a way to signal the status to the server.
Abort.py: how is it possible to interrupt a movement forced by an independent script I.e. open.py?
As long as open.py runs I don’t see a chance to start abord.py. Am I Right?
I know about the interrupt programming in Python but this something different.
At the moment I’m not able to write an own driver. Maybe I can try to modify an existing one like from Jasem indi-Ikarus roof. Or a similar name, sorry.

Have good day till soon.
I would really appreciate to continue this conversation.

Gunter

  Hi Ferrante,

thank you a lot for your answer.
My roof is split in half and both parts sliding apart from each other while opening and vice versa while closing.
Each half has its own drive. I use shutter motors with internal end switches.
In order to control the roof I have a dedicates raspberry pi (“Allsky”). Via relais I connected those drives. On this Pi runs a indi server with the indi-scripting host driver. Another Pi (“RPI41”) controls the Astro equipment and is linked to “allsky”.
I mean in setup equipment you could find “@allsky”. That means to use all drivers on “allsky” like the dome scripts, GPSD, SkySafari.
As client I use a kubuntu laptop. From inside the house I can control the equipment. That works well but the the status of connect or disconnect can not be set because I don’t know the most important parameter. It’s doesn’t seems to be the values in /tmp/indi-status. I’m not sure about the status.py script. It needs two arguments but what software delivers it?
Maybe it is not important for my issue with connection status. Even if I fake the connected or disconnected Staus it would help. But again I can not find a way to signal the status to the server.
Abort.py: how is it possible to interrupt a movement forced by an independent script I.e. open.py?
As long as open.py runs I don’t see a chance to start abord.py. Am I Right?
I know about the interrupt programming in Python but this something different.
At the moment I’m not able to write an own driver. Maybe I can try to modify an existing one like from Jasem indi-Ikarus roof. Or a similar name, sorry.

Have good day till soon.
I would really appreciate to continue this conversation.

Gunter

hi Gunter,

Nice observatory you have there.
So, if I unterstand correctly, each of your RPIs is running an INDI server, the primary RPI ("RPI41") manages the telescope devices and the secondary ("allsky")  manages the roof and other stuff.
Then those RPIs are chained so that the Kubuntu laptop Ekos client sees all the equipment.

The status of connect or disconnect you are referring to is the Dome Scripting Gateway (DSG for short) driver on Allsky? In these case, if the network connection is working fine, it should always be connected. I mean, DSG doesn't check if the roof device is available or not. Other drivers that directly connect to the device through a serial connection might return a 'disconnected' status if the device is for example not powered on.But DSG doesn't work this way, the device (roof) is decoupled from the DSG driver. 
In other words, for DSG the connection only shows that the connection from the INDI server to the client is ok/ko.

Using DSG the only way to exchange information between  INDI driver (and thus the Ekos client) and the device is through the indi-status file.
So status.py, open.py etc don't return any value to INDI/Ekos directly, they can only update the indi-status file to provide information about the device.
For example: '1 0 0' means to Ekos that roof is parked (closed), while  '0 0 0'  roof unparked (open).  If you are wondering what are the other digits meaning, remember that this is a Dome driver not just managing Roofs.

All the scripts (open, close, abort) don't  really need a loop, so there's no harm in executing abort immediately after open.
I see it this way: 'open.py' should only trigger the relais that starts the roof motor and then exit. Then the user could run the 'abort.py' script by pressing 'abort' : the script simply triggers the relais that stops the roof drive and exit.
Remember, like said before, that both open and abort in this case don't  return any value to INDI/Ekos, they can update indi-status though.

From this example it is clear that the information in indi-status is limited: You can read that the roof is unparked after pressing 'open' but you cannot see if it's running, aborted or fully open.

I've used DSG for three different observatory as a temporary solution while writing the INDI driver for the roofs (which I still recommend to you).
My approach is to make use of park and unpark to trigger the roof actions only and not to update indi-status.
Then status.py periodically reads the status from the device and writes it to indi-status, so that INDI/Ekos is aware of the roof status.
Finally abort.py is used....well, to abort roof motion.

If you start developing a roof driver I would recommend to start with: github.com/indilib/indi/blob/master/drivers/dome/roll_off.cpp which I guess was the one you were referring to.

You don't need to send any parameters to the scripts: it is the INDI environment that automatically sends these parameters. They are two file names and file locations if I remember correctly.

All this is based on my maybe limited understanding of DSG. Others could jump in the conversation and add more insight.
I hope that in some way I understood your questions but please provide further information if it helps.

Ferrante

Hi Ferrante,

yes you are right with your assumptions about ma setup . To make it crystal clear I have added a pfd-file.

 

And yes again, the connection via LAN is stable and so it is the connection to the "allsky" RPi incl. the electrical connection to the relais and the motor drives.
All you other thoughts are also correct. With open.py or close.py I just "High" or "Low" a GPIO pin what triggers a relais action. 

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
open.py: (close.py is very simmilar but mode ist "zu" instead as "auf". In german it means "auf"= open and "zu" = close.

#!/usr/bin/python3                       
#usage:~/Python-scripts/open.py                                                   
import time                              
import sys     
import RPi.GPIO as GPIO
# definition section
was="auf" # mode open or close "zu"                                
zaehler= 11   # motor running time  in sec                     
GPIO.setmode(GPIO.BCM)                
GPIO.setwarnings(False)
stop = 19 # emergency stop knob on GPIO pin 19
if was=="auf": pin=23                    
if was== "zu": pin=10
#Interrupt-Service Routine or Callback-function for emergency knob                                
def Interrupt(stop):                       
    global zaehler                           
    zaehler =1                               
    GPIO.cleanup()   
GPIO.setup(pin,GPIO.OUT)            
GPIO.setup(stop,GPIO.IN) # with an external Pull-down resitor installed!
#GPIO.add_event_detect(stop, GPIO.RISING, callback = Interrupt, bouncetime = 250)  # add rising edge detection on a channel
# status request and embedding into indi-driver system
coordinates = open('/tmp/indi-status', 'r')
strg = coordinates.readline()
coordinates.close()
if strg[2]== "0" :
      print("opening the roof")
                                                 
 # main loop                                             
      try:                                         
            while zaehler != 0:                        
                GPIO.output(pin,GPIO.HIGH)               
                time.sleep(1)                            
                zaehler=zaehler-1                  
            GPIO.output(pin,GPIO.LOW)

      except KeyboardInterrupt:                        
         GPIO.cleanup()
         
else: print("roof is already open - stop")
#write status for opened roof 
strg = strg[0] + ' 1 ' + strg[4:] + ' ' + str(zaehler)
print(strg)
coordinates = open('/tmp/indi-status', 'w')
coordinates.truncate()
coordinates.write(strg)
coordinates.close()

sys.exit(0)

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I use a loop because the drives have to run a certain time. That's why I can not interrupt the movement by abourt.py. 
I have analyzed the cpp-files of "domscripting host" and have understood the meaning of /tmp/indi-status. And I was surpized that not much communication happens.
I will start adapting the "roll-off.cpp". But with my limited knowlege in cpp it'll be a challenge. But very interesting. 

 

Thanks, have a good day.

Gunter
 

hi Gunter,

the need for a loop that spans a time interval is now clear to me.
But I would suggest decoupling the zaehler loop from the rest of the script so that it runs independently from the command you send to the driver.
To be more specific, the loop could be saved in a 'gunter_roof_controller.py' script that acts like a server on Allsky RPI and you manually start it when the system starts.
This script receives in a different thread inputs from other scripts like 'open.py', 'close.py' or 'abort.py' (that are triggered by DSG commands).

So you could press open, abort, close without waiting the execution of the script. The command is then forwarded* to the controller script that can retain the roof status in the zaehler var.
For example if you abort  5 secs after open, the zaehler equals 6. You then hit open again and the roof keeps moving for the right amount of time (zaehler from 6 to 0).

Just an idea, don't know if could be of any help.
Working on a custom INDI driver would be still the best option. 

Ferrante

* I mean that a python script should send data to another script. There are many ways to implement interprocess communication (subprocess pipe, queues, write/read files etc).

Hello Ferrante,

thank you again. I will give it a try but in parallel I try to write or adapt the roll-off.cpp driver. I actually started to analyze the code.
In my case are several things are different.
1. I don't need to check if the roof is fully open nor fully closed because the drives have theire own internal limit switches. These were manually set by me.
2. it would be not a big deal to install them (one for each roof part to indicate open and another set of two for status fully closed), but again no need for that.
3. the runtime of the drives need to be roughly adjusted to that. There is a const ROLLOFF_DURATION 10 //seconds.
3. As far as I understand the code at a first glance, it uses dome motions like turns cw and ccw. I wouldn't need that. Can I just comment them out?
4. The only thinks necessary are unpark to open and park to close the roof. And of course connecting resp. unconnecting.
5. propably abort in an emergancy case.

I'm a bit confused about roll-off.cpp . On the very top in the comments "Dome Simulator" is written. I think it is a mistake over taken from another code file, right?
The core of the code seems to be TimeHit(). But where is the routine to switch a relais (GPIO-Pin)? Or in other words, how the move is kicked on?

Many questions, sorry.

best regards Gunter

hi Gunter,

if it's your first approach to INDI driver development I recommend reading the tutorial that Rick wrote recently: docs.indilib.org/

3b and 4. Roof drivers are all adapted from dome drivers. That's why you see the dome simulator in the comments and the roll-off driver is in the source code 'dome' directory.
I guess that helps keeping a cleaner INDI API but requires a little tuning when developing a roll off roof driver, for example:
- Park and Unpark methods must be used for opening and closing the roof.
- CW and CCW must be used for outward/inward (respectively)  roof motion.
- Open and Close are used for the dome shutter control and not be used in roll offs.

Of course you can comment everything out and develop your own methods but those are methods implemented in the parent class (dome) and shared among other Ekos modules. For example:
-  the shutdown procedure calls the Park method not your own.
- CW and CCW should be used for the roof direction of motion in case you want to just move the roof and not to fully open/close it.

5. In case of unattended operation, would be very useful to automatically stop the roof if the mount is not parked. 

Timerhit is useful if you need to check the driver status and not just perform actions.
For example, if you need just to trigger the opening of the roof and don't care of the rest, TimerHit is not needed.
But if you also need to check the roof position or if it reached the final position or if it received an error msg from the device etc, TimerHit is the place to check all this.

Usually the driver communicates to a device firmware interface not to GPIO-pins directly.
From what I understand you have two options: deal with the RPI GPIO from inside your new custom INDI driver or write a 'firmware' for your roof device. By 'firmware' I mean another script on the Allsky RPI that deals with the GPIO and exposes these controls to the driver. Consider that is more or less what you already did with your script in python. 
The second option has the benefit that you could control the roof also outside of INDI / Ekos with the same script.

Ferrante
 

Wow, Hi Ferrante,

That‘ll take a Moment to Digest.

Think you.

Best regards Gunter

I think I get an idea what you mean. The Aldi dome driver has a similar format a scripting gateway to control a Relais box.

CS Gunter

Hi Ferrante,

I think I can start with the custom driver. I will use wiringPi to control my relays resp. motors. The Ikarus roof driver of Jasem is a pretty close example to my ideas. I could clone the source code from GitHub. It was easy to compile and link the code but I think I have to copy the source to a directory of the the indi core drivers under domes. Is that correct? (~/projects/indi )
Can you please advice exactly how to proceed in this matter?
Thank you in advance.

Gunter