Simulator tries to schedule zero time

[Traumflug]

Trying the simulator today, I found it to fail pretty quickly ... often after as short as 1 or 2 seconds after sending a G-code command. Diagnosis: output of steps simply hangs.

After some back and forth, I managed to find a workaround: https://github.com/Traumflug/Teacup_Firmware/commit/e3f7cabd372b71ee4eb08ef9a93994077c890795

schedule_timer() is called with zero, which can't work for obvious reasons.

@phord, do you have insight wether this is sane or does the fix just cover a real bug?

[phord]

Not sure, but I've seen it die the same way a lot. Haven't had time to track it down. I'll take a look tonight and see if anything stands out.

Phil On Nov 8, 2013 3:51 PM, "Traumflug" notifications@github.com wrote:

Trying the simulator today, I found it to fail pretty quickly ... often after as short as 1 or 2 seconds after sending a G-code command. Diagnosis: output of steps simply hangs.

After some back and forth, I managed to find a workaround: e3f7cabhttps://github.com/Traumflug/Teacup_Firmware/commit/e3f7cabd372b71ee4eb08ef9a93994077c890795

schedule_timer() is called with zero, which can't work for obvious reasons.

@phord https://github.com/phord, do you have insight wether this is sane or does the fix just cover a real bug?

— Reply to this email directly or view it on GitHubhttps://github.com/Traumflug/Teacup_Firmware/issues/50 .

[phord]

Ok, I did see this failing before before and I thought I fixed it. It doesn't happen for me now, anyway. But I see where it happens and it's a real bug.

I think your patch is reasonable and workable. I've got some other cleanup on the simulator. I'll try to polish it up tomorrow.

I see some real oddities in the simulator in addition to this, though. Not sure why, yet. I started collecting pin traces to track it down, but I got lost in the weeds and haven't gotten back to it yet.

[Traumflug]

Does trying to run the code in realtime make sense, after all? Somehow I get the impression the actual execution time isn't important. We'd need printable timestamps instead to allow making a graph about stepper motor speeds.

[phord]

Realtime is not important. But it is still possible to run into the zero-time request, I think. Try setting

#define TIME_SLOW_FACTOR 50

on line 12.

[phord]

I have some graphs of position and pinouts after running some simulations with my data_recorder. They're actually pretty nice. But getting gnuplot to show them seemed a bit torturous. Getting the data into another format (.vcd) seems like the right thing to do, but maybe it only makes it more complicated for others to use it. You have any opinions on this?

[Traumflug]

Realtime is not important.

Well, why run a timer, then?

I have some graphs of position and pinouts after running some simulations with my data_recorder.

This looks really awesome!

Regarding complexity ... I think the most you can expect from a user is to run a script as-is. Only very few dive into how to connect one part to another. So far I didn't do so myself, yet, as I've already totally forgotten how I did get graphs the last time.

As such it doesn't matter wether you write data for GNUplot or another application. Some ASCII data format is a good idea, though, to allow further manipulation with scripts, e.g. calculating speed or acceleration values.

[Traumflug]

Uhm, I see a lot of commits in your fork, @phord. Can I assume the ones on the experimental branch are thought for picking?

[phord]

They are suitable for picking, I think. I pushed them to be available in case I couldn't get more things pulled together. I probably can't today, so have at 'em. :-)

On Sat, Nov 9, 2013 at 2:09 PM, Traumflug notifications@github.com wrote:

Uhm, I see a lot of commits in your fork, @phordhttps://github.com/phord. Can I assume the ones on the experimental branch are thought for picking?

— Reply to this email directly or view it on GitHubhttps://github.com/Traumflug/Teacup_Firmware/issues/50#issuecomment-28134423 .

[Traumflug]

Done.