MaslowCNC / Firmware

Maslow Firmware
GNU General Public License v3.0
261 stars 136 forks source link

Add simduino program for simulating and debugging Maslow #406

Closed idoc closed 6 years ago

idoc commented 6 years ago

I've created a wiki page with more details: https://github.com/MaslowCNC/Firmware/wiki/Running-the-firmware-in-a-simulator

blurfl commented 6 years ago

Very nice!

idoc commented 6 years ago

Thanks! If you try it out, please let me know how it went.

And then I'd love some help figuring out how why GC still won't talk to it :)

blurfl commented 6 years ago

GC expects the target machjoine to reset when the connection is established n(see GC issue #638 https://github.com/MaslowCNC/GroundControl/issues/638. If you like, I can show you the change I made to serialPortThread.py that made the Teensy3.5/3/6 work with GC...

idoc commented 6 years ago

Ooh! I bet you that's exactly the problem. Yes, if there's an easy way to work around this, I'd love to give it a try.

blurfl commented 6 years ago

Sorry for the delay, here's a copy of serialPortThread.py with the change (see line 106). serialPortThread.py.zip

When I'm working with a Teensy, without this line GC shows 'Connected on port./.../...' but no more. With the line the normal sequence occurs.

idoc commented 6 years ago

Thanks! I think that helps.

GC now correctly complains that my Maslow needs calibration, so that's some improvement. I can even get GC to try to move the sled, but then the simulated Maslow gets stuck in an infinite loop, when GC send " G91 G0 X-3.94" . Let's see if I can put the debugger thing to use and find out why.

idoc commented 6 years ago

Ah! I think I understand what's going on. Tell me if this makes sense:

I moved runsOnATimer() into the main loop() function, as a workaround for the missing timer functionality. I figured it would still get called often enough for the simulator's needs. And that seemed OK, because I never got GC to work, so I never really tried processing G-code and moving the sled in the simulator.

When the G0 is being processed, loop() calls gcodeExecuteLoop(), which ends up calling singleAxisMove() in Motion.cpp. singleAxisMove() goes into a loop, waiting for the sled position to change, but that never happens, because now there's no timer calling runsOnATimer().

Did I get the flow right?

runsOnATimer() will get called occasionally in loop() when the sled isn't moving, because gcodeExecuteLoop() returns. But once Maslow expects the sled to move, gcodeExecuteLoop() won't return until motion is done.

Looks like I need to get that timer running.

blurfl commented 6 years ago

Since much of the important code is scheduled by the timer, having it running would make the simulation much more useful... I think that PRs #385 & #386 made the PWM portion of TimerOne unnecessary. If so, that could help simplify the task of getting the timer to run in simavr.

idoc commented 6 years ago

Hmm... I'll have to dig deeper into this tomorrow. Monday is big on boring status meetings, so hopefully I'll have a chance to try a few ideas :)

krkeegan commented 6 years ago

Sorry, struggling to keep up with all the activity. @idoc I believe your summary is correct. If you want a function that is called frequently during the loop you probably want.

execSystemRealtime()

I believe this will get called way more frequently than the loopinterval, so maybe you also want to add a last ran variable and only run the routine if the elapsed time exceeds loopinterval?