Unable to "Save to Firmware"

Hi,

First, thanks for the great support you have shown everyone!

I've been having problems getting my CNC to position from CONTROL. I've narrowed it down to an issue trying to save the firmware. It seems when I do that, I receive the error:



When I press refresh, that field ($13) is always blank. The boolean drop down for this is different than the others. Note the circles instead of the check/x marks:



I wonder if that has something to do with it.

Running on a new Mac (M2 chip) with version 1.0.370.

Thanks for the help.

Rick

 

Thanks for the reply, Peter. It is set to zero, but I set it again using $13=0 and the field remains blank. It always give me this error when I try to update the new settings.

 

Running on a new Mac (M2 chip) with version 1.0.370.

 

I swore I downloaded and installed 376 the other day... Unfortunately, the problem still persists. I am using a custom machine. I noticed, looking in the JS console, that $("#val-13-input").val() returns null, whereas $("#val-6-input").val() returns the string '1'. It appears that this control is different than the other booleans.

I can set the value to enabled, save to firmware, restart grbl, but when it is refreshed, the field is blank again and I get the same error when trying to save.

 

It appears that $13 may have been skipped in grbl-settings. I added line 269 and the value appears after refresh.

setTimeout(function() {
$("#val-32-input").val(parseInt(grblParams['$32'])).trigger("change");
$("#val-20-input").val(parseInt(grblParams['$20'])).trigger("change");
$("#val-21-input").val(parseInt(grblParams['$21'])).trigger("change");
$("#val-22-input").val(parseInt(grblParams['$22'])).trigger("change");
$("#val-23-input").val(parseInt(grblParams['$23'])).trigger("change");
$("#val-5-input").val(parseInt(grblParams['$5'])).trigger("change");
$("#val-6-input").val(parseInt(grblParams['$6'])).trigger("change");
$("#val-13-input").val(parseInt(grblParams['$13'])).trigger("change");
$("#val-2-input").val(parseInt(grblParams['$2'])).trigger("change");
$("#val-3-input").val(parseInt(grblParams['$3'])).trigger("change");
$("#val-4-input").val(parseInt(grblParams['$4'])).trigger("change");
}, 100);;

 

I guess I did not full test that, it appears that $13 stays at Enabled, even when setting it to disabled.

$0=10 (step pulse,usec) ; Step pulse time, microseconds
$1=25 (step idle delay,msec) ; Step idle delay, milliseconds
$2=0 (stepport invert mask) ; Step pulse invert, mask
$3=4 (dirport invert mask) ; Step direction invert, mask
$4=0 (stepenable invert,bool) ; Invert step enable pin, boolean
$5=1 (lims pin invert,bool) ; Invert limit pins, boolean/mask
$6=1 (probe pin invert,bool) ; Invert probe pin, boolean
$10=3 (status report mask) ; Status report options, mask
$11=0.010 (junction deviation) ; Junction deviation, millimeters
$12=0.002 (arc tolerance,mm) ; Arc tolerance, millimeters
$13=0 (report inches,bool) ; Report in inches, boolean
$20=0 (soft limits,bool) ; Soft limits enable, boolean
$21=1 (hard limits,bool) ; Hard limits enable, boolean
$22=1 (home cycle,bool) ; Homing cycle enable, boolean (Grbl) / mask (GrblHAL)
$23=3 (homing dir invert mask) ; Homing direction invert, mask
$24=100.000 (homing feed,mm/min) ; Homing locate feed rate, mm/min
$25=500.000 (homing seek,mm/min) ; Homing search seek rate, mm/min
$26=250 (homing debounce,msec) ; Homing switch debounce delay, milliseconds
$27=1.000 (homing pull-off,mm) ; Homing switch pull-off distance, millimeters
$30=10000 (maximum spindle speed,rpm) ; Maximum spindle speed, RPM
$31=0 (minimum spindle speed,rpm) ; Minimum spindle speed, RPM
$32=0 (laser mode enable,bool) ; Laser-mode enable, boolean
$100=800.000 (X axis pulse:step/mm) ; X-axis steps per millimeter
$101=800.000 (Y axis pulse:step/mm) ; Y-axis steps per millimeter
$102=800.000 (Z axis pulse:step/mm) ; Z-axis steps per millimeter
$110=2000.000 (X axis max rata:mm/min) ; X-axis maximum rate, mm/min
$111=2000.000 (Y axis max rata:mm/min) ; Y-axis maximum rate, mm/min
$112=2000.000 (Z axis max rata:mm/min) ; Z-axis maximum rate, mm/min
$120=20.000 (X axis acceleration:mm/s^2) ; X-axis acceleration, mm/sec^2
$121=20.000 (Y axis acceleration:mm/s^2) ; Y-axis acceleration, mm/sec^2
$122=20.000 (Z axis acceleration:mm/s^2) ; Z-axis acceleration, mm/sec^2
$130=400.000 (X aixs max travel:mm) ; X-axis maximum travel, millimeters
$131=400.000 (Y aixs max travel:mm) ; Y-axis maximum travel, millimeters
$132=80.000 (Z aixs max travel:mm) ; Z-axis maximum travel, millimeters

 

I changed the settings above for $13 as it is now stuck at 1

 

In the underlying settings $("#val-13-input").val() is now '1' (what I refer to as Enabled). Maybe because I patched the code in the JS console I am seeing this? Even though my change appeared to fix it, it was behaving oddly afterwards. Unfortunately, it did not solve my issue where the movement controls don't do anything. It appears that nothing happens on a click. I'll dig in more before posting a new thread. Thanks again for the help.

 

Unfortunately, it is set to 1. Thank you.

$$
...
[11:05:25] [ $$ ] $4=1 (stepenable invert,bool) ;Invert step enable pin, boolean

 

Thanks. Good catch. I don't believe I changed it. It's odd that the screenshot captured 0 for $4. I'll be watchful. I can do all of the motion positions manually through the GCODE command line on CONTROL. I just don't think the click() event is hooked up to the buttons, but I am still investigating.

 

Back to the NaN issue... This is where I started, but I could not recall where I did see it. I realized it was trying to send a Feed command with NaN. So the click event IS enabled and working , it just that the websocket is getting garbage.

This is the content of the packet var in socket.js, line 268.

 

Nope. This is pretty much a plain vanilla setup. I'm still trying to figure out why a feed rate of NaN is emitted to the websocket. I believe that is the problem.

 

It appears I have a value in localstorage that is causing the jogRate override to occur. Unfortunately, the $110 is not a valid number and sets the jogRate to NaN. The easy fix is to remove localstorage.

If jogOverride is called, then the grblParams must be parsed prior to using them.

The UI now updates when pressing a button, but the head is not moving. I do have control over the spindle through the UI, though.

I added the parseInt (like in grbl-settings.js) to the jogOverride function in jog.js. I believe this is a bug.

function jogOverride(newVal) {
if (grblParams.hasOwnProperty('$110')) {
jogRateX = (parseInt(grblParams['$110']) * (newVal / 100)).toFixed(0);
jogRateY = (parseInt(grblParams['$111']) * (newVal / 100)).toFixed(0);
jogRateZ = (parseInt(grblParams['$112']) * (newVal / 100)).toFixed(0);

$('#jro').data('slider').val(newVal)
}
if (grblParams.hasOwnProperty('$113')) {
jogRateA = (parseInt(grblParams['$113']) * (newVal / 100)).toFixed(0);
}
localStorage.setItem('jogOverride', newVal);
}

 

I completely agree. It seems odd to me that this is happening, too; these are the last things I would expect. I love the software. It's really great.

The value coming back from grblSettings[$key] is a string (most often, I have not seen otherwise), and it usually has the numeric value followed by a space and a short description. That won't work in the jogOverride function as it is set on my setup. Whenever I touch the jog slider, that routine get called and the jogRate values get set to NaN.

 

I am doing this investigation in the DevTools window. socket.js lives under build/esm/socket.js. That is where I first noticed this issue. But tracing it back on the stack I noticed it originated in the jogOverride routine.

 

That is an issue on my machine where the head is not moving. I think adding the parseInt would resolve this.

[edit] grrrr. I had $4 set to 1 - that is why it wasn't moving. I set it back to 0, and with the parseInt() fix it is working (at least temporarily).

 

I am using a Genmitsu 4040 Pro and using OpenBuilds CONTROL to send the gcode. I was just trying to help out with the open source tool. BTW, the last comment should have been parseFloat, not parseInt. I submitted a PR with these two issues. Thanks again for the help.

 

Thank you, Peter. I do not require help with configuration. I honestly believe the PR's I submitted are subtle bugs. I have run the GitHub code on my computer with those fixes and it works for me. I absolutely agree that it could be unique to my setup as this is very basic functionality, however, it is very clear to me as an engineer that those two fixes were not incorrect.

I have been consistently able to reproduce this. I clean my application local settings within the Electron app, restart CONTROL, I get prompted to register, I connect to my CNC and I can position the head using the buttons. I can see the X/Y/Z coordinates change as expected as I use the buttons. I then move the jog dial to some other value (doesn't matter what it is). Then I try to press the X/Y/Z positioning buttons ($('xP') in the JS) and the CNC does not respond. When I repeat the same process with my changes, the final position step in the aboce scenario works.

At this point I have a working solution (I am unable to use the positioning keys in CONTROL) to my issue. None of this was about configuration - just why CONTROL was not responding as expected. I tried to contribute to an Open Source project, that was all.