GRBL comms fine on USB but fails on BT

[Tom-Nelson]

I've been using GRBLPanel for some time now with GRBLv0.9j for some time. I had some problems with noise on the USB connection, and tripping over usb cables when switching the laptop from mill to lathe, so made the serial connection from pc to Arduino using HC-05 Bluetooth controllers. It's been working great, and got rid of all of my noise problems.
I decided to upgrade both GrBLPanel and GRBL to the latest versions (1.0.9.12 and v1.1e respectively) and it worked fine when connecting via a usb cable. But when I tried connecting via B T I picked up an issue. The screenshot shows the work posn readout as blank, while the Z machine posn has a bit of the rest of the status string from GRBL showing. Other than that, GRBL seems to be responding correctly to gcode commands issued by the UI. Looking at the verbose output from GRBL, it all looks normal, which makes me think it may be GRBLPanel-related

[gerritv]

Can you post the verbose output as well please? The symptom is very much like a previous user reported, namely the communications path is dropping data. What you see in the Z display is the hint for that. The 1.1 protocol is a bit less forgiving in that only machine position is reported.

[Tom-Nelson]

Here's two screenshots, one with usb connection, one with BT connection.

[gerritv]

While the Status info in the second screen shot looks fine, it doesnot reflect what got displayed earlier in the position display. At some point you lost data coming into GrblPanel. E.g. it doesn't show Idle in Status.
There is nothing in the code that knows whether you are on BT or USB or an RS232 port.
Unfortunately I don't use BT so I have no way to duplicate your set up.
You could try compiling Grbl with a lower baud rate, e.g. 57600 and connect that way.

[Tom-Nelson]

The error, whatever it is, seems marginal. I find that if I launch GRBLPanel,connect on USB, and then disconnect the usb comm port and reconnect on the BT comm port, 2 times out of 3 it carries on working just fine. If, however, I launch GRBLPanel and first-time connect to the BT port, I can replicate this error every time.
I'll try dropping the baud rate (probably only tomorrow because I also have to re-program the BT modules), but will let you know what happens.

[gerritv]

Ah, that is an interesting observation. Try changing the Startup Delay on the Settings page, it will give BT more time to connect etc.

[Tom-Nelson]

I'm afraid changing the startup delay didn't help (tried a 5 sec delay). I also tried slowing down to 57600 and have exactly the same response - I guess I could go even slower but if it was just a latency issue, halving the speed should have sorted it.
Here's a capture of the verbose immediately on connection, I can't see anything missing in it. Maybe it has something to do with CR/LF or some other non-priny

ing character

[gerritv]

Does it retrieve Settings (on Settings tab)?, are there values set in State block such as Absolute etc? You should see a lot of chatter before the point you screen captured.

[Tom-Nelson]

Yes it does retrieve the settings, and I see the offstes and the modal commands coming through as well. Not sure if there's anything else that should be coming through on connect

[gerritv]

I don't understand the symptom given what you see in the status window :-( Does the G54 value show on the Offsets tab?

[electrokean]

@Tom-Nelson Does your HC-05 module have level shifting? The HC-05 I/O pins operate at 3.3V instead of 5V like the Arduino. Even with level shifting circuitry, the signals can get a bit iffy at higher baud rates due to the high value pull-up resistors typically used. Weird though that all the verbose logs look normal, and yet it isn't parsing the responses properly.

[gerritv]

Could you trace the HC05 behaviour using http://freeserialanalyzer.com/? 5 sessions of 20 minutes per day should give enough time to figure out what is being sent to GrblPanel.

[Tom-Nelson]

Hopefully learnt something new that will be helpful. I did trace the serial streams using freeserialanalyser. Haven't quite figured out how to save the sessions, so will try to describe my observations here.
In the USB mode, you start by issuing $$, $#, $G, $I commands as soon as you connect, followed immediately by the first '?' Status Query. GRBL spits out its response to all the $ commands in one packet, and then when it gets the next '?' it responds with a status report.
In BT mode, the initial response to those $ commands comes through as whole bunch of individual packets which may be a little slower, and what seems to be happening is that GRBL is getting a '?' request and issuing a status string while it's still sending through the G54-59 parameters and parser state reports.
It occurs to me that if you were to suppress any '?' status requests until a suitable timeout to ensure all the $ commands have been responded to, that might sort it out. I'm afraid my vb knowledge is too rusty to attempt to try this myself, but if it's something you think worthwhile, I'd be happy to try it out before you publish anything.

[Tom-Nelson]

I have discovered something new on this BT vs USB issue. It has nothing to do with the BT link itself, but the USB to Serial converter which drives the HC-05 from the pc. I connected the RX/TX lines from the converter straight into Arduino pins 2/3 and get exactly the same data corruption. Tried two different USB/serial devices and got exactly the same result. So it looks like there's some sort of incompatibility or port timing issue. I have the latest drivers installed for the serial devices, so don't think that's the problem.
So it looks as though it may be a slightly broader comms issue for anybody who may want to connect their pc to the Arduino via a serial link rather than USB direct.