I’m getting some gcode errors when using CNCJS 1.91, 1.94 and 1.97, could be others, as I only tested those versions.
1.8.17 does NOT have any errors as well as when I use Carbide Motion 4.
Using a Shapeoko 3 with GRBL 1.1f.
The exact line with the error changes with different versions and runs, but this is one log:
T1
G17
G20
G0Z0.3000
G0X0.0000Y0.0000
G0X7.8375Y-5.5128Z0.1000
G1Z-0.0200F25.0
G1X-7.8375F50.0
G1Y-5.3253
G1X7.8375
G1Y-5.1378
G1X-7.8375
G1Y-4.9503
G1X7.8375
G1Y-4.7628
G1X-7.8375
G1Y-4.5753
G1X7.8375
G1Y-4.3878
G1X-7.8375
G1Y-4.2003
G1X7.8375
G1Y-4.0128
G1X-7.8375
G1Y-3.8253
G1X7.8375
G1Y-3.6378
G1X-7.8375
G1Y-3.4503
G1X7.8375
G1Y-3.2628
G1X-7.8375
G1Y-3.0753
G1X7.8375
G1Y-2.8878
G1X-7.8375
G1Y-2.7003 error:3 (Invalid statement)
G1X7.8375
G1Y-2.5128 error:3 (Invalid statement)
G1X-7.8375 error:24 (Invalid gcode ID:24)
G1Y-2.3253
G1X7.8375 error:3 (Invalid statement)
G1Y-2.1378
G1X-7.8375 error:3 (Invalid statement)
G1Y-1.9503
G1X7.8375
G1Y-1.7628
G1X-7.8375
G1Y-1.5753
G1X7.8375
G1Y-1.3878
G1X-7.8375
G1Y-1.2003
G1X7.8375
G1Y-1.0128
G1X-7.8375
G1Y-0.8253
G1X7.8375
G1Y-0.6378
G1X-7.8375
G1Y-0.4503
G1X7.8375
G1Y-0.2628
G1X-7.8375 error:3 (Invalid statement)
G1Y-0.0753
G1X7.8375
G1Y0.1122 error:3 (Invalid statement)
G1X-7.8375
G1Y0.2997 error:3 (Invalid statement)
G1X7.8375
G1Y0.4872
Followed by another ~70 lines that were fine.
评论 (7)
#2 – cheton 于 2017-08-15
It seems that CNCjs 1.8.17 is much more stable than 1.9.x. The Receive Buffer reported by Grbl constantly stayed at 17~19 bytes when running the job.
However, after I turn back to CNCjs 1.9.7, I found that each time when triggering a parser state query (i.e. $G) once timedout, it will deduct Grbl’s receive buffer size with 3 bytes (e.g. Bf:0,17 -> Bf:0,14), as shown below:
!image
Once the Receive Buffer is approximately equal to 0, it will cause unpredictable errors to Grbl, like below:
!image
I should already know the root cause to this issue. I will take a look into it and fix it soon.
Thank you for sharing your findings.
#3 – cheton 于 2017-08-15
Related to https://github.com/cncjs/cncjs/issues/176
#4 – nsfilho 于 2017-08-22
@cheton I belive it’s solved this problem on my branch. Tomorrow I’ll create a pull request and commit for your review. Basically I suffering the same problem on many of my gcodes, because some of than are “long” perimeters with low feedrate….
Basically its about the chunk size of command buffers in grbl (after analyzing gnea/grbl) — I made 2 (two small changes):
a) number of bits to protect against overflow from 8 to 16 bytes — because this is the size of the chunk for planner and the Serial buffers are collect using this specifically size.
b) the repeat time — a little more long, because grbl respond with free memory when it is available ….. from 5 secs to 30 secs.
No other operation will be affected by this changes. All is running smoothly and the errors from gcode stopped.
Again thank you by this software and tomorrow I’ll try to contribute with you with this really small piece of code. ![]()
#5 – cheton 于 2017-08-22
It is not necessary to force re-send parser state ($G) when running a G-code program, the purpose of the query timer is to make sure Grbl will respond periodical “?” and “$G” commands during bootstraping, for some rare cases (e.g. re-connecting the USB cable, etc.) it may need to send $G again to Grbl after bootloader is ready.
The 8 bytes deduction is relevant to Grbl’s receive buffer size (defaults to 128 bytes), especially when using the character-counting streaming protocol, I decrease the size on the sender side to make sure it won’t overflow Grbl’s receive buffer.
The CNCjs server will periodically send $G\n and ? commands to Grbl, so it should deduct the buffer size at least 4 bytes, including the newline character:
* length(‘$G\n’) = 3
* length(‘?’) = 1
To reserve more space to prevent race conditions from being occurred if any, I double the size to 8 bytes, so the sender side will assume it has 120 bytes (i.e. 128 – 8) available to use.
This issue was already fixed in this commit https://github.com/cncjs/cncjs/commit/0148f35fefabdcedf18cc29b82f5746d8b2e5794#diff-4ecb4a936d43625e056e3cca7620e47eR484
It will publish 1.9.8 with the bug fixes this week.
#6 – cheton 于 2017-08-22
I’m not sure whether the realtime command ‘?’ will occupy Grbl’s receive buffer. If it won’t occupy the receive buffer, I can take it off from the calculation.
#7 – cheton 于 2017-08-25
Release Notes of CNCjs 1.9.8
https://github.com/cncjs/cncjs/releases/tag/v1.9.8
#1 – cheton 于 2017-08-14
I ran into similar issue using your G-code program. I saw several random errors around line 4x to 5x, however, if I replace the line
G1X-7.8375F50.0withG1X-7.8375F1000.0for a faster feed rate, then it won’t happen again. I will try 1.8.17 by tomorrow.My screenshot that reproduced this issue:
!image
“
“T1
G17
G20
G0Z0.3000
G0X0.0000Y0.0000
G0X7.8375Y-5.5128Z0.1000
G1Z-0.0200F25.0
G1X-7.8375F50.0
G1Y-5.3253
G1X7.8375
G1Y-5.1378
G1X-7.8375
G1Y-4.9503
G1X7.8375
G1Y-4.7628
G1X-7.8375
G1Y-4.5753
G1X7.8375
G1Y-4.3878
G1X-7.8375
G1Y-4.2003
G1X7.8375
G1Y-4.0128
G1X-7.8375
G1Y-3.8253
G1X7.8375
G1Y-3.6378
G1X-7.8375
G1Y-3.4503
G1X7.8375
G1Y-3.2628
G1X-7.8375
G1Y-3.0753
G1X7.8375
G1Y-2.8878
G1X-7.8375
G1Y-2.7003
G1X7.8375
G1Y-2.5128
G1X-7.8375
G1Y-2.3253
G1X7.8375
G1Y-2.1378
G1X-7.8375
G1Y-1.9503
G1X7.8375
G1Y-1.7628
G1X-7.8375
G1Y-1.5753
G1X7.8375
G1Y-1.3878
G1X-7.8375
G1Y-1.2003
G1X7.8375
G1Y-1.0128
G1X-7.8375
G1Y-0.8253
G1X7.8375
G1Y-0.6378
G1X-7.8375
G1Y-0.4503
G1X7.8375
G1Y-0.2628
G1X-7.8375
G1Y-0.0753
G1X7.8375
G1Y0.1122
G1X-7.8375
G1Y0.2997
G1X7.8375
G1Y0.4872