Tech support for Javascript Macros in CONTROL

OpenBuilds-CONTROL/app/js/main.js at f3c9b79ecdea7bac5a151a3fbd776d5272162c6d · OpenBuilds/OpenBuilds-CONTROL

 

So false is OK for what I'm trying to do (it basically doesn't matter?).

Thank you.

 

Correct

 

G38.3 is probe with no error. Try G38.2 so you can see what the Probing error was?
The .3 is hiding the true error that causes the lockout in the first place. Error 9 always comes after some earlier error/alarm, and they key is knowing what that one was... With G38.3 you don't know why the probe failed, you only see the next symptom of it being locked out

G38.2: Probe towards the stock, error on a failure.
G38.3: As G38.2, no error on failure

 

I see it ran through a couple of probe cycles OK.
The original error was on G21 still, but this got repeated for the G38 command. The first two G38.3 commands competed OK.

I have no idea.

Is anyone else with a BB32 willing to try out this macro to see if they get the same error?

 

I see. Jog command ran. Content of string did trigger the $G checker (not needed, but shouldnt hurt)
But then it was already locked when the G21 was sent. Whatever Errored or Alarmed did so silently before the G21 was even sent
Error 9 is the symptom, of an earlier error/alarm that placed Grbl into a locked out state (ALARM state usually) - why we don't see that one being raised is interesting and the silentness made me wonder about the G38.3

[13:35:22] [ $J=G91G21Z2F1000 ] ok
[13:35:22] [ $G ] [GC:G38.3 G54 G17 G21 G91 G94 G49 G98 G50 M5 M9 T0 F200 S0.]
[13:35:22] [ $G ] ok
[13:35:22] [ ] error: 9 - G-code locked out during alarm or jog state [ G21 ]
[13:35:22] [ ERROR ] error: 9 - G-code locked out during alarm or jog state [ G21 ]

 

As previously, the probe completed OK (the G9 error started at the G21 command again). I *might* have sussed it though:

The macro is commanding a Z move with a feed of 1000.
Your machine is set for a maximum Z speed of 1000 mm/min.

Can you increase your Z maximum speed setting ($112) to something >1000 (1100, say?) and then try re-running the macro?

 

I give up ! ​

 

MisterG you have regular Grbl right? Not grblHAL?

One last thing we can try is just latest grblHAL (our included image is from around May 2023)


http://svn.io-engineering.com:8080/?driver=ESP32&board=BlackBox X32

Just incase its a grblhal bug of some sorts. With latest firmware if it persist we can perhaps ask Terjeio (grblhal dev)

 

I’m using GRBL_ESP32 (just to complicate matters!)

 

That really does! Hehe
But that means you could try grblHAL as you have an ESP based board?

 

Yes, when I've got a minute I'll flash a spare ESP32 with GRBL_HAL and see what happens. It's not a standard board, though, so I need to cross-check the I/O assignments.

(ETA: I can probably try standard GRBL more quickly.)

 

OK, that was quicker than I thought it would be (I basically only needed to worry about the probe pin):

With standard GRBL (V1.1h) on a fake Arduino Uno the macro runs OK.

With GRBL_HAL (freshly flashed from Control) I get 'error 9' as reported by @Niuulh

(As an aside, I noticed that the probe status in the troubleshooting tab doesn't seem to work in GRBL_HAL, but it does for standard GRBL despite this, the 'Z' probe routine (for example) successfully detects that the probe contact has closed.)

 

Try $10=511 to fix the Troubleshooting tab (just the report Mask)

If you have a moment

 

$10 was already set to 511 (I loaded a machine configuration from the library in Control) - I set it to something else, set it back & restarted everything and the probe flag still doesn't seem to work on the diagnostic screen.

I downloaded the new firmware and flashed it, and now the probe dooesn't work at all - I will investigate further tomorrow after I've had a good sleep!

 

OK, I have done some more testing, but am not very much wiser....

The probe diagnostic thing went away (possibly my shonky wiring on the test ESP32).

I have tried the following without success (still error 9):

i) The current version of GRBL_HAL;
ii) The current version of GBBL_HAL compiled with the compatability level set at 10;
iii) Reverted back to the version of GRBL_HAL that Control flashes
iv) Altered macro to avoid possible trailing or leading newline characters*
v) Altered macro to build strings to send using explicit \n character rather than relying on newline in the editor* (notepad++)
vi) Altered macro to replace $J command with G0*
vii) Altered macro to remove commands in the job string after the G38.2 probe command
viii) Reverted back to an earlier version of the macro

All of the various versions of the macro ran OK on standard GRBL on an Arduino Uno clone, and on GRBL_ESP32 (which Control detects as standard GRBL, I think).

I then set up a port sniffer to compare the communications between standard GRBL and GRBL_HAL (current verson flashed from Control).

I can detect *no* difference in the strings sent in each case, yet this causes an error 9 in GRBL HAL.

For reference, the commands that are sent are:

Code:

G21
G53 G0 Z-5
G30 G91 X0 Y0
G30 G91 Z0
G21
G38.3 Z-45 F150
G4 P0.4
$J=G91G21Z2F1000
G21            <--------------I think this causes error 9 under GRBL_HAL
G38.3 Z-5 F30
G4 P0.4
$J=G91G21Z2F1000
G21
G90

As far as I can tell, the code above is perfectly legit, but for some reason, GRBL_HAL flags up an error.

I've attached several files from the port sniffer (I have deleted some of the idle messages and replaced them by [...]):

The zip file contains two html files that show all communication in sequence with TX and RX colour coded (these are the easiest to make sense of).
The XXXwrite.txt files show the hex characters sent by the computer.
The XXXread.txt files show the hex characters sent by the ESP32. (The activity in both of these are time stamped, so it is possible to read them side by side.)

I am completely at a loss at the moment!

*The original syntax is the one used for several of the sample macros, and as per the sniffer files, generates the expected code :

Code:

                var tc_probe =  `
                    G21                    ;set mm mode
                    G38.3 Z-` + tc_seekdistance + ` F` + tc_seekspeed + ` ;probe using parameters at the top of the macro
                    G4 P0.4                ;pause
                    $J=G91G21Z` + tc_retract + `F1000    ;jog up by retract paramter at the top of the macro
                    `
                socket.off('prbResult'); // Disable old listeners
                socket.emit('runJob', {
                    data: tc_probe,
                    isJob: false,
                    completedMsg: "",
                    fileName: ""
                });

[Edit - added the serial log from when GRBL_HAL connects for version numbers, etc. Control is v1.0.370]

 

Great testing. Lets tag in @terjeio

 

Theres a lot of spaces after the G21, before the semicolon for the comment. Might be worth a shot, but i would have expected it to be filtered. I don't think we filter spaces, as I am quite sure Grbl ignores them and we avoid modifying the job as much as possible. Sorry out of office, just caught my eye on a second look through.

 

No worries - I get the same response if the string is built like this:
var tc_probe = "G21\nG38.3 Z-" + tc_seekdistance + " F" + tc_seekspeed + "\nG4 P0.4\n$J=G91G21Z" + tc_retract + "F1000\n";

From the port snooper, neither the spaces or the comment are sent, anyway.

 

Figured. Sorry shot in the dark... And a Miss. It happens

 

I hate unfinished business:

@Niuulh - try this, if you wouldn't mind?

It works on my GRBL_HAL test setup (just a bare ESP32 and a probe switch!) and on my GRBL_ESP32 real machine.

Thanks.

[Edit 17/9/23 - FIle deleted to avoid duplication. Please see this post instead. ]

 

Curious, what was it?

 

Yay!

The $J command was the problem. It seems that GRBL_HAL will not accept any other commands after a $J within the macro, even though standard GRBL does. I thought I had eliminated this in earlier testing, but apparently not.

I'll update the version in the other thread assuming no adverse report from @Niuulh

 

I suspect that throwing the error should be the expected behaviour, but for reasons I have been unable to fathom, the same macro generates an error in GRBL_HAL but not in GRBL. In further testing, I have been unable to recreate this outside the macro execution (e.g. just sending GCode strings).

(I don't know why the $J command was originally used to retract the tool after probing - I just copied one of the examples )