search

vlachoudis / bCNC

GRBL CNC command sender, autoleveler and g-code editor
GNU General Public License v2.0
1.54k stars 528 forks source link

GRBL1 processing of $# parameter response #1753

Open rschell opened 1 year ago

rschell commented 1 year ago

I have a grblHAL controller and when I issue a 'G43.1" command then check the parameter response I get the following:

ok g43.1z3.0 ok b'$G\n' [GC:G0 G54 G17 G21 G90 G94 G43.1 G98 G50 M5 M9 T0 F0 S0.] ok $# [G54:-357.000,-757.000,-148.306] [G55:0.000,0.000,0.000] [G56:0.000,0.000,0.000] [G57:0.000,0.000,0.000] [G58:0.000,0.000,0.000] [G59:0.000,0.000,0.000] [G59.1:0.000,0.000,0.000] [G59.2:0.000,0.000,0.000] [G59.3:0.000,0.000,0.000] [G28:0.000,0.000,0.000] [G30:0.000,0.000,0.000] [G92:0.000,0.000,0.000] [HOME:0.000,0.000,0.000:0] [TLO:0.000,0.000,3.000] [PRB:0.000,0.000,0.000:0] ok

Note that the TLO response consists of three coordinates rather than one. The present GRBL code is using: CNC.vars[word[0]] = word[1] which converts to CNC.vars["TLO"} = 0.000

For my controller, I would suggest the following would be a better approach: idx = -1 if len(word) > 4: idx = 3 CNC.vars["TLO"] = word[idx]

Edit: This would accept a TLO response of Z, XYZ, XYZABC, or any other 4+ axis answer. Looking at the grblHAL report.c code, more than 3 values appears to be possible.

Also while I was debugging this issue, I noticed in this square bracket code, it is written in the long form of case logic using if/elif statements, but the second, third, and forth cases are coded with if's rather that elif's. The "PRB" response is processed twice because of this. Once at the beginning and a second time in the else: clause. I don't know if this is intentional that "PRB", "G92", "G28", and "G30" get handled this way. As it stands, GRBL1 is creating CNC.vars for "PRB", "G92", "G28 and "G30" in addition to the coded treatments there.

rschell commented 1 year ago

A scan through the source code, I do not find CNC.vars["PRB"], ["G92"], ["G28"] or ["G30"] referenced directly. The closest is setting "PRB" = None in CNC.py.

On a side note, "TLO" = 0.0 is set twice and "tlo" = "" in CNC.py. Is the lower case version used anywhere?

Code cleanup in order?

rschell commented 1 year ago

On closer inspection, the new CNC.vars where intentional, they are just getting set twice.

rschell commented 1 year ago

Turns out that the default grblHAL core default setting in config.h is:

//#define TOOL_LENGTH_OFFSET_AXIS Z_AXIS // Default z-axis. Valid values are X_AXIS, Y_AXIS, or Z_AXIS.

results in the TLO response containing all axes, even though the default listed says Z-axis. Defining TOOL_LENGTH_OFFSET_AXIS to Z_AXIS results in just the single coordinate response. Still would be good to modify GRBL1.py to correctly interpret either response.