kprims
August 2, 2017, 5:11pm
5
"@kprims , nonsense! Loopback test works on every serial communication."
@septillion , It may be nonsense to you, but after testing 6 different Uno's with the ch340g chip I come up with that same problem.
An atmega 2560 with the same chip works fine on the loopback test.
My failures were just like Post #9 .
https://forum.arduino.cc/index.php?topic=351099.0
IDE 1.8.3
I have no problems loading sketches and using the serial port.
I tried the loopback test because of the OP and was surprised to find loopback wasn't working on smd clone uno's.
I used a USB 3 port as well as a USB 2 port and three different cables.
Used a different Linux computer and still the same result with the ch340g chip failing.
This thread seems to talk about a problem using loopback on ch340g Uno's.
serial
More information on Nano's with ch340g.
opened 07:00AM - 14 Nov 15 UTC
First. let me appologize for the length of this post, but I feel this is a very … important issue.
I have been doing some more testing to verify GRBL's running of g-code files. I decided to get a serial port sniffer program to see exactly what is being sent, and what is being received to verify if any of these uncovered errors are from my GUI, or something else. What I have determined is that the data sent to GRBL is correct, but the echoed return is not correct, meaning the error happens somewhere either in the arduino, or in the GRBL code. See the following description to see how I came to this conclusion.
As further testing, I made a small program to use for testing. This program has streaming code that is very streamlined with nothing extra except what is absolutely necessary for streaming and for detecting GRBL error messages. Nothing else. Both the send-response and the character counting protocols can be used and both have generated errors. The only other thing the program does is record the GRBL echoes so they can be compared to the original code for discrepencies. The files can be streamed to GRBL without any timed status requests and the following errors were encountered with timed status responses turned off.
I am testing with a CAM generated g-code modified to have only G0 commands. This results in very fast streaming. If I slow the stream down a little by placing an intentional delay in the streaming code, it works as expected without errors, but at full speed GRBL doesn't always echo back the same line that was sent and/or throws errors. I have verified that the lines sent are correct by using a serial port sniffer program.
For example, in a recent run using the character counting streaming, the following lines were sent at the very start of the run:
G01G21G90X-0.5375Y3.5375Z3.3598F4000
X3.8999Z1.0234
X3.896Z1.0262
X3.8645Z1.0475
X3.8566Z1.0527
**X3.8212Z1.0742**
X3.8173Z1.0765
The above first 7 lines were immediately sent by the GUI and the character count, including a LF at the end of each line coincidentally totals 127 characters which fills the RX buffer, and the sent lines were verified using the serial port sniffer. The response from GRBL was:
[echo: G01G21G90X-0.5375Y3.5375Z3.3598F4000]
ok
[echo: X3.8999Z1.0234]
ok
[echo: X3.896Z1.0262]
ok
[echo: X3.8645Z1.0475]
ok
[echo: X3.8566Z1.0527]
ok
**[echo: X3.8999Z1.0742]**
ok
[echo: X3.8173Z1.0765]
ok
Note the 6th line. The echo from GRBL has the wrong X value but the correct Z value. Remember that all of the above information is from a serial port sniffer and not from my own program. However, my test program shows the exact same thing when comparing the echo from GRBL to the original G-code file, showing that the 6th line does not match. A second run of the same file got through this point fine without an error.
#
During another test run, the lines sent were:
X2.8811Z1.167
X2.889Z1.1702
X2.9362Z1.1889
X2.9441Z1.192
with these responses from GRBL
[echo: X2.8811Z1.167]
ok
[echo: X2.889Z1.1702]
ok
[echo:]
ok
[echo: ]
ok
[echo: .9362Z1.1889]
error: Expected command letter
[echo: X2.9441Z1.192]
ok
This was toward the end of a 90,000 line G-code file run using the send-response protocol during check mode. Like before, the serial port sniffer confirmed that the line that generated the error is sent correctly with a LF used as an end of line character. but note that GRBL echoes 3 times for that single line and drops the "X2" in the final echo. The serial port sniffer detected no extra end of line characters in the sent data stream.
#
I'm not sure what to make of this. The above errors, especially the first example is weird and makes me think it may be a GRBL issue, but I am not sure of that. I am running these tests at the absolute maximum speeds that can be run and running files longer than probably anyone else has before, so maybe I am just exceeding the capability of GRBL, or perhaps this is still related to the baud rate issue I reported. As I said, if I slow the streaming loops down with an inserted delay, but with the baud rate kept the same, the errors go away.
Last week I had experienced errors that seemed to be tied to baud rate. Indeed those errors did go away when only the baud rate was changed, and this was verified using a simple code within my GUI to compare the original file to the GRBL responses. My new test program uses the same comparison, with the main difference when running being that the new code doesn't include all of the stuff that My GUI implements for canned cycles, tool change support, etc, so the run loop is as streamlined as possible.
On my Arduino Nano clones I still haven't been able to generate errors on 250000 baud or 76800 baud, but on my Aruino Mega clone, the opposite is true and the errors appear at 250000 baud, but not at 115200 baud. The Nano uses a ch340G USB to Serial chip but the Mega doesn't, so perhaps the USB chip is the culprit. I'm not sure how to test further, but based on the serial port sniffer program showing that the lines are being sent correctly it seems to me that the error must be either related to the Arduino hardware, or to GRBL code. I am at a loss at this point as to how I can determine which it is, but adding in a slight delay in the streaming loop seems to work ok, but slows things down a bit.
Anyone have any ideas?
"On the nano clones I have this test was a little more involved. It didn't simply work with a couple jumper wires like the mega did. The Nano clones I have use the ch340g USB/serial converter. I did find that shorting the pins directly at the ch340g worked, so I figured there must be something in the circuit making the loopback test not work. I couldn't find a schematic for this clone board, but a little poking around with a meter showed that the TX and RX pads from the ch340g were connected to the RX/TX pins of the 328P with a 1 k-ohm resistor in each line just like the 16U on genuine boards. However, the 16U has separate pads to power the indicator LED's. On the ch340g, the LED indicator lamps were being powered from the TX/RX lines with an LED and 1k-ohm resistor. I suspected that the LED/resistor circuit might be pulling just enough power that just shorting the TX and RX pins together wouldn't work. So, out came my pocket knife and I broke the TX and RX LED's off to eliminate that circuit. It worked and the loopback test was working."