×

INDI Library v1.9.4 Released (17 Jan 2022)

Bimonthly Stable INDI Library release introduces new drivers and fixes for existing ones. Some highlights:

Ekos Scripts Manager does not accept parameters

  • Posts: 2
  • 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
8 months 4 days 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.
Jasem Mutlaq
Support INDI & Ekos; Get StellarMate Astrophotography Gadget.
How to Submit Logs when you have problems?
Add your observatory info
8 months 4 days ago #71347

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

  • Posts: 2
  • 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: 8 months 4 days ago by siberx. Reason: Additional clarification
8 months 4 days 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.
Jasem Mutlaq
Support INDI & Ekos; Get StellarMate Astrophotography Gadget.
How to Submit Logs when you have problems?
Add your observatory info
The following user(s) said Thank You: Brandon R
8 months 3 days ago #71350

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

Time to create page: 0.471 seconds