Request: DragScript "after action" report

As you had mentioned in a post on CN, you keep detailed statistics on the various stages of operation in a DragScript to manage the time values in the stages … you had also mentioned that it may be possible to expose that to an end user in an XML format rather than the current raw data.

Currently I need to be able to record information relating to the time needed for various operations (slew, plate solve, focus, image download, etc.) to allow me to forecast sequence times for another program I use, SkyTools4. My current method is quite coarse: for each DragScript action I call an external program to record the event to a unique text file such as “Plate Solve with Sync” and the clock time that happens on, then another timestamp prior to the next DragScript action. Once this is done I have a Python script dig through the text file correlating events into time durations for each action, and then after a few weeks run another correlation for individual actions … that way I know it takes an average of 45sec to do the “Plate Solve with Sync”, worst case 180sec and best case 40sec. I plug those numbers into SkyTools4 and uses those delay times to compute it’s nightly workload … good, but very cumbersome!

My suggestion, therefore, is for the ability to store an XML “after action” report for the stages in a DragScript … this could be enabled by a checkbox in the DragScript “start” dialog (where currently you can set events at start to Disable) followed by a potential path for the report file, with the filename being something unique to the dragscript name and run time/ date. This XML file would have each action that takes a meaningful time (such as slew to Target, Focus, Image, etc.) with specific data collected from the run as well as the running statistics that you keep: LowBound, HighBound, Average and Current. The XML nodes would be the same as the DragScript nodes/ names, as an example …

For dragscript X run on date Z at time A, it would contain:

±-- DragScript
±-- RunTime [0] (180, 300, 260, 250)
±-- Action
±— Plate Solving
±— Plate Solving with Sync [5] (20, 40, 25, 27)
±— AutoFocus
±— AutoFocus with RoboStar [30] (40, 60, 50, 54)
±-- AutoFocus with RoboStar [170] (40, 60, 50, 55)
±— Guiding
±— Acquiring Guide Star [85] (30, 40, 35, 33)
±-- Camera
±-- Expose [120] (40, 45, 44, 42)
±-- Expose [200] (40, 45, 44, 43)

This would tell me that for this dragscript it took a total of 250 sec to complete, of which 27 sec were for plate solving, 33 sec to get the guide star, 54 sec to focus and 42 sec to expose the images. On the average this sequence takes 260 sec to complete with the shortest time being 180 sec, the longest being 300 sec. Note that I show the runtime that a step started at but I also show where repeat(s) and loops(s) happen … looking at this file, the sequence following this DragScript was (sync), then (RoboStar Focus), then (Acquire GuideStar), then (Expose), then (RoboStar AutoFocus), then (Expose). This would handle focus failover actions as well as conditionals by following the increasing runtime values.

As an additional item it would be nice to have an XML representation of the execution flow, so for this example it would be

±-- DragScript
±-- Flow
±-- Plate Solving With Sync
±-- AutoFocus with RoboStar
±-- Acquiring Guide Star
±-- Expose
±-- AutoFocus with RoboStar
±-- Expose

That way if I really didn’t want that to happen like that it would be easy to debug my DragScript to determine why it followed this pathway …

Something to think about, as always much thanks for such a powerful program!


i think the bestway is to use the application server inside Voyager.
You can connect to it (tcp/ip port) and get with JSon RPC all the info you ask when you want. And also i can send event in push.

Its ok for you ?

I wasn’t aware of an application server inside of Voyager, I would need to know more info about it (so homework for me!) …

Since you directed me to the log file the other day I’ve already started to put together a Python script to digest it into a format similar to what I laid out, that may end up being the easiest way to get this information


Log info appear in log only when you start Voyager app, i talk about the completly list. But you can parse the log file in realtime because at end of each action a line with the statistic updated was written. Also you can found start of each actions row. I think its easy to parse … but attention … dont lock the file !! Shadow copy it and parse.

Voyager have an application server tcp/Ip able. Was made to third parts application for integration (some professional observatory use Voyager for some particular tasks) or for manage array of telescope across the lan. I can add some JSON RPC method if you need.

No documentation about … just private and relate to the costum version of Voyager.

I wouldn’t try to parse the log realtime, for me I’m only after an after-action report (although it might be useful to have my watchdog program looking for strange events) and of course I would only operate on a shadow copy of the file! :slight_smile:

I’ll pass on the application server capability … it’s too dangerous for me to potentially goof something up, but it’s nice to know that you have a JSON RPC capability … currently my interface to the watchdog application is extremely crude (literally, it’s a command line passed to a program start that pulls serialized state information at each program load from the registry) so if I could make a JSON call from within DragScript to a server and get back a JSON reply that would really open up some possibilities … but that’s way, WAY down the wish list … :slight_smile:

If you need some particular key in log with info please tell me … i add.
In this way you can parse better the data .

All the best