Difficulty with GRBL being non-responsive

LightBurn Software Questions
1

New user, so forgive if the question has been covered - a search didn’t turn up anything related.

  1. I’m using a S03XL, have been using it for quite some time without difficulty.
  2. I have upgraded to a SuperGerbil control board. The software is 1.1f, ported to ARM.
  3. This supports A and B axis, which I am not currently using.
  4. I’ve been using it just fine with UGS and other senders

Where I’m having trouble

  1. I can connect to the controller and jog. That seems ok.
  2. clicking “get position” never returns any data in the display.
  3. After homing, no commands via the console work at all. $$, $X, $, ? do not return responses.

I suspect that this is related to the additional information returned in the status messages for the additional axis (ie. 5 axis instead of 3) . GRBL doesn’t have a means to manipulate the report format, so I’m not sure where to go from here.

Any easy ways to get through this?

example:
Waiting for connection…
ok
Homing
ok
?
<Idle|MPos:0.000,0.000,0.000,0.000,0.000|Bf:15,254|FS:0,0|Pn:PAB|WCO:-219.988,-370.000,-90.000,0.000,0.000>
$
?
$$
$X

2

I’ll have to add code to handle the additional axis reports - I’ve never seen that before, and it’s likely the code doesn’t handle it.

Having said that, it shouldn’t affect whether you get a reply back from $$, $#, or ?, unless the extra state is confusing my parser and resulting in a locked state somehow. I notice that there’s no ‘ok’ after the status report. I believe normal GRBL does this, and LightBurn expects it. That might actually be the problem.

3

Strange that there is no ok acknowledgement since this part of the code has not much changed from the Grbl arduino part. Only the N=3 is now N=5 because of 5 axis. The change in firmware can be achieved easily and I am thinking $10 can be modified to include the option to turn off the A and B axis reports.

4

May be worth trying 1.1h?

5

Can’t run “straight” arduino GRBL.

6

Can’t you recompile?

7

Gerbil is an STM chip, so it would have to be from Awesome Tech’s branch of it, and would require that dev environment and tool chain.

8

I understand that.

Their port is on GitHub, along with the build files.

Interestingly the latest Awesome Tech build is ver 1.1e, but the version the OP is using is 1.1f.

I cannot find a 1.1f version from Awesome Tech, which raises the question of where it came from.

The STM32 is a common port for grbl and there should be nothing special about any toolchain used by Awesome Tech.

Follow this video and you will build a working version of 1.1h on an STM32, including on Gerbil: https://www.youtube.com/watch?v=5DBtbAYmfEE

9

There are some 1.1f changes in it - among other things (ie. additional axis) - I’m not sure the extent.

I’ve actually tried to recompile a couple times over the past few months, and have not been successful yet, but have been trying to do so a little round-about… The atollic compiler appears to be the only one that works right, the STMcube compiler says it can import the old projects, but hasn’t worked for me. I’ve got to set up a linux vm to use atollic, and just haven’t done so yet.

GRBL is at 1.1h, which has some additional fixes around doors and coolant that are probably not too interesting here.

10

Sometimes I forget my audience. :slight_smile:

1 Like
11

No worries. Sometimes I forget my manners :wink:

12

I realize you’re just trying to help, but no, there appears to be something special about the atollic toolset.

13

There are other toolchains for the STM32 - like System Workbench (SW4STM32) - available from https://www.openstm32.org/System+Workbench+for+STM32

I would always go for Eclipse-based IDEs. I understand ST just bought Atollic, but they promote System Workbench…

It’s multi-platform so you should get away without creating a VM.

You can even add STM32 support to the Arduino IDE.

14

Any chance of getting this in the next release cycle?

15

I’ve logged it as a bug and set it high priority, but I have a few vendor needs ahead of it, so it might or might not make it into this release, depending on workload.

1 Like
16

I’ve looked at the logic in this code, and I think it’s the missing OK response that’s the root of all of this. The code already handles varying counts of values, because GRBL can be compiled as 3 axis or 4 axis easily, so I generalized it to handle “any”. The missing OK would mean LightBurn was still waiting for GRBL to finish responding, and since it never gets the completion acknowledgement, it never returns your result.

The logic that parses out the MPos value does this:

  1. Take everything between the <>'s, split it up into chunks using | as the delimiter
    This will give you a list containing (Idle), (MPos:0.000:0.0,.0,0.0,0.0), (Bf:15,254), … etc

  2. Each one of the entries above is parsed looking for MPos: or WPos: as a prefix. If found, go to the next step

  3. The MPos: or WPos: prefix is removed, and the values are split by commas, which would give us a list containing (0.0), (0.0), (0.0), (0.0), … etc

  4. If the list contains more than 1 value, it’s considered valid and pulls out X & Y. If it contains more than 2 values, it pulls the 3rd as Z. If it contains more than 3 values, it pulls the 4th as A.

17

That’s all a fair statement and all… but I don’t think the “ok” is the basic problem - I DO get “ok” for everything I’ve tried on UGS. Everything in this case seems to be working fine until this point- I can issue commands, it only break when I get to this point of asking for “get position” - then things are broken. I understand what you’re saying, and you know the code better than anyone, but something isn’t working right in this particular case.

18

Rather than clicking Get Positions, just type ? into the console and press enter. You should get an ‘ok’ response, after the info with coordinates.

19

I did this:
$H

ok

$$

$0=6

$1=255

$2=0

$3=3

$4=0

$5=0

$6=0

$7=0

(ATC M6, pulse/ff)

$8=100

(ATC Tool Td, milliseconds)

$9=100

(ATC M6 Td, milliseconds)

$10=255

$11=0.020

$12=0.010

$13=0

$19=0

(Softstart, milliseconds)

$20=0

$21=0

$22=1

$23=0

$24=100.000

$25=4000.000

$26=25

$27=5.000

$28=0

(Spindle freq. 0 to 15)

$30=10000

$31=1

$32=0

$33=1

$100=80.600

(x:stp/mm)

$101=80.125

(y:stp/mm)

$102=320.000

(z:stp/mm)

$103=160.000

(a:stp/mm)

$104=160.000

(b:stp/mm)

$110=20000.000

(x:mm/min)

$111=15000.000

(y:mm/min)

$112=5000.000

(z:mm/min)

$113=500.000

(a:mm/min)

$114=500.000

(b:mm/min)

$120=1000.000

(x:mm/s^2)

$121=1000.000

(y:mm/s^2)

$122=500.000

(z:mm/s^2)

$123=2500.000

(a:mm/s^2)

$124=2500.000

(b:mm/s^2)

$130=830.000

(x:mm max)

$131=465.000

(y:mm max)

$132=400.000

(z:mm max)

$133=200.000

(a:mm max)

$134=200.000

(b:mm max)

ok

?

<Idle|MPos:0.000,0.000,0.000,0.000,0.000|Bf:15,253|FS:0,0|Pn:PAB>

$$

?

Note no ok, then $$ and ? don’t seem to do anything.

20

That’ll be the problem. Paul’s custom version of GRBL appears to be eating the ok at the end of <Idle|MPos:0.000,0.000,0.000,0.000,0.000|Bf:15,253|FS:0,0|Pn:PAB>

If I don’t get an ok, I keep waiting, assuming more characters are coming. I could make it terminate waiting on a carriage return, but I worry that will break something else. This works for every other controller.