How to run test cases

[Cyberwizzard]

I have followed the wiki article to download and compile the simulavr version for Teacup. I am working off a clean checkout of experimental.

The first thing that I trip over is the fact that the config.h.profiling configuration uses a small move buffer while the run-in-simulavr.sh script says that the move buffer should be big enough to hold the entire test file; most files seem to have more lines than the move buffer size.

Second issue, possibly related: when running examples like short-moves.gcode, the simulator returns a lot of 'ok' messages, more than there are lines in the gcode file. The end result is that it hangs as it does not seem to reach the 'M2' code which will stop the simulation. My guess is that every 'ok' is for an entry in the move buffer which is then filled before the 'M2' is reached.

When I remove all but the first few lines, I get a lot of 'ok' messages (but less then when running the original gcode file) and the simulation does terminate.

So is it just being weird on my system or am I missing something?

[Traumflug]

The first thing

That's quite possible. As you probably can imagine, I have a number of local modifications for various situations, so I might have missed a few bits. Glad you got it working at all, so things aren't that much wrong.

IIRC the movebuffer should be long, because there's no G-code sender, i.e. nothing which waits for the "ok" before sending the next line. Anything not accepted immediately is simply lost.

That said, I think I managed to create a pipe ( mkfifo(1) ) on Linux and connect with SimulAVR on one end and with Pronterface on the other end. Then there's no file size limitation.

You can also not redirect SimulAVR input from a file and enter G-code manually from the command line, waiting for the ok's manually.

Second issue

These ok's come from Teacup, so it works. Two of them for each line, because the G-code testcases are with Windows line endings.

Also, a bit patience is required. Depending on your host hardware, SimulAVR is 5 to 10 times slower in wall clock time than a real ATmega. It simply takes a few minutes until all the movements and then the M2 gets executed. Timings inside the MCU are still accurate.

Big advantage of SimulAVR is, you always get precisely the same results. And you can easily watch and measure pin status changes; something which would require an logic analyser on real hardware.

Hope that helps.

[Cyberwizzard]

I tried increasing the size of the move buffer but when I exceed the available memory for the 644P, the simulator spews errors about incorrect addresses; how did you work around that?

I also looked into connecting pipes to simulavr but it does not seem to have any facilities for that. Or do you use a 'mkfifo' pipe together with in- and output redirection to connect them to the simulator?

So far patience was not really needed: when I did get it to work, the simulation is done in a matter of seconds for a quarter of the 'smooth-moves.gcode' file.

[Traumflug]

the simulator spews errors about incorrect addresses; how did you work around that?

I didn't. 32 moves or something is simply a limitation which didn't bother me enough to write an enhancement so far. There is sender.sh and sender-mac.sh among the source files in case you want a start.

I also looked into connecting pipes to simulavr but it does not seem to have any facilities for that.

It's stdin/stdout. Redirectable as usual.