Closed RedHart66 closed 4 years ago
I loaded my Arduino with Grbl 0.9j and tried a the latest commit from March 25 and it worked for me.
I'm curious about this from your console log, it looks wierd that those two lines are next to each other:
$$
$G
Could you give it a try using single step mode (change this under preferences).
If this doesn't work I think your next step is to try Grbl 1.1f. The Grbl 1.1e contained the following fix, maybe it is this you are experiencing?
Contains a critical bug fix for alarm handling. A recent change to internal alarm codes were not handled correctly and would occasionally show the wrong code and enter an infinite loop.
@breiler those are sent automatically in the response handler after a GRBL version is detected:
try {
this.sendCommandImmediately(createCommand(GrblUtils.GRBL_VIEW_SETTINGS_COMMAND));
this.sendCommandImmediately(createCommand(GrblUtils.GRBL_VIEW_PARSER_STATE_COMMAND));
} catch (Exception e) {
throw new RuntimeException(e);
}
It is technically incorrect to do this because of $$
and $G
accessing the EEPROM. But in reality, they are received properly by GRBL almost 100% of the time. Single step mode is temporarily enabled while processing those commands in GrblCommunicator:sendingCommand
, this feature might not be enabled in the July release.
@breiler I tried your suggestion of single step mode but this made no difference other than making the $G appear after the $$ list. A rerun of the code with single step mode off then also produced the same result. I am nervous of altering the firmware as you suggest as my only working solution is UGS Classic with 0.9j. If I lose that by not being able to re-install 0.9j after trying a version 1 I am stuck! Thanks for your swift suggestions by the way. The fact that UGS works with 0.9j suggests something significant has altered in the initialising scheme in UGS Platform. Could it be that ugsplatform has a more rigorous communication system than UGS Classic has, which means UGS can carry on further?
I am getting the exact problem as reported in #812, using both Classic and Platform - Endless error loop. This error only started yesterday after everything had been operating ok for weeks (Mac Air running OSX 10.13.1). I downloaded and re-installed the current stable builds today. The errors still there. The only way to exit the error loop is shutdown. The strange thing is that if the Mega is not wired to drivers or any other pins, and only connect to the computer, it connect ok on both Classic and Platform..
For those of you that are interested, I went through and systematically replaced all component and updated and reinstalled all the relevant software. Only upon removing the installed USB-Serial Drivers and replacing them with the updated CH34x Drivers for Mac, did the issue cease.
im havin this problem too! help!
@beensolo could you specifiy:
Hy folks,I solve the problem updating my all four Arduino Uno with another bootload.Please feedbach for your experimenting results
Thanks, dude!! this is how to update a bootloader https://www.youtube.com/watch?v=xl-XQ_te8zM
Closing issue as it seems that upgrading the Arduino boot loader fixes the problem. https://github.com/gnea/grbl/wiki/Known-Issues#usb-to-serial-transmission-errors
SOLUTION FOUND >>>>>> Two simple steps:
1) CLEAR the EEPROM. Upload the sketch to clear all the EEPROM values to 0. 2) Re-upload the GRBL sketch
That's it. The problem is most likely a changed value in the EEPROM, so you have to reset them all to 0s.
Problem description
UGS Platform Error while processing response <>
This occurs on connecting. See text from console below..
It does NOT occur with UGS Classic.
Expected Behavior
Correct connection
Actual Behavior
Get looping dialog box saying Error while processing response <>
on connection attempt.
Steps to Reproduce the Problem
Specifications
Version
UGS Platform 2.0 - Nightly Build July 23, 2017 UGS Platform 2.0 - Nightly Build March 25, 2018 -->
Operating system
System: Windows 10 version 10.0 running on amd64; Cp1252; en_US (ugsplatform)
Platform
Grbl 0.9j -->
Other
This seems similar to #812, which is supposed to be fixed.
* Connected to COM3 @ 115200 baud ** Grbl 0.9j ['$' for help]