×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

Ekos Scripts Manager does not accept parameters

  • Posts: 3
  • Thank you received: 1
In a previous version of Ekos, I had been using the post-capture script with a command like the following:
rts_shutter.py 120
to run a small python script that will trigger a camera shutter via a serial port RTS line toggle, with the passed parameter equal to the exposure time requested.

This worked great, but after updating to the latest Ekos I now see that the scripting functionality has been expanded to support Pre/Post job and Pre/Post capture scripts in its own "Scripts Manager" section under tools. I have not been able to get my previous approach to work under this, however - whenever I pass it a script with a parameter, the logs just give the following no file or directory error:
2021-05-16T01:33:43 Executing post capture script rts_shutter.py 120
2021-05-16T01:33:43 execvp: No such file or directory
2021-05-16T01:33:43 Post capture script finished with code -1.
(Order reversed from the presentation in Ekos for readability)

Removing the parameters lets Ekos find the script fine, so I worked around this last time I imaged by making a hardcoded version of the script with that night's exposure duration explicitly set in the script, requiring no parameters. This is, however, pretty inflexible as I'd need a pile of scripts with various potential exposure values to cover all possibilities.
Was the loss of the ability to pass parameters in these scripting fields an unintentional regression, a change in behaviour, am I missing some syntax or something else?
As an additional ask, do these fields have any support for passing "dynamic" variables obtained from the Ekos GUI such as the configured capture count, delay, gain, ISO, etc? I don't currently need this functionality, but I can envision future scenarios where such options would be quite helpful for further customizing external script behaviour.
The following user(s) said Thank You: Brandon R
2 years 10 months ago #71344

Please Log in or Create an account to join the conversation.

I believe the ideal solution to this is not to hard-code any parameters at all, but they should be passed along. I was thinking that one parameter is passed which is a JSON document. It then would be easy for most scripting languages to parse that and extract information from it.
2 years 10 months ago #71347

Please Log in or Create an account to join the conversation.

  • Posts: 3
  • Thank you received: 1
Are you confirming that these fields no longer support parameters being passed, then, when the previous post-capture script field did?
I would consider it perfectly adequate to be able to pass a single string parameter; as you say, it's possible to pack an arbitrary number of fields/variables into a structure like JSON that's passed this way if needed, and if you're writing the receiving script yourself you can build it to decode whatever is passed pretty easily. This would only be slightly less convenient for people trying to trigger a pre-built command provided by somebody else without having to write their own wrapper, but if it's easier to support a single parameter than an arbitrary number then that wouldn't be a showstopper.

Edit: As a note, if the idea you're having would be to automatically build a JSON structure that provides a set of built-in parameters to a script and have that passed when a checkbox is enabled or something, this would not work for my use-case as I must specify my RTS shutter controlled exposure time separately/independently from the exposure time configured in the capture dialog. To provide a bit more detail, I'm using an older mirrorless camera with no software/USB control support, so to control the camera from Ekos I use the CCD Simulator as my imaging camera driver and specify a very short (0.01s) "dummy" exposure, with the actual duration controlled by the post-capture script's runtime (the script stays running until the manually-specified script exposure parameter has elapsed). As long as it's possible for the user to specify their own variables/data to provide in the parameter, then it should work for all cases. Having automatic/builtin or manual support for passing dynamic variables from the GUI in the same structure would also be a useful/helpful bonus that would cover other use-cases elegantly.
Last edit: 2 years 10 months ago by siberx. Reason: Additional clarification
2 years 10 months ago #71349

Please Log in or Create an account to join the conversation.

There was an update to Qt way of starting executables, hence the parameters are no longer passed this way. The JSON single parameter could be a good compromise that can be achieved without adding much complexity (and hence time). Of course, if someone wants to take a stab at this and improve it to enable dynamic parameter handling, then go ahead.
The following user(s) said Thank You: Brandon R
2 years 10 months ago #71350

Please Log in or Create an account to join the conversation.

  • Posts: 12
  • Thank you received: 3
You could possibly get the info you need from d-bus.
For instance - if the job is already running (which it should be to trigger the pre-capture script), then the Exposure time could be determined from D-bus using the Kstars/Ekos/Capture methods "getActiveJobID" and "getJobExposureDuration".
However, if you need to know this before the capture is started - it won't work, because getJobExposureDuration needs an active Job ID to return the exposure value.

I tested this with python and pydbus and it works. (was looking for an alternate to monitoring RTS for something I'm working on and came across this thread)
from pydbus import SessionBus
 
# Connect to d-bus session bus
bus = SessionBus()
 
# Create an object for kstars/capture - allows access to properties and methods.
busObject = bus.get(
    "org.kde.kstars", # Bus name
    "/KStars/Ekos/Capture" # Object path
)
 
# Introspection returns an XML document containing information
# about the methods supported by a d-bus object 
#print("Introspection data:\n")
#print(busObject.Introspect())
 
#  get active job ID
id = busObject.getActiveJobID()
# print exposure value for active Job
print(busObject.getJobExposureDuration(id))

should be able to get same info in a shell script using dbus-send command line tool
2 years 2 months ago #79715

Please Log in or Create an account to join the conversation.

  • Posts: 3
  • Thank you received: 1
This is actually a really clever approach; I hadn't considered querying the Ekos engine "just-in-time" via API after launching the script to get parameters from it. The timing might be a bit tricky; you'd need to set it up as a pre-capture script and have it fork so control returns from the script, then wait a short amount for the exposure to start and then query the value, then ensure the script finishes at approximately the same time as the fake main exposure, but with a bit of tweaking this would likely do the trick.

I'm not currently using the RTS trick described in this post as I've switched over to a camera with proper driver support so I can plate solve, but if I end up running my old camera piggyback for widefield exposures on the same mount then this approach should let me synchronize exposures between the two units with minimal additional configuration. Thanks for the great idea!
2 years 2 months ago #79717

Please Log in or Create an account to join the conversation.

The scripts should really send some info when executing the external scripts, but I haven't got around to deciding on which data exactly to send, with which format..etc. I thought maybe the community can step in and help shape this approach.
2 years 2 months ago #79718

Please Log in or Create an account to join the conversation.

  • Posts: 12
  • Thank you received: 3
I got this working and it really wasn't tricky at all - and no timing issues so far.
And I would also like to say thank you for this thread - without it, I probably would never have though of using the d-bus interface to get the exposure parameter - it just kinda came to me after thinking - damn there's gotta be a way to get this info if I can't pass a parameter.
As for the question of what parameters would be useful to scripts - sorry I'm way to new to this to have much input, (2 months of playing with Ekos/INDI and I only got my 1st long exposure/multi exposure session last night)

Setup:
  • IR Led (with 220 ohm resistor soldered to anode (+) pin) connected to Rpi GPIO ground and trigger pin (I used physical pins 12 for trigger and 13 for ground)
  • Borrowed a c++ program for IR trigger (github.com/outofjungle/NikonRemote/blob/master/NikonRemote.cpp) and modified it to use "wiringPi" instead of "arduino". Then added a cmd line argument so it will trigger the IR led immediately or at a specific number of seconds.  (sub-second triggering is always handled by INDI Nikon driver, so I'm not to worried about accuracy of this trigger mechanism)
  • Created a Python script that queries d-bus for exposure time and if successful - triggers the NikonRemote IR program immediately (via subprocess.run()) and then creates a spawned child process (via subprocess.Popen()) to create a NikonRemote process that will trigger the shutter again after X seconds.  (I don't know how acurrate the timing is, so I never exceed 29 minutes as the camera has a 30min maximum shutter duration and I don't want the IR to trigger if the camera has already closed the shutter.). The python script then immediately returns control to Ekos while the 2nd NikonRemote process continues to run as a background process.

How it all works for a session is pretty simple - only one extra step (bullet 3):
  • My camera is always in full manual mode with "bulb" as the shutter speed. (NOTE: INDI driver will not use bulb mode for shutter speeds below 30sec - as far as I can tell from scanning the code - and testing seems to confirm this). However - I suppose that could change in the future...
  • Setup my rig with Nikon DSLR INDI driver (via PTP) - normal polar align, align, focus - all this is done with the camera in normal "capturemode" setting of "continuous low speed" allowing full control via normal INDI driver.
  • Once I'm ready to start sequencing - go to "INDI Control Panel" and in the Nikon Tab - under the "capturesettings" tab, find "capturemode" and change the dropdown to "Quick Response Remote"
    • it seems that if you change it here instead of on the camera - the 15min Remote timeout does not seem to be a limitation
    • I'm also running my camera with AC power - so I'm not concerned about battery drain caused by IR sensor waiting to be triggered - which is something the manual mentions
  • In Ekos under the "Camera" tab in the "Script Manager" dialog box - enter "NikonRemote.py" as the Pre-Capture script.
  • Set your exposure to any value above 30 sec (I wouldn't trust it for anything less 31 sec - driver might try to trigger shutter as well) and below say 1740sec (29 min) and fire away normally
  • and that's it
Capture preview works.
Sessions work
The only problem I had was the IR Led shifted because I didn't fasten it to the camera securely enough and I lost 3 of the last 15 images of my session (unfortunately - Ekos is not able to determine that a new image hasn't been captured and just keeps downloading the last image on the SD card. I could set the INDI driver to "delete" instead of "save" for captured images - but I'll have to think about that...)
I'm actually running the NikonRemote IR trigger executable on my Rpi attached to the mount and the Python script on my computer in the house, where I run Kstars/Ekos. I run the NikonRemote executable via SSH and Private keys from within the python script.

Is this a great solution - not really.
Does it work - you bet.
I've ordered a USB relay and Nikon remote trigger cable and will be changing this over to a better solution once they arrive in a couple weeks.
If you want any of the scripts or code - let me know.
Oh, and this is all Linux & Rpi based - so if you're using windows or mac you might have to do some coding work.

Cheers
2 years 2 months ago #79778

Please Log in or Create an account to join the conversation.

Time to create page: 1.347 seconds