Closed c--- closed 10 months ago
Short "video" showing what the GUI does. Note that after I click "Connect" I don't click anything else.
As of UGS 2.0.17 the protocol detection was changed from reading the welcome string Grbl 1.1f
to use the information from the $I
command. This is because more modern GRBL controllers does not require a reset upon connection, and in some cases it is even discouraged.
Unfortunatley the specification for describing the version in the $I
response is a bit loose:
[VER:]
and[OPT:]
: Indicates build info data from a$I
user query. These build info messages are followed by anok
to confirm the$I
was executed, like so: [VER:v1.1f.20170131:Some string] [OPT:VL,16,128] ok The first line[VER:]
contains the build version and date. A string may appear after the second:
colon. It is a stored EEPROM string a user via a$I=line
command or OEM can place there for personal use or tracking purposes.
Many vendors has come up with very creative version variants, but we seem to be able to handle them all by now:
[VER:v1.1f.20170131:]
[VER:1.1i MegaV 4 Axis Router.20190120:]
[VER:1.1g3.20211002.Mega:]
[VER:1.1f.20170801:MINIMILL]
[VER:v1.1f.20170131]
[VER:v1.1f:Some string]
[VER:v1.1.20170131:Some string]
[VER:1.1h-XCP.20220314a:abc]
[VER:1.1h-XCP]
[VER:GD32 V2.1.20220827:]
[VER:ARM32 V2.1.20220827:]
But it appears that a vise developer at Vigotec decided that it was a good idea to scrap the version string all together. You could try and execute the following command $I=1.1f
. That should in theory make the version string look like this which might be parseable by UGS [VER::1.1f]
.
@breiler OK, thank you, that seems to work. I remember reading something about empty version numbers but I did not know that GRBL would allow the user to change it.
Though it would be a good idea to handle all cases rather than crash/hang the software just because of some external input (this is how exploits are born; imagine a "harmless" gcode file infecting your machine with malware).
You are absolutely right, it should of course properly disconnect when it fails to detect the controller.
Version
2.0.20
Hardware / Firmware
GRBL 1.1
What happened
I'm having a problem with a VigoTec controller using UGS 2.0.20 (the "all-in-one-Java-ball") and the latest UGS SNAPSHOT also have the problem (shown below). My previous version was UGS 2.0.14 and it does work without this issue.
It connects and gets the status then immediatlly "disconnects" but it's not really disconnected because it's still polling the controller. Reconnecting doesn't work because "busy" (obviously it's busy because UGS itself already has the serial port open).
Here is the Console log:
The
.ugsplatform/var/log/messages.log
has this:I enabled Java debugging, the full log:
How to reproduce
It's always an issue every connect.
Operating System
Arch Linux latest
Anything else
No other applications have the serial port open.
That's after connecting in UGS but the GUI shows DISCONNECTED and I can't do anything.