Problems using CNC.js

Mostly Printed CNC - MPCNC Troubleshooting
1

So I decided to go a little bit further in my current build and use a Raspberry Pi 4 with the V1Pi image on it. However, when connecting CNC.js to the machine, I noticed some strange behaviors:

1st. After connecting the Console Widget showed only the messages in the video below. I don’t know if everything is right but it is definitely different from what appeared with the first version of the firmware I installed on MPCNC. (previously 414D, and now 509D)

2nd. Not being able to move the machine through the axis widget, not even homing. Moving it was only possible after homing through the LCD or when giving G28 XY through the Console Widget.

3rd. In the Axes Widget, the machine position and work position columns values ​​were not updated.

After getting these problems I decided to downgrade the firmware version to the 414D and the above items were resolved, however, I did not want to use the machine with an “outdated” version of the firmware.

2

I think this is a bug in CNCjs with Marlin.

There was an issue closed in the latest release related to jogging not with Marlin, but in my experience there is still some sort of issue, or maybe a new one. But jeffeb’s workaround from this issue still works

github dot com/cncjs/cncjs/issues/406 - sorry I can’t post links yet

tldr; send a plain G0 in the console manually and commands should work from there on out once you get an “ok” response

Personally I just switched to GRBL and have been very happy. But CNCjs has not had a commit in 4 months, which is a huge bummer.

3

Hi, @ejt4x.

Thanks for the reply. I have several tabs open at the moment researching this subject. I saw that CNC.JS is basically geared towards grbl and that this firmware has some very interesting features. Currently, I’m using a MKS GEN L board that is basically a RAMPS with a few more pins. I saw that both @johnboiles and @enducross forked the grbl-Mega-5x to work with MPCNC using RAMPS 1.4 and dual-endstops. Wich version of grbl are you using?

4

It is. I have been supporting the project and I really think it is a good project. But I have tried to edit it and I just have not spent enough time to understand it enough to help out. So I send them some dollars each month. I think the main dev. has a full time job.

5

I’m using the @johnboiles grbl-Mega-5X/mpcnc-rambo-support with dual endstops on a Rambo 1.4 board. It “just worked” for me.

Definitely recommend testing a “G0” in the console to see if that gets you an “ok” response, and starts recognizing commands afterwards. It’s a bit annoying to have to do that every time you connect, but it did the trick. There might be a way to automate it.

6

Yeah I have only dipped my toe into the code for the tinyweb/shopfloor GUIs to do a bit of customization and it was a bit of an exercise in frustration. JS is not really in my wheelhouse, unfortunately.

7

Knowing that I wasn’t the only one with this issue inspired me to track it down. I flashed back to Marlin and did some debugging. It’s a bug with the way cncjs parses for the ‘start’ message (for me at least).

There’s a pull request up here: https://github.com/cncjs/cncjs/pull/683

To fix locally, edit /usr/lib/node_modules/cncjs/dist/cncjs/server/index.js (your location might vary depending on your platform and install)

Look for MarlinLineParserResultStart. For me it was line 10065. Edit the regex match to the following:

const r = line.match(/^(?:echo:)?start$/);

You should get a whole lot more output when you connect, and things should work.

2 Likes
8

I think that line is always the culprit and it has changed multiple times. Hopefully you nailed it for a while.

The tough thing is that gcode is relatively standardized (but not completely) but what has zero standardization is the talk back from the firmware. There isn’t any consistency that I’ve seen, which would be very frustrating if you were trying to maintain something like CNCjs. Add to that 99% of Marlin installs have EXTRUDERS=1, and we all have EXTRUDERS=0. It gets hairy, for sure. But it also seems like a solvable problem. The trick is just making sure you didn’t break it for somebody else.

9

You’re right, I missed a question mark in that initial regex I posted which would break it for others. Updated my post and PR.

10

@maaf747 I see now from your video that you’re getting the ‘echo:start’ message as well, so my post above should definitely help you out.

Here’s the root cause: https://github.com/MarlinFirmware/Marlin/issues/20305. Looks like it should be fixed in the next Marlin 2.0.x release.

1 Like
11

@minor_lazer Thanks for the reply, but my knowledge of Linux / Raspberry is still not that advanced. I couldn’t quite understand what you said. I imagine that the index.JS file is from the CNC.JS installation, right? As soon as I have a little more time I’ll check this out. At the moment I can’t remember the password I set for the pi user on the Raspberry and I will have to do another procedure to change the password.

But I just installed @johnboiles version of grbl-Mega-5X on my MPCNC and everything seems to work correctly. I made changes directly to defaults.h and before uploading the firmware to MKS GENL L I uploaded the sample code to clear the EEPROM. I’m using $23 = 27 for the machine to do homing at X0 Y0, which in my case is in the lower-left corner. However, I noticed something strange, the position values ​​of the machine are negative and correspond to the size of the axes that I defined with $130, $131, $132, $133 and $134, but the machine moves where it should when I give the commands of X + … and Y + …

Edit: I uncommented the #define HOMING_FORCE_SET_ORIGIN line so that when giving the homing command the machine coordinates would be at X0 and Y0, so far everything is ok. I will try to do tests with .gcode files to see if everything goes well.

12

Yeah the index.js file is part of the CNCjs install. It’s not something you’d normally edit but I’m not sure when the next cncjs will be released (hopefully with that fix baked in).

The negative machine coordinates at home X and Y are actually normal for GRBL. They have an explanation on their wiki:

13

So I’m having some trouble when running a gcode file. I’m using Fusion 360 to generate it and using the native post processor for grbl.

I home the machine, I move the tool in X and Y axes in 200m, zero the coordinates of X, Y and Z with G92 X0 Y0 Z0 and I hit play to execute the gcode, but I get an error message.

This is what appears on the CNC.js console:
client> $H
ok
feeder> G91
ok
feeder> G0 X200 Y200
feeder> G90
ok
ok
feeder> G92 X0 Y0 Z0
ok
ALARM:2 (Soft limit)
[MSG:Reset to continue]

And these are the first lines of gcode:
(1001)
(Machine)
( vendor: V1 Engineering)
( model: Burly)
( description: MPCNC)
(T1 D=6 CR=0 - ZMIN=-14.5 - flat end mill)
G90 G94
G17
G21
(When using Fusion 360 for Personal Use, the feedrate of)
(rapid moves is reduced to match the feedrate of cutting)
(moves, which can increase machining time. Unrestricted rapid)
(moves are available with a Fusion 360 Subscription.)

(2D Contour3)
T1
S17000 M3
G54
G0 X110.4 Y55.6 Z15
G1 Z5 F720
Z-3.4 F240
G18 G3 X109.8 Z-4 I-0.6 K0
G1 X109.2
G17 G3 X108.6 Y55 I0 J-0.6
G2 X6.4 Y55 I-51.1 J0 F720
X108.6 Y55 I51.1 J0

Edit: This is my $$

$0=10 (Step pulse time, microseconds)
$1=255 (Step idle delay, milliseconds)
$2=0 (Step pulse invert, mask)
$3=21 (Step direction invert, mask)
$4=0 (Invert step enable pin, boolean)
$5=1 (Invert limit pins, boolean)
$6=0 (Invert probe pin, boolean)
$10=1 (Status report options, mask)
$11=0.020 (Junction deviation, millimeters)
$12=0.002 (Arc tolerance, millimeters)
$13=0 (Report in inches, boolean)
$20=1 (Soft limits enable, boolean)
$21=0 (Hard limits enable, boolean)
$22=1 (Homing cycle enable, boolean)
$23=27 (Homing direction invert, mask)
$24=500.000 (Homing locate feed rate, mm/min)
$25=2000.000 (Homing search seek rate, mm/min)
$26=250 (Homing switch debounce delay, milliseconds)
$27=1.000 (Homing switch pull-off distance, millimeters)
$30=1000 (Maximum spindle speed, RPM)
$31=0 (Minimum spindle speed, RPM)
$32=0 (Laser-mode enable, boolean)
$100=100.000 (X-axis travel resolution, step/mm)
$101=100.000 (Y-axis travel resolution, step/mm)
$102=1600.000 (Z-axis travel resolution, step/mm)
$103=100.000
$104=100.000
$110=7200.000 (X-axis maximum rate, mm/min)
$111=7200.000 (Y-axis maximum rate, mm/min)
$112=400.000 (Z-axis maximum rate, mm/min)
$113=7200.000
$114=7200.000
$120=400.000 (X-axis acceleration, mm/sec^2)
$121=400.000 (Y-axis acceleration, mm/sec^2)
$122=200.000 (Z-axis acceleration, mm/sec^2)
$123=400.000
$124=400.000
$130=1200.000 (X-axis maximum travel, millimeters)
$131=900.000 (Y-axis maximum travel, millimeters)
$132=90.000 (Z-axis maximum travel, millimeters)
$133=1200.000
$134=900.000
ok

Edit 2: I noticed that Alarm2 is triggered when I try to give a command Z + G0 or G1 (G0 Z10) but Z- commands (G0 Z-10) work.

I don’t have any limit switches installed on the Z axis so I can’t do the complete homing sequence, instead I commented out the respective config.h line: //#define HOMING_CYCLE_3 (1<<AXIS_3) // OPTIONAL: Home Z axis

14

That’s the soft limit for Z travel triggering. Since you don’t have a Zmin limit switch, turn off the Z soft limit.

$132=0

Otherwise I think GRBL assumes machine Z0 is wherever Z is when the controller is powered on and won’t let you go any higher.

Or you can disable soft limits altogether with

$20=0
15

Quick update.

First of all, want to thank the @minor_lazer’s help and also thank @johnboiles for the great work in porting grml-Mega-5X for the MPCNC. I spent some time trying to make everything work but that was because my machine has some aspects that are out of the standard.

I printed a support for the Z-max limit switch and made the changes in config.h, so everything ended up working as it should.

1 Like
16

Edit: Never mind! I figured it out with help from my brother-in-law. In case other newbies comes across this topic, this is what I did:

the line saying
var r = line.match(/^start$/);
is the one I changed to
const r = line.match(/^(?:echo:)?start$/);

I haven’t booted up the machine yet, I’ll chime in when the kids are put to bed…

Edit 2:
It worked!! Thanks a lot for the fix. Let’s hope the error is taken care of with a new marlin version.

Original post:
Hi, thank you so much for looking into this! I just updated the MPCNC firmware to 509d, and now the coordinates are not responding in CNCjs, as described in the beginning of this thread. They are showing in the LCD. I get no response unless I type a G0 command in the terminal as well.

I’ve found the index.js, and the function described, but I don’t understand what you mean by the editing the regex match… This is the whole code for the function. Where do I change it? I’m sorry for being such a noob, I hope you are patient with me!

2 Likes
17

Glad you were able to figure it out, sorry my earlier post wasn’t very beginner friendly!

1 Like
18

Don’t be sorry, I was super happy to figure it out (with some family help)! If everything is spoon-fed, we’ll never learn anything, will we?