I am running an automation script, that serves two purposes.
To start a triggered capture, save result on trigger and restart capture.
To act as a supervisor, ensuring that Logic is restarted in case of a breakdown.
For the second purpose I would like to evaluate the log file in %APPDATA%/Logic/logs. But this logfile newer contains the last events, and more than often the last line is evidentially half a logline.
example: [2024-04-18 12:30:08.592] [main] [info] [logic_device_node.cp
If I compare to what I get on stdout when running Logic from a commandline, i see that the logfile is updated with a quite low frequency.
In my script i start logic using the Manager.launch() method, so as far as I can see I can’t capture stdout from that? So i am left with the logfiles, that often do not capture the loglines informing on the crash, because they are so delayed.
Is there a way to triggger a flush of the logger?
Is there a way to increase the logger update frequency?
Is there a way to capture this from the automation API?
Could the Python subprocess module help, vs. using the Manager.launch() method to start the session? I think you could use the Popen Objects and the Popen.communicate() method, which should be more interactive and not need the process to exit before reading from stdout like the subprocess.run() method.
Note: If doing this, review how to launch the Logic 2 application with automation server started, and then use Manager.connect() vs. Manager.launch() to connect to the existing process started by the subprocess module above.
However, this only gives you access to the stdout stream as requested, but may not solve your higher-level problem and cause more complicated issues dealing with nuances of Python subprocess communications. Otherwise, there might be better ways to implement a Logic 2 supervisor feature vs. trying to parse the log file and/or monitor stdout. For example, you could do a Manager.launch() + Manager.close() after each capture, or after every so many captures to just preemptively reboot the Logic 2 program?
Just curious, were you having problems with the Logic 2 program breaking down that actually needed a supervisor to restart it? Or, is it just that the target system is sometimes failing to trigger a capture, and stuck in a Capture.wait() that didn’t return? In this case, see another post about detecting when the Saleae failed to trigger.
Please note that the slow update of the logs is not so much a problem for my supervisor. It is quite general.
If Logic is started in normal way from the GUI, (by the user clicking on the icon) I see the exact same slow update of the logfiles.
So if there is a crash, and Saleae request you to send the logs, well they can be quite sure that most of the logs will miss the last 10-30 seconds. And thus probably won’t capture the problem.
With all that said.
I was considering using subprocess, or just have os.system call a bat file that ensures stdout is piped to a log. As I don’t need the stdout information inside the python program. I only wanted to ensure a proper log from Saleae to dig into, in case I see too many crashes.