This is mostly a preparation for reverse walks through the movement queue,
where crossing speed calculation is done only once, while actually used
speeds can be raised successively with repeated walks.
Add a tool (tools/velocity_plot.sh) to read in a simulator trace
file, calculate the velocity of the X and Y axes, and show a plot
of these velocities against time along with the X and Y positions.
The nice thing about these save files is, they provide a display
for the data, so you simply load a .vcd, additionally read a
save file and you're ready to investigate your movement data.
- comment on why the case exists,
- add an M2 at the end to later allow automatic simulation stop,
- move comments to the end to avoid filling the serial buffer with
stuff unrelated to movements,
- make sure there's a line ending at the end of the file and
- use Windows line endings (they're more difficult to handle).
Moves which have no movement intention, e.g. pure feedrate changes,
and moves too small to cause a single step, are a bit tricky to
handle with lookahead. Essentially, they should be joined with the
next movement, without queueing them up.
This obviously requires less place on the stack and accordingly a
few CPU cycles less, but more importantly, it lets decide
dda_start() whether a previous movement is to be taken into account
or not.
To make this decision more reliable, add a flag for movements done.
Else it could happen we'd try to join with a movement done long
before.
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.
This script also asks SimulAVR to generate pin traces of the X
and Y axis and even processes this data into a data file with
time, position and current speed of each axis.
Missing:
- Acceleration calculation.
- LOTS of polish.
This shouldn't change the running binary at all, so it shouldn't
harm. However, it allows to run Teacup inside SimulAVR and accessing
Teacups' serial line through the console/terminal.
For detailed instructions, see http://reprap.org/wiki/SimulAVR .
Including a semicolon in a macro function causes problems
when the "function" is called inside an if statement. Fix
four cases in pinio.h where this error exists but currently
is not harming the code.
Teach simulator several command line options to control console output
of info messages, gcode traces, data_recorder output, etc.
Also move gcode output to sim_gcode instead of sending directly to
datarecorder.
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.
The simulator runs as a device simulator complete with serial port
so it can communicate with printer software like pronterface. But
often we just want to stream it a file of gcode commands and get
some output. Teach the simulator to take a regular file as input
and process it as a file of gcode commands if it is not a device.
In AVR the labs() function takes a 32-bit signed int parameter. On
the PC it's at least 64-bits and maybe more. When we have a 32-bit
unsigned value we're taking the labs() of, coercing it to 32-bits
first turns our high-bit into a sign, but coercing it to 64-bits
does not. This causes all our negative values to appear to be
really big positive ones.
Create a new function abs32() which always coerces its argument to
a int32_t first before return the abs value. Use that function
whereved needed in dda.c.
This fixes a problem on the simulator which caused negative
direction movements to "never" end.
research/datalog.plot is a gnuplot script to plot pin outputs like
a logic analyzer and x/y/z positions as well. It's quite rudimentary
but it does recognize some keyboard commands to pan and zoom.
Be careful with keyboard repeat getting too far ahead of you.
Reduce the simulated timer to 1/10 actual time. There is no need
for the simulator to run at full speed for now, and some PCs may
not be able to attain real-time speed anyway due to PC clock
speed, scheduler slack or OS differences.
Maybe the simulated timer interrupt is not needed at all and some
cooperative timer interrupt could be used instead. Such a setup
may even run faster as it could also run >1.0x time when there is
nothing to do. This bears investigation later. For now, the
simulated timer interrupt seems more realistic and possibly valuable.
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
Dependency automation seems a bit confused in these makefiles.
Clean it up following ancient sage wisdom here:
http://mad-scientist.net/make/autodep.html
In short, use -MMD to generate dependency files for each .o target,
and then use a sed script to extend that to avoiding "missing file"
dependencies when headers are renamed/removed.
Also, make everything dependent on makefiles other than our
autodependency (*.P) makefiles.
Make the BUILDDIR an order-only prerequisite for our targets so any
changed file therein does not cause all other files to appear to be
out of date.
Also, some makefile cleanup:
- Remove obsolete 'depend' target.
- Move AVR-specific targets to AVR makefile.
- Add TARGET variable to identify target to make and to clean.
- Tidy up dependency make.
Next-interrupt-time calculations were made in 16-bit registers but
moved to 32-bit ones for convenience. But they forgot to round off
at 16-bits. Force the round-off so we do not wait forever.
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
David Forrest
Phil Hord
Johannes Schriewer (Dunkelstern)