GRBL 1.1: can't unlock during 10 failed status polls

[ranknfyle]

I run Win10, UGS 2.1.14 (.\bin\ugsplatform64.exe), and a CNC machine running GRBL 1.1. On my PC, I have Univ. Gcode Sender (UGS) and LaserGRBL. In LaserGRBL I just click "Connect", then "Unlock" and everything is fine. I'm trying to get UGS working. In UGS, I click "Connect", I see an "Alert" state (probably due to the GRBL's homing settings). Then UGS makes 10 auto attempts to poll the "status". All fail due to "Alert" state. so UGS auto-disconnects. I tried entering "X" or "$X" (unlock) on the command line, while the status is polled, but the command line won't accept my keystrokes. The "unlock" (padlock) icon is grayed out, so I can't click on it. I added .usg/macros/unlock.macro text file with just "$X" in it, but I don't see a way to auto-execute it. I have the ability to re-program (flash) the CNC machine (I think the homing / alarm state can be disabled with $22 = 0). But the machine hasn't been flashed for a while, so flashing could cause issues and I need to get something done, so I'm trying to fix it on the sender/PC side.

[breiler]

Can you activate the verbose logging in the console and try and connect again and paste the log messages here.

[ranknfyle]

I set $22 to 0 in GRBL settings, so now the default state is "Idle" not "Alarm", but this "fetching status" thing (failed) still happens. Verbose output below. I don't see such issues in LaserGRBL or ioSender, they just connect, and it's done. Is there a way to disable this "fetching status" thing?

*** Connecting to jserialcomm://COM4:115200
*** Fetching device status

?
Grbl 1.1g ['$' for help]
Grbl 1.1g ['$' for help]
<Idle|MPos:0.000,0.000,0.000|FS:0|WCO:0.000,0.000,0.000>
ok
*** Fetching device status (2 of 10)...
?
*** Fetching device status (3 of 10)...
?

[breiler]

What type of controller do you have and what firmware are you using? (Provide links to what you've bought and the project page of the GRBL you installed).

The reason that you see a bunch attempt to query the status is because the controller is not responding. I have seen this on the Arduino Mega before. If UGS is too quick to query the status after connecting the controller simply stops responding.