Invalid gcode ID:33: Motion command target is invalid

Discussion about the arduino based g-code interpreter, grbl
Post Reply
klaus-de
Posts: 3
Joined: Tue Jul 25, 2017 7:13 pm

Invalid gcode ID:33: Motion command target is invalid

Post by klaus-de » Tue Jul 25, 2017 7:23 pm

Hi there!

I am using Grbl 1.1f & UGS 2.0.

When I send the following command:

G2 X 2.525 Y 4.034 I 0.640 J 0.640 F15

I get: error: Invalid gcode ID:33: Motion command target is invalid.

Visualize function & simulation with CAMotics works fine!

Additionally: The given gcode command is one of a gcode file with 2.000 lines generated using 'DXF2GCODE 2017-05-03'.

Not a single command of these G2 commands is working using grbl.

I tried to increase the decimal places as far as 10 digits but it is not working either.

I also checked the grbl '$12 (Arc tolerance, millimeters)' firmware-settings value which is 0.002 (default). Even increasing this value to 1.002 does not change anything.

How can I fix the problem?

- klaus -

Dan_the_Chemist
Posts: 76
Joined: Thu Nov 10, 2016 2:52 am

Re: Invalid gcode ID:33: Motion command target is invalid

Post by Dan_the_Chemist » Tue Jul 25, 2017 9:48 pm

I recently ran a very large job that took quite a long time. I received the same error code and googled up "invalid gcode id:33 shapeoko" and found a number of very interesting results. Some people blame it on insufficient precision, other people have blamed it on Fusion 360, yet another notes that the same problem comes from VCarve, and others have had success changing Gcode senders.

I use bCNC, and so I tried using the editor to uncheck the intermediate blocks between the initialization (block 1 and block 2) and the block where the error occured. It worked - the machine went right past that point and finished the first pass. I had a similar problem on my second pass with a different tool, and the same solution fixed it. The third pass - a very fine skim cut with a brand new bit finished without problems.

WillAdams commented back in Dec of 2016 - "It's a weird problem, and I think we're going to all have to collaborate to get it fixed." http://community.carbide3d.com/t/carbid ... 360/3627/7

Fortunately, while it is a bit annoying it's not a deal breaker for me. Simple fix.

klaus-de
Posts: 3
Joined: Tue Jul 25, 2017 7:13 pm

Re: Invalid gcode ID:33: Motion command target is invalid

Post by klaus-de » Wed Jul 26, 2017 7:53 am

Thanks for your reply, Dan.

In my case: The error occurs even if i reset grbl/ugs and send only the command:

G2 X 2.525 Y 4.034 I 0.640 J 0.640 F15

grbl will not move and return the error 33. That happens to all of these

G2 X Y I J commands. Maybe they are wrong calculated ..

Is someone able to verify the given G2 command mathematically?

chamnit
Posts: 376
Joined: Tue Aug 12, 2014 2:16 pm
Location: Albuquerque NM, USA
Contact:

Re: Invalid gcode ID:33: Motion command target is invalid

Post by chamnit » Wed Jul 26, 2017 4:33 pm

Dan. FWIW, myself and others just looked into the Fusion360 problem with G2 and G3 arcs. It turned out that this is indeed a bug in the Fusion360 source and/or post processing file a lot of people use. Namely the Strooom version of the Grbl post that increases the precision of the arc values. It turns out that Fusion360's default grbl post doesn't produce G2 or G3 errors in the testing done so far on problematic CAM programs that had errors. This may have been a recent development with Fusion360 ongoing updates, because the Strooom post was written to solve arc problems. It seems things have changed. In addition, we also narrowed problems down to G18 and G19 arc planes, but not the typical G17 (XY) arc plane. Again another Fusion360 problem. When you actually look at the arc command, they are way off. The radius and the targets are not even close to lining up.

While I can install something into Grbl to check for weird inconsistencies like this, it will only be a patch and mask an ongoing problem. It won't solve it. The actual problem is that the g-code standard defines arcs in one of the worst possible ways in a mathematical sense. It's impossible to define it accurately and promotes poor implementations by CAM program and firmwares alike.

@klaus-de : Grbl will report an error for your `G2 X 2.525 Y 4.034 I 0.640 J 0.640 F15` command, if your starting position is not on the arc within a certain range that is depending on radius and a fixed error bound (See LinuxCNC for the error description). You'll need to tell us where you are located before you issue the arc command.

$12 arc tolerance has nothing to do with the error and only determines the resolution the arc is traced after the gcode has been error-checked.

Dan_the_Chemist
Posts: 76
Joined: Thu Nov 10, 2016 2:52 am

Re: Invalid gcode ID:33: Motion command target is invalid

Post by Dan_the_Chemist » Thu Jul 27, 2017 11:06 pm

chamnit wrote:Dan. FWIW, myself and others just looked into the Fusion360 problem with G2 and G3 arcs. It turned out that this is indeed a bug in the Fusion360 source and/or post processing file a lot of people use.
Okay... I'm always willing to believe that there is a bug in a huge software package. However, now I don't understand why my trick of commenting out the blocks of Gcode between the initialization blocks and the error containing block would work...

To give a little more information, it seems that I have experienced two types of ID:33 bug. A while ago I got a ID:33 while the carbide3d controller was trying to perform a G3 arc, and nothing short of editing the specific G3 command would fix the problem. That is commensurate with the sort of bug you describe. However, the one I experienced last weekend doesn't depend on the specific line - it is context sensitive. If I modify the context prior to the line that gives the ID:33 error, the line is successfully processed. We are talking big Gcode files... 90,000 lines and the problem doesn't occur until 1/4 or more the way through. Maybe it's a problem with the Gcode sender - bCNC ??? SOOOOooooo many variables in this process - it's a miracle it works so well. :)

Can you recommend a freeware/shareware Gcode checker that will catch one or both of these bugs?

WillAdams
Posts: 8489
Joined: Mon Apr 09, 2012 6:11 pm
Location: Pennsylvania --- south of the Turnpike, East of US-15
Contact:

Re: Invalid gcode ID:33: Motion command target is invalid

Post by WillAdams » Fri Jul 28, 2017 2:39 pm

My understanding is there's some Grbl / G-code simulation mode (in bCNC?) which allows one to submit a file and have Grbl run all the way through it.

If not, try GrblGru?
Shapeoko 3XL #0006 w/Makita RT0701 Router w/0.125″ and ¼″ Elaire precision collets
Nomad 883 Pro #596 (bamboo)

chamnit
Posts: 376
Joined: Tue Aug 12, 2014 2:16 pm
Location: Albuquerque NM, USA
Contact:

Re: Invalid gcode ID:33: Motion command target is invalid

Post by chamnit » Fri Jul 28, 2017 6:43 pm

You can check for gcode errors directly with Grbl by enabling its check-mode via a $C command. Another $C command will disable it and soft-reset Grbl. Or just soft-reset to get back to normal operation. This is the most robust way to check, because it is using Grbl's g-code parser and error-checking that it uses during a job. It's identical, except it doesn't move anything, and runs as fast it can stream. (For 90,000 lines, it might take a minute).

I think there also might be an issue with CarbideMotion as well. There is some evidence that CarbideMotion pre-processes the g-code program prior to streaming it to Grbl. Meaning that it doesn't stream the program exactly as it was written. Often if you switch to mm units from inches, this fixes most of the arc errors.

Again this is really all caused by the way arcs are described by the g-code standard. There are lots of potential for errors to occurs from the CAM side and controller side. Even the precision of the floating point values used and how they are handled within each calculation can make a difference. This problem with arcs failing has been around for decades. It's not new. Seasoned machinists will often avoid arcs altogether, unless they know that their toolchain from CAM to tool is compatible. This is the reason why disabling arcs, altering their output to a quadrant, or restricting to certain sizes is available in CAM programs.

Dan_the_Chemist
Posts: 76
Joined: Thu Nov 10, 2016 2:52 am

Re: Invalid gcode ID:33: Motion command target is invalid

Post by Dan_the_Chemist » Fri Jul 28, 2017 7:09 pm

chamnit wrote:You can check for gcode errors directly with Grbl by enabling its check-mode via a $C command. Another $C command will disable it and soft-reset Grbl. Or just soft-reset to get back to normal operation. This is the most robust way to check, because it is using Grbl's g-code parser and error-checking that it uses during a job. It's identical, except it doesn't move anything, and runs as fast it can stream. (For 90,000 lines, it might take a minute).
NICE tip !!!

THANKS :)

klaus-de
Posts: 3
Joined: Tue Jul 25, 2017 7:13 pm

Re: Invalid gcode ID:33: Motion command target is invalid

Post by klaus-de » Fri Jul 28, 2017 7:55 pm

Now it works fine!
chamnit: if your starting position is not on the arc within a certain range that is depending on radius and a fixed error bound
I learned that it is not possible to run this command stand-alone because it can only run at a valid staring position.
chamnit: You can check for gcode errors directly with Grbl by enabling its check-mode via a $C command.
With this knowledge I was able to do my trial & error checking from my first post again.

Thats the solution: You have to set DXF2GCODE: Options > Postprocessor configuration > Output formatting:

Image

-> Number of digits before the decimal separator: 5 (default: 4)
-> Number of digits after the decimal separator: 4 (default: 3)

Thanks again for Your help!

- klaus -

Post Reply