Before, a seemingly valid command like ...
./sim -o sim-log.log -t 0 testcases/triangle-odd.gcode
... would not act as expected (treat both files as G-code source)
and not give meaningful hints on what's going on either. It just
reported 'Could not stat file'. No hint that it tries to open the
intended log file as G-code source.
Now the message reporting opening of a G-code file names it as
'G-code source' and opening of the recorder file gets reported,
too. Which should give a good idea about what's going on.
We cheated before and sent the serial data in the simulator into
the G-code reporter so it could be line-buffered and then recorded
as comments in the trace-log. But this confuses the simulator
console output and is harder to manage. Revert to sending serial-out
data directly to the comment engine.
Also be less chatty about startup when connecting to a UART.
Add a comment to the datalog output showing how it can be viewed with
gnuplot. It would be trivial to add this as a .plot script, but it's
even easier in the datalog output.
If the recorder is initialized with a filename, write trace data
to that file. But if it is not initialized, don't complain and
don't write the data anywhere.
Cleanup datalog output a bit.
* Add close/flush on exit in case we have pending data
* Use hash for comment characters to be compatible with gnuplot
* Report x/y/z/e position in array
Record simulation run-time data in file 'datalog.out' so it
can be analyzed after-the-fact or during the run.
This feature is evolving. Eventually it should be compatible with
some logic analyzer GUIs such as gtkwave or even gnuplot.
Markus Hitter
Phil Hord