[OldSalt1945]

I got the following errors on a 238,000 line job. It threw off the registration, causing the router to cut off from where it was supposed to.

I don't know enough, yet, to do anything about it.

Perhaps someone can help me to understand/correct it.

I didn't have this problem with 0.9i, just with 0.9j. I will probably just switch back to 0.9i, but "enquiring minds want to know".

**** Connected to COM5 @ 115200 baud ****


Grbl 0.9j ['$' for help]
>>> G20 G91 G0 Y-1
ok




>>> G0X0.000Y0.000S15000M3
>>> G0X153.797Y2.952Z1.000
ok
error: Unsupported command
>>> G1Z-1.687F720.0
>>> G1X153.808Y2.952Z-1.687F2520.0
ok




>>> G0X153.797Y2.952Z1.000
ok
>>> G1Z-1.687F720.0
>>> G1X153.808Y2.952Z-1.687F2520.0
error: Unsupported command
ok
ok
ok
>>> X155.681Y3.011Z-1.687




>>> G0X153.797Y2.952Z1.000
>>> G1Z-1.687F720.0
ok
error: Unsupported command
ok
ok
>>> G1X153.808Y2.952Z-1.687F2520.0
ok

Thanks, John

[wizard]

I can't help but I'm certain the GRBL people will want to know about this. I might suggest though that with error codes it pays to look at the code before and after the failure just to make sure nothing odd is seen. In any event I'd the G-Code runs in an older version of the software that does kinda indicate an interpreter error.

The next question becomes is this repeatable? Because if you can get it to repeat I'm certain the GRBL people will want to see your G-Code. If it can't be repeated then you can't rule out hardware issues which makes for more debugging.

[OldSalt1945]

I might suggest though that with error codes it pays to look at the code before and after the failure just to make sure nothing odd is seen. In any event I'd the G-Code runs in an older version of the software that does kinda indicate an interpreter error.

That's why I include a line or 2 both before and after the error line.

The next question becomes is this repeatable? Because if you can get it to repeat I'm certain the GRBL people will want to see your G-Code. If it can't be repeated then you can't rule out hardware issues which makes for more debugging.

Yes. I reset back to zero and ran the job 2 more times. It cut precisely in it's own footprints.

The problem arises when GRBL sees a problem with a line of code, it discards the line. If that code said move x+1 y+2, then the machine doesn't move, but the G-Code Compiler assumes it did. Now the actual machine location is 1 less in x and 2 less in y than it should be. Unfortunately, I don't know enough g-code to be able to tell what it doesn't like. Out of 238,000 lines, there were 3 it didn't like.

John

[wizard]

I'm not seeing anything obviously wrong with the G-Code that you posted. That doesn't mean much though. About these failures though, you say there are three places the code fails. Do these repeat over runs or are they random?

In any event I have to wonder if you have a communications issue, possibly a buffer over run on the Arduino or a corrupted transmission. I might start by using a slower baud rate or if your comms program supports it adding intercharacter delays or line delays.

In any event I would bring this up with the GRBL people. Most of my commenting is based on experience with other communications issues on other machines. Also everything needs to be documented right down to the last update done on your PC. There are all sorts of possibilities here.

[ger21]

Yes, the info you posted does not clearly show which line the error is occurring on. Some show an error before a line of code, and some show an error after a line of code?
Maybe someone familiar with grbl will know more??

[OldSalt1945]

The error was repeatable. Before starting the job, I lowered the bit into the work piece to mark zero. After the failure, I returned the router head to zero with Universal Gcode Sender and it was off. I manually set the bit to the zero mark, zeroed UGS and ran the job again, twice. Each time the router bit retraced it's steps exactly.

It is almost as if some Gcode lines had been removed or discarded. I am assuming that the unsupported were discarded.

Just to make sure, I will regenerate the Gcode file and try again. Since my free trial with ArtCam has expired, I will have to have a friend subscribe to do that. When I buy, it will be Vcarve Desktop, but this particular piece is really impressive.

I will let you know how that turns out.

John

[109jb]

GRBL will absolutely continue to run after an error and simply ignore the lines that contain the errors. It is the job of the interface program to do something when encountering an error..

GRBL reports an 'ok' or error report for each line received, so it again is the GUI interface to track the lines to see where the erroneous line is located.

There is another possibility regarding experiencing errors when running on GRBL. I identified a problem with the USB to serial chips used on some cloned Arduino boards. The genuine Arduino UNO boards use a Atmel 16U2 USB-serial chip, whereas some clone boards use a CH340G chip. Both chips can experience occasional errors where the line sent from the computer is corrupted by the USB-serial chip before getting to GRBL. The CH340G it happens much more frequently and there is no fix at this time. It usually takes the form of missing data. for a fictitious example:

>>> G1Z-1.687F720.0
>>> G1X153.808Y2.952Z-1.687F2520.0

could come through as

>>> G1Z-1.687FY2.952Z-1.687F2520.0

where a portion of both lines, including the line feed character are dropped. This can result in GRBL seeing the last line above and throwing an erroe because it doesn't know what to do with it.

The only way to know if this is what is happening is to turn on echoing in GRBL and see if the echoed lines match what the GUI sent.

My recommendation is that if you have a clone Arduino with a CH340G, that you not use it for GRBL. If you have a clone or genuine Arduino with a 16U2 chip then there is a fix for the firmware in this chip. You can read more about the problem, and the firmware fix at the following link:

https://github.com/grbl/grbl/issues/845

https://github.com/grbl/grbl/wiki/Known-Bugs

[109jb]

You are also likely to get better answers relating to GRBL from the GRBL Github repository here:

https://github.com/grbl/grbl/issues

[OldSalt1945]

Thank you for the information.

I'm headed there now.

John

[OldSalt1945]

Thanks to 109jb, I found out about a communication problem that happens on the Atmel MEGA16U2 chip on Arduino computers.

Well, I've been all over the internet looking for answers and have been down many, many rabbit holes.

I am still having problems, so I have come back to the land of knowledgeable people.

I found that the Atmel MEGA16U2 has had a firmware problem for several years now that causes random characters to be dropped, corrupting the gcode being sent to the Arduino-GRBL controller.

I found several articles on how to determine if the particular Arduino has the updated firmware. None were of sufficient detail to allow me to definitively determine which mine is.

Under Device Manager I found :

Driver Management concluded the process to install driver arduino.inf_amd64_6cb1adf1bc8e1d48\arduino.inf for Device Instance ID USB\VID_2341&PID_0043\95333303031351306041 with the following status: 0x0.

Revision 0001 is the good one. I see no mention of Revision. Of course, I have Win 8.1 so who knows?

When I run Atmel Flip, I chose 16U2, then selected "Select a communication medium" and selected USB. It responded "AtLibUsbDfu.dll not found". I went to C:Program Files(x86)\Atmel\Flip 2.3.7\bin where Flip resides and found AtLibUsbDfu.dll smiling back at me.

I'm confused. I found several articles about AtLibUsbDfu.dll not found. They all basically said "install it". How? Where?

Since I found references to this problem back to 2012, why haven't the folks at Atmel or Arduino fixed it? What the hell good is a controller that "mostly" works? Did these folks ever hear of checksum handshaking protocols with rebroadcast of bad packets? Communication protocols have had this since I was a teenager and I'm 71 now.

I'm just glad that I'm running a machine that doesn't break things when it goes haywire. If it were a 10hp mill, these little hiccups could be a real problem.

Please, please, someone help me out of this mess.

John

[wizard]

Thanks to 109jb, I found out about a communication problem that happens on the Atmel MEGA16U2 chip on Arduino computers.

Well, I've been all over the internet looking for answers and have been down many, many rabbit holes.

I am still having problems, so I have come back to the land of knowledgeable people.

I found that the Atmel MEGA16U2 has had a firmware problem for several years now that causes random characters to be dropped, corrupting the gcode being sent to the Arduino-GRBL controller.

I found several articles on how to determine if the particular Arduino has the updated firmware. None were of sufficient detail to allow me to definitively determine which mine is.

Have you seen this page: ATmega16U2 and a rather old page on the Arduino forums: https://blog.arduino.cc/2011/02/15/f...rial-problems/

Under Device Manager I found :

Driver Management concluded the process to install driver arduino.inf_amd64_6cb1adf1bc8e1d48\arduino.inf for Device Instance ID USB\VID_2341&PID_0043\95333303031351306041 with the following status: 0x0.

Revision 0001 is the good one. I see no mention of Revision. Of course, I have Win 8.1 so who knows?

When I run Atmel Flip, I chose 16U2, then selected "Select a communication medium" and selected USB. It responded "AtLibUsbDfu.dll not found". I went to C:Program Files(x86)\Atmel\Flip 2.3.7\bin where Flip resides and found AtLibUsbDfu.dll smiling back at me.

I'm confused. I found several articles about AtLibUsbDfu.dll not found. They all basically said "install it". How? Where?

I haven't touched a Windows machine in years for personal projects so I have no idea.

Since I found references to this problem back to 2012, why haven't the folks at Atmel or Arduino fixed it? What the hell good is a controller that "mostly" works? Did these folks ever hear of checksum handshaking protocols with rebroadcast of bad packets? Communication protocols have had this since I was a teenager and I'm 71 now.

Well in an ideal world something like that would be implemented but honestly I don't think GRBL leaves enough room on the chip to implement any such technology. The first versions of GRBL basically used all available space in flash storage. This is one reason why I see ARM based controllers taking over the low end G-CODE processor business.

I'm just glad that I'm running a machine that doesn't break things when it goes haywire. If it were a 10hp mill, these little hiccups could be a real problem.

Please, please, someone help me out of this mess.

John

As has been mentioned you really need to bring this up on the GRBL boards. They know the software inside out and should be aware of this issue.

[johnohara]

OldSalt1945~

You mentioned in your first post:

I didn't have this problem with 0.9i, just with 0.9j. I will probably just switch back to 0.9i

Before chasing down hardware related issues that may or may not be causing your problem, I suggest reloading
version 0.9i. If the problem disappears there is a high probability version 0.9j is the culprit. Same hardware,
same g-code file, same machine, works with 0.9i not with 0.9j would imply software.

A spare Arduino 328p would help to see if the problem displays the same symptoms on a different hardware platform.

In other words, "does your problem move with the hardware or the software?" If it's software, I'm fairly sure
Sonny Jeon (current lead developer) would want to know.

It may also imply that version 0.9j is not compliant with the firmware version of your Arduino. This is listed
as a known bug as per the link "109jb" gave above.

~john

[109jb]

You guys are right that the problem may or may not be related to the usb to serial chip problem, but let me characterize the usb chip problem this way.

I would not run my machine without using an 16u2 equipped Arduino with the updated firmware, and I would not run my machine on an Arduino clone that uses the ch340 usb chip. In my opinion, the problem with the chips is there and it is not a matter of "if" the usb chips will result in an error, but rather a matter of when the errors will occur.

[109jb]

Oh. By the way, it is not a problem with "Arduino" firmware, (i.e. The 328p), but a problem with the usb to serial chips that interface with the 328p and serve as the communication channel from the computer to the 328p

[OldSalt1945]

I would not run my machine without using an 16u2 equipped Arduino with the updated firmware, and I would not run my machine on an Arduino clone that uses the ch340 usb chip. In my opinion, the problem with the chips is there and it is not a matter of "if" the usb chips will result in an error, but rather a matter of when the errors will occur.

I wholeheartedly agree. Now if only I could. I have been fighting the good fight and losing for a week now.

Here is what I have done and where I am stuck.

I am using an HP Pavilion laptop running Win 8.1 because that is what I have.

I went to ATmega16U2
and downloaded FLIP 3.4.7. There are 2 versions. I tried both.

When I run FLIP, I clicked "Select a target device" and chose Atmega 16U2.
Then I clicked "Select a communication medium" and chose USB and got an error message "AtLibUsbDfu.dll not found".
I went to C:\\Program Files (x86)\Atmel\Flip 3.4.7\bin and found "AtLibUsbDfu.dll" to be there in the same directory with the Flip application file that I executed from a desktop shortcut.

This happens whether or not I have the Arduino connected at the time.

I searched the net and found several suggestions that involved running mgrsvc or some such. I don't have the knowledge or confidence in an anonymous "someone" to take that step and possibly make things worse or wipe the system.

I tried the Reset 8U2 as shown in https://www.arduino.cc/en/Hacking/DFUProgramming8U2. It caused the Device Manager to drop the Arduino UNO from the Ports and put it under "Other Devices" and list it as "Unknown Device". Unlike what the directions said. I tried FLIP again with the same results of "AtLibUsbDfu.dll not found".

Hence, I am stuck.

If there is someone out there that knows what I should do to get around this problem and has the patience to deal with someone who knows just enough to be dangerous, I would be eternally grateful (for, perhaps, a week, maybe two). Directions like "Install the driver" won't work. I need to know how, please. I realize this is asking a lot, but ..........

John

[OldSalt1945]

My problem is solved.

wega52 responded on my query under github grbl issues.

Open Device Manager
Look for "unknown device"
if there is no unknown device plug in the UNO Board and reset the 16U2 not the UNO
the device should show up
right click the entry and select "update driver"
select "search for driver on computer"
navigate to "C:\Program Files (x86)\Atmel\Flip 3.4.7\usb" or where you installed FLIp
confirm the directory
the computer will find the correct driver and install it
Done
The problem with the dLL will be solved too

Werner

My thanks to Mr. Werner.

John