Why does the Wokwi Simulator hang GRBL?

Projects General Guidance
1

Here's gnea/grbl v1.1h on a Wokwi simulation:

It seems to hang relative to an actual Arduino Uno.

If I enter these commands in:

    $RST=$ (set settings to default)
    $$  (show settings)
    ?? (show status)
    G1 X1 F10 (move)
    ?? (show status)

The output is:

error:7   (eeprom read failure -- expected)
$0=10
$1=25
$2=0
$3=0
$4=0
$5=0
$6=0
$10=1
$11=0.010
$12=0.002
$13=0
$20=0
$21=0
$22=0
$23=0
$24=25.000
$25=500.000
$26=250
$27=1.000
$30=1000
$31=0
$32=0
$100=250.000
$101=250.000
$102=250.000
$110=500.000
$111=500.000
$112=500.000
$120=10.000
$121=10.000
$122=10.000
$130=200.000
$131=200.000
$132=200.000

Grbl 1.1h ['$' for help]
>:error:7  (eeprom read failure -- expected)
>:error:7  (eeprom read failure -- expected)
[MSG:Restoring defaults]
ok

Grbl 1.1h ['$' for help]
<Idle|MPos:0.000,0.000,0.000|FS:0,0|Pn:XYZ|WCO:0.000,0.000,0.000>
ok
ok
<Run|MPos:0.000,0.000,0.000|FS:10,0|Pn:XYZ|Ov:100,100,100>
ok
<Run|MPos:0.000,0.000,0.000|FS:10,0|Pn:XYZ>
ok
error:8  (not idle )

GRBL doesn't move the steppers, never comes out of run mode, and blocks further movements and the $$ command.

I opened a github issue for Wokwi for this at Timer1 WGMmode=0b0100 / CTC(TOP=OCR1A) issue? · Issue #122 · wokwi/avr8js · GitHub where I suspect it is some edge case with the timer configuration, but I'm
not sure how to diagnose this difference between silicon and simulation.

I was amazed that you can run gdb on the Wokwi-simulated AVR:
Timer1 WGMmode=0b0100 / CTC(TOP=OCR1A) issue? · Issue #122 · wokwi/avr8js · GitHub You can set breakpoints in your sketch and single-step through the code.

Any suggestions for how to figure out what might be the problem?

2

Post a block diagram!

Regarding Grbl there's a sender and a receiver. Where does the simulation fail? At the sender or the receiver?

3

I haven't figured out how to attach to an external sender on my mac, but it seems like it would be possible on Linux--in the diagram.json you can connect the serial to other ports:
wokwi-serial-port.ino - Wokwi Arduino and ESP32 Simulator

I've used the Wokwi serial console to enter commands manually.

The failure is that the stepping doesn't seem to happen and it sticks in the Run state.

4

Posting links to projects or other large documents cuts off a lot of helpers that don't spend a lot of time to dig up the nucleus of Your project.
Do the filtering and post the central information here..

5

There's the Wokwi setup which I've tried to pattern off of the standard grbl connections:

image
image990×1042 98.5 KB

If you disable the soft and hard limits, and disable the HOMING_INIT_LOCK, you can run GRBL on a bare silicon UNO without any hardware connections, and interact with it. If you run similarly configured grbl with a bare UNO in Wokwi, it also gets stuck in Run. The block diagram for that is just a bare Uno.
Here's an almost bare Uno with grbl:
grbl.ino - Wokwi ESP32, STM32, Arduino Simulator

It also hangs in Run on a Nano and a Mega.

I agree. I'm not sure how to trim the multiple-file grbl software down to a minimum reproducible example. I tried Timer1_TimerHelpers.ino - Wokwi ESP32, STM32, Arduino Simulator to exercise the Timer1 mode 4 similar to grbl's inner workings, and Wokwi seemed to handle everything I threw at it.

grbl is complicated software, with a few levels of seemingly unsupported forks, but grbl is very well tested on silicon. The Wokwi software is also complicated, and it's hard to pinpoint just what is wrong with the simulator that makes grbl not work. Wokwi drives steppers OK with 2-6-axis gcode software on Mega and Uno using code from GitHub - MarginallyClever/GcodeCNCDemo: a simple example of making a CNC machine from an Adafruit Motor Shield so the problem isn't the simulated stepper hardware.

It is the interaction between grbl's complicated internals and Wokwi that seems to be the problem.

6

Grbl is commonly used for CNC machines, 3D printers etc.
I use a Grbl sender sending commands to a little CNC.
Sorry but I don't understand Your problem. Referring to a simulator makes things difficult. Why not get into the real world and run things?
Does that simulator send commands to a physical rigg?

7

I understand what grbl is used for. What I see the simulator valuable for is for debugging or developing grbl.

My problem is that the Wokwi simulator has a bug that is demonstrated by grbl, but it is difficult to suss out exactly what the bug is

Since it is possible to connect the simulator to the outside world through serial or ethernet, there might be ways for the simulator to send commands out to physical rigs, but that isn't what I'm attempting.

8

Let's hope somebody pops up that know that simulator. I don't know it.

9

I switched the title around--it isn't a grbl problem.

10

Found another Wokwi Timer1 problem, but I don't think it is what's messing up grbl.

Grbl's timer code appears to be:

Any hints on distilling grbl down to a minimum reproducible example?

11

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.

13

It is a timer problem.

I hunted it down in a separate Wokwi instance:

(The PINC=bit(4); trick and monitoring A4 was very helpful. )

I identified it as a Wokwi issue of Timer1 WGM Mode 4/CTC(top=OCR1A) when OCR1A = 0. See Timer1_TimerHelpers_CTC_OCR1A_0 - Wokwi ESP32, STM32, Arduino Simulator for a trimmed down demo of the issue.

A workaround for GRBL is to set OCR1A to something non-zero inside the stepper.c:st_wake_up() routine. OCR1A = 0x7FFF; seems to work OK. I didn't change it in the OP sim, because I want to keep that using the official grbl source.

I've reported it in Timer1 WGMmode=0b0100 / CTC(TOP=OCR1A=0) issue? · Issue #122 · wokwi/avr8js · GitHub and I'm confident Urish of Wokwi will fix it soon.

ETA: This Wokwi timer problem might be a while--triggering an interrupt whenever 0 rolls over to 0 might need some deep changes.