SOLVED - Motion command target is invalid on xPro V5 controller

[Niggle]

Hi all,

I'm getting back into using My Queen Bee CNC and have and error that repeats and would love some help. It causes the system to pause - I hit resume and it seems to not worry the project overall but it's frustrating and obviously may be causing some errors I am unaware of.

The Stack is
* CamBam to draw, generate tool paths and *.nc (file and *.nc attached)
* Universal G-Code Sender
* xPro v5 (settings attached)

A couple of things I notice in the file:
*.NC lines 7 and 8 read
"G21 ( Units - mm ) G90 ( Distance Mode - Absolute ) G40 ( Cutter Compensation Off )
G0  Z3.0"

They appear in the error file.text (aka console output) in lines 27 and 28 as below - without spaces between G0 and Z instructions, also without the "G90" and "G40" instructions
>>> G21
>>> G0Z3.0

Error occurs when *.nc line "G3 X9.01Y137.26Z-2.26I7.2J2.99" is parsed.

Error is:
[Error] An error was detected while sending 'G3X12.0Y139.07I5.4J0.0': (error:33) Motion command target is invalid. Streaming has been paused.
**** The communicator has been paused ****

**** Pausing file transfer. ****

Any idea what the issue might be - happy to learn to diagnose it myself of course.

Thanks from New Zealand

[lloydsp]

Spaces should not be required between a G0 and its targets.

But this makes no sense at all:
Error occurs when *.nc line "G3 X9.01Y137.26Z-2.26I7.2J2.99" is parsed.

Error is:
[Error] An error was detected while sending 'G3X12.0Y139.07I5.4J0.0': (error:33) Motion command target is invalid. Streaming has been paused.
**** The communicator has been paused ****

I think you're seeing the error of sending occurring WHILE the parsing of the _next_ line is occurring.  Have you explored the g-code yourself to see if that error line is actually in your code?

If so, it's possible that one of the destinations is out of range.  A Y offset (J) of zero is illegal for many machines. (It is always illegal to specify NO offset, but a zero offset may be interpreted as no offset.)

Lloyd

[Niggle]

Thanks Lloyd,

Sorry I missed that, my mistake - I expected the error to have bounced back on the last line transmitted but didn't check. I see what you mean.

Whole error log attached - it shows it parses 8 additional instructions before the error bounces back to the console, I guess that's just a comms timing thing . I coloured the associated commands and error responses in the text below for easy reading - all grabbed straight from the error log attached.

I also tried copying the G-Code causing the error then pasting it directly into the Console but the error repeated/persisted...

>>> G3X9.01Y137.26Z-2.26I7.2J2.99
>>> G1X4.8Z-3.0
>>> G1Y141.48
>>> G3X9.01Y137.26I7.2J2.99
>>> G1X4.8
>>> G0Z3.0
>>> G0Y267.02
>>> G0Z1.0
>>> G1F300.0Z0.0
[Error] An error was detected while sending 'G3X9.01Y137.26Z-2.26I7.2J2.99': (error:33) Motion command target is invalid. Streaming has been paused.
**** The communicator has been paused ****

**** Pausing file transfer. ****

ok
ok
[Error] An error was detected while sending 'G3X9.01Y137.26I7.2J2.99': (error:33) Motion command target is invalid. Streaming has been paused.
**** The communicator has been paused ****

**** Pausing file transfer. ****

Spaces should not be required between a G0 and its targets.

But this makes no sense at all:
Error occurs when *.nc line "G3 X9.01Y137.26Z-2.26I7.2J2.99" is parsed.

Error is:
[Error] An error was detected while sending 'G3X12.0Y139.07I5.4J0.0': (error:33) Motion command target is invalid. Streaming has been paused.
**** The communicator has been paused ****

I think you're seeing the error of sending occurring WHILE the parsing of the _next_ line is occurring.  Have you explored the g-code yourself to see if that error line is actually in your code?

If so, it's possible that one of the destinations is out of range.  A Y offset (J) of zero is illegal for many machines. (It is always illegal to specify NO offset, but a zero offset may be interpreted as no offset.)

Lloyd

[dave benson]

Hi Niggle
try this post processor I wrote for someone a while ago.
It has the arc center mode set and won't output any tool changes in the Gcode.
Dave

[lloydsp]

Unless I'm missing something really basic, I don't see anything invalid about that command, based upon the limits established in your setup file.  I seriously doubt that a toolchange has aything to do with it.

Perhaps it has to do with flow-control.  Is it possible that you're overrunning a buffer?  Is the controller reading this file from disk, or are you sending it serially to the controller?

Lloyd

[dave benson]

I seriously doubt that a toolchange has aything to do with it.

Didn't say it did, To explain that PP was copied from a master default test file that works with all GRBL controllers and has been tested with 5 Gcode senders including UGS.
It will work (I know what error 33 means) and can see the problem in the Gcode.
If Niggle tries it and it works (it will) the I post one with tool changes or show him to add
tool changes himself.
Dave

[lloydsp]

Well, Dave, if you know what Error 33 means, please explain it so we can all understand the problem.

The g-code looks OK, so without your explanation, I surely can't figure it out.  And I don't have one of those controllers to discern what an error 33 means.

Lloyd

[dave benson]

It's easy once you know.
there's not enough precision in the G2\3's decimal output it's 2 and should be 3.
Dave

[lloydsp]

Really?  It doesn't know how to handle truncated decimals?  REALLY?

Woof!  That's a (excuse me) DUMB flaw in the controller soft!  It should be able to handle integers without any decimal point.

I'm glad you knew that.  That's one of the most 'esoteric' bugs I've ever heard of.

Lloyd

[dave benson]

I don't want to derail the thread but.
It's to do with the math, 2 decimal places is not enough precision, meaning the endpoints of the arcs and other geometry.
are not close enough.
Dave

[Niggle]

Solved - thank you sir!

The new PP did the job all right. Thank you for taking the time to post the PP and the explanation. It makes sense once you explained how it affects the geometry but must admit it's a far cry from "error 33".

Very grateful

Curious about adding tool changes but it's not urgent for me.

Hi Niggle
try this post processor I wrote for someone a while ago.
It has the arc center mode set and won't output any tool changes in the Gcode.
Dave

[dave benson]

Glad you got it sorted out.
Here is that post same processor with the tool changes added.
Dave

[lloydsp]

Dave,
I agree that two digits don't provide enough precision.  But the language of math is universal in all tongues.  The absence of digits beyond a particular number causes an explicit presumption of trailing zeros, and any software should handle that situation.

I still count that as a bug on the part of the controller's programmer, regardless of the rationale behind it.

Lloyd

[dave benson]

Lloyd it has nothing to do with the controller not GRBL or the Gcode sender software
or the twin core 32 bit 240 mhz with floating point unit, processor.

Mach3 or linux will barf at  2 decimal places too, it's just a setting in CB's PP that governs how many digits are output in the Gcode.
Mach3 won't throw an error you just get to go on a fun ride. I just tested this.
Something to know is 3 decimal places for Niggle because he is in metric land for imperial units you would be well advised to use 4.
Dave

[Garyhlucas]

The problem isn’t that you only two digits. This problem happens on virtually all CNCs on arcs when the ends and center are too far off at two decimals. I used to get drawings from customers with 2 decimal dimensions that I couldn’t program from. I had to beg a lot of them to go 4 decimals because they thought it would add cost by specifying unneeded precision. It cost a lot more when I couldn’t finish a program !