{"action":"created","issue":{"url":"https://api.github.com/repos/grbl/grbl/issues/845","repository_url":"https://api.github.com/repos/grbl/grbl","labels_url":"https://api.github.com/repos/grbl/grbl/issues/845/labels{/name}","comments_url":"https://api.github.com/repos/grbl/grbl/issues/845/comments","events_url":"https://api.github.com/repos/grbl/grbl/issues/845/events","html_url":"https://github.com/grbl/grbl/issues/845","id":116906322,"number":845,"title":"Sent lines different from GRBL echoes","user":{"login":"109JB","id":10978476,"avatar_url":"https://avatars.githubusercontent.com/u/10978476?v=3","gravatar_id":"","url":"https://api.github.com/users/109JB","html_url":"https://github.com/109JB","followers_url":"https://api.github.com/users/109JB/followers","following_url":"https://api.github.com/users/109JB/following{/other_user}","gists_url":"https://api.github.com/users/109JB/gists{/gist_id}","starred_url":"https://api.github.com/users/109JB/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/109JB/subscriptions","organizations_url":"https://api.github.com/users/109JB/orgs","repos_url":"https://api.github.com/users/109JB/repos","events_url":"https://api.github.com/users/109JB/events{/privacy}","received_events_url":"https://api.github.com/users/109JB/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":32,"created_at":"2015-11-14T07:00:07Z","updated_at":"2016-10-28T07:43:09Z","closed_at":null,"body":"First. let me appologize for the length of this post, but I feel this is a very important issue.\r\n\r\nI 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.\r\n\r\nAs 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.\r\n\r\n 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. \r\n\r\nFor example, in a recent run using the character counting streaming, the following lines were sent at the very start of the run:\r\n\r\nG01G21G90X-0.5375Y3.5375Z3.3598F4000\r\nX3.8999Z1.0234\r\nX3.896Z1.0262\r\nX3.8645Z1.0475\r\nX3.8566Z1.0527\r\n**X3.8212Z1.0742**\r\nX3.8173Z1.0765\r\n\r\nThe 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:\r\n\r\n\r\n[echo: G01G21G90X-0.5375Y3.5375Z3.3598F4000]\r\nok\r\n[echo: X3.8999Z1.0234]\r\nok\r\n[echo: X3.896Z1.0262]\r\nok\r\n[echo: X3.8645Z1.0475]\r\nok\r\n[echo: X3.8566Z1.0527]\r\nok\r\n**[echo: X3.8999Z1.0742]**\r\nok\r\n[echo: X3.8173Z1.0765]\r\nok         \r\n\r\n\r\nNote 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.\r\n\r\n==================================================================================\r\n\r\nDuring another test run, the lines sent were:\r\n\r\nX2.8811Z1.167\r\nX2.889Z1.1702\r\nX2.9362Z1.1889\r\nX2.9441Z1.192\r\n\r\nwith these responses from GRBL\r\n\r\n[echo: X2.8811Z1.167]\r\nok\r\n[echo: X2.889Z1.1702]\r\nok\r\n[echo:]\r\nok\r\n[echo: ]\r\nok\r\n[echo: .9362Z1.1889]\r\nerror: Expected command letter\r\n[echo: X2.9441Z1.192]\r\nok\r\n\r\nThis 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.\r\n\r\n==================================================================================\r\n\r\nI'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.\r\n\r\nLast 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. \r\n\r\nOn 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.\r\n\r\nAnyone have any ideas?"},"comment":{"url":"https://api.github.com/repos/grbl/grbl/issues/comments/256857261","html_url":"https://github.com/grbl/grbl/issues/845#issuecomment-256857261","issue_url":"https://api.github.com/repos/grbl/grbl/issues/845","id":256857261,"user":{"login":"longtolik","id":14175218,"avatar_url":"https://avatars.githubusercontent.com/u/14175218?v=3","gravatar_id":"","url":"https://api.github.com/users/longtolik","html_url":"https://github.com/longtolik","followers_url":"https://api.github.com/users/longtolik/followers","following_url":"https://api.github.com/users/longtolik/following{/other_user}","gists_url":"https://api.github.com/users/longtolik/gists{/gist_id}","starred_url":"https://api.github.com/users/longtolik/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/longtolik/subscriptions","organizations_url":"https://api.github.com/users/longtolik/orgs","repos_url":"https://api.github.com/users/longtolik/repos","events_url":"https://api.github.com/users/longtolik/events{/privacy}","received_events_url":"https://api.github.com/users/longtolik/received_events","type":"User","site_admin":false},"created_at":"2016-10-28T07:43:09Z","updated_at":"2016-10-28T07:43:09Z","body":"@109JB : Ok, then the **checksum** also can be implemented as a comment to G-code block.\r\nFor instance, a lot of sensors are designed so.\r\nBut it seems to me that **it is not a transmission error** at all.\r\nOtherwise, how putting a delay can affect?  We send, say: G01 X25.2876348 Y56.8765439 F500 - this line is transferring anyway, do we add a delay or don't and errors must occur in both cases.\r\nI resolve my problem reducing lines, instead of above one, I send: X25.28Y56.87 (in my case one hundred's of millimeter accuracy is enough). Such short lines let me put some delay after sending. Result packets sending frequency remains the same. \r\nI use FTDI USB-serial chip, connected to Rx/Tx pins of ATmega328P. Connecting HC-05 Rx to FTDI Tx, I was monitoring G-code receiving by 328P in Terminal window. They always were very clean, without artefacts. So, now I've decided that Grbl controller just cannot do its job when the data are going too fast or G-code lines are too long and complicated to be analysed. And Grbl skips some bytes...\r\nThanks."}}
{"actor":{"display_login":"longtolik"}}