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!
Thx!
