UGS Platform Error while processing response <<Alarm>>

[RedHart66]

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

1. Open the program
2. Click on the Connect icon

   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]

$$ $G $0=10 (step pulse, usec) $1=255 (step idle delay, msec) $2=0 (step port invert mask:00000000) $3=0 (dir port invert mask:00000000) $4=0 (step enable invert, bool) $5=0 (limit pins invert, bool) $6=0 (probe pin invert, bool) $10=0 (status report mask:00000000) $11=0.010 (junction deviation, mm) $12=0.002 (arc tolerance, mm) $13=0 (report inches, bool) $20=0 (soft limits, bool) $21=1 (hard limits, bool) $22=1 (homing cycle, bool) $23=11 (homing dir invert mask:00001011) $24=100.000 (homing feed, mm/min) $25=500.000 (homing seek, mm/min) $26=0 (homing debounce, msec) $27=5.000 (homing pull-off, mm) $100=53.390 (x, step/mm) $101=53.480 (y, step/mm) $102=203.510 (z, step/mm) $110=2500.000 (x max rate, mm/min) $111=2500.000 (y max rate, mm/min) $112=2500.000 (z max rate, mm/min) $120=50.000 (x accel, mm/sec^2) $121=50.000 (y accel, mm/sec^2) $122=50.000 (z accel, mm/sec^2) $130=555.000 (x max travel, mm) $131=746.000 (y max travel, mm) $132=40.000 (z max travel, mm) ok [G0 G54 G17 G21 G90 G94 M0 M5 M9 T0 F0. S0.] ok Error while processing response <> LOOPING IN ERROR DIALOG BOX

[breiler]

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.

[winder]

@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.

[RedHart66]

@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?

[Mitch-X]

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..

[Mitch-X]

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.

[beensolo]

im havin this problem too! help!

[breiler]

@beensolo could you specifiy:

• grbl-version
• universal gcode sender variant and version
• os

[cocasnuno]

Hy folks,I solve the problem updating my all four Arduino Uno with another bootload.Please feedbach for your experimenting results

[snakeb0x14]

Thanks, dude!! this is how to update a bootloader https://www.youtube.com/watch?v=xl-XQ_te8zM

[breiler]

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

[I22Found22Solution]

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.