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.

[gerritv]

What brand are your serial converters? I know that the CH340 has issues. I use a FT232 converter, USB to PC, TX/RX/DTR to Arduino.

[Tom-Nelson]

The one converter is a Silicon Labs CP201x, the other is a Prolific PL2303 (or possibly chinese clones) Interesting about the CH340 - my Arduino is a chinese clone with CH340 on board and its worked fine.

I think I will shell out for a genuine FT232 and see what happens

[gerritv]

I no longer have those 2, had other issues at one time, like no drivers. Shall I close this issue? Sorry I couldn't help with a code solution.

[Tom-Nelson]

Thanks for your feedback, and yes please do go ahead and close the issue. Hopefully others will learn from this to avoid dodgy clones.

[electrokean]

Could be poor USB packetising in the serial converter in conjunction with the packetising behaviour of the BT protocol, but I'm still suspicious of mismatched I/O voltage levels between the BT module and serial converter at the PC end (or serial converter and Arduino). Ideally you'd want to use a BT module without level shifting circuitry, and a 3.3V USB to serial converter. When mismatched logic levels are used, things will mostly work but are out of tolerance and can randomly produce weird results like you've seen. It could be less noise immunity, or even temperature fluctuations pushing it just that bit extra,

[Tom-Nelson]

Gerrit, I'm not re-opening this issue in any expectation of a fix - I just wanted to get some additional test information on record so it's there if ever applicable in future or to help others with a similar issue. In summary, I am able to replicate a comms failure with GRBL 1.1e under specific circumstances.

• After launching the app, connecting via serial TX/RX results in a comms error (both hardwired and via BT)
• It happens irrespective of the USB/serial converter and drivers used (FT232, CH340, PL2303)
• It happens at all baud rates between 9600 and 230400
• A serial analyser shows no difference in TX and RX streams between direct USB and Serial connection
• When the app is launched, first connecting via usb, disconnecting and then reconnecting via serial always results in a good connection with no errors. Closing and re-starting the app, and reconnecting first via serial, always results in the comms error
• The error is 100% consistent, always producing the same result I've devised a crude but effective workaround. I have a spare Arduino with GRBL loaded permanently connected to my pc via usb, and my cnc connected via BT. When I launch the app, I first connect to the dummy GRBL, disconenct immediately and reconnect to the cnc via BT. Then everything is fine as long as the app is running, no matter how many times I disconnect and reconnect.

Note: UGCS has no connection problems at on Serial/BT. I just really prefer the GRBL Panel interface look and feel.

[gerritv]

Well I for one would like to understand the cause and fix it!

When you say 'connect to dummy Grbl, then disconnect and reconnect to BT' what are you actually doing? Are you swapping just the TX/RX wires? Part of the issue might be that DTR is used to reset the Grbl controller when I first connect in code. If you are unplugging the actual USB-Serial converter or USB cable then I will detect an error. Would you consider sending me a video of this happening so I see the sequence? My email address is on the page when you click my name at top of page. (xxxx.opaq.com) The HC05 looks interesting so I might be tempted to order a few to play with.

[gerritv]

@Tom-Nelson Thank you for the video, it helped a lot. What is happening: The HC05's do not seem to pass the DTR bounce at time of connection. I do this bounce to reset Grbl. A couple of things to try:

1. Set Startup Delay on settings page to 0 or
2. Issue a reset after connecting to Com12

What is happening (or not happening to be more precise) is that Grbl is not sending the initial message when you connect this way. I use that message to detect if Grbl is 0.9x or 1.x version. If 0.9x is detected (also the default :-() you won't get Work coordinates displayed as that is a calculated value in Grbl 1.x. The message I am keying this from looks like Grbl 1.1f['$' for help]

[Tom-Nelson]

Hi Gerrit, It looks like you've identified the issue. The startup delay doesn't help, but resetting the Arduino fixes it every time. If your default is 0.9x, that also explains why I've never had an issue with my BT connection on the earlier GRBL versions.

Would it be a lot of work to just look at the response to a "?" status report request, and set a switch based on the string composition V1.x <Idle|MPos:0.000,0.000,0.000|FS:0,0|WCO:5.400,5.400,5.400> V0.9x <Idle,MPos:0.000,0.000,0.000,WPos:0.000,0.000,0.000>

Alternative, could you consider putting a switch on the setting page to pre-select the V1+ data stream format?

[gerritv]

I will add an override on the Settings page. Detecting from a status response would be somewhat delayed from the actual start-up, not sure of side effects of that. Might be a week or so but in the meantime you have a more workable workaround.

[MeJasonT]

I can remember many moons ago something about Arduino's having this handshake issue on startup. Unfortunately i've slept since then so my ram has been erased, but there was something.

[gerritv]

GrblPanel expressly blips DTR on connection to force a reset on the Arduino. In case of BT though I suspect that the DTR blip is not passed on. Depends on the implementation of the adapter.

[Tom-Nelson]

Gerrit, You have it right about the DTR blip not going through. The vanilla BT solution using HC05/06 modules only supports simple 2 wire Tx/Rx, so there is no Arduino reset on connect.

On Thu, Mar 23, 2017 at 1:57 PM, Gerrit Visser notifications@github.com wrote:

GrblPanel expressly blips DTR on connection to force a reset on the Arduino. In case of BT though I suspect that the DTR blip is not passed on. Depends on the implementation of the adapter.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/gerritv/Grbl-Panel/issues/89#issuecomment-288727025, or mute the thread https://github.com/notifications/unsubscribe-auth/AI41I8lTsE8A7DahDP4Ly69AvSyLVpQyks5ronpegaJpZM4Lw0U1 .

[StrictlyTech]

@Tom-Nelson I see you stated that you were able to control your machine via HC-05 BT and Arduino Uno. I know you are using GrblePanel, but you mentioned it works with UGCS as well. I currently use UGCS, but I haven't been able to get it to work with my BT. My connection is as followed, an Arduino UNO wired to the stepper drivers of my machine. I then have an HC-06 BT connected to the VCC, GND, D0(RX), and D1(TX) of the Arduino. The Bluetooth works with a simple turning ON/OFF a LED on the Arduino. However, when I tried to connect to the BT COM port through UGCS, the program simply finds only the "Incoming port" and not the "Outgoing port" as it should. When the program connects to the "Incoming port" (the wrong port), it then displays the connection message but resumes to freeze the program.

Can you please help me? Do I need additional wiring or hardware connections? I figured I could just replace my USB cable with a BT module communicating over the onboard serial pins. Do you have any ideal as to why the UGCS isn't finding the COM port that connects and talks to the BT? Is it that I should simply replace the Bluetooth with the HC-05 instead of the HC-06. if so why? Thank you for any help in advance!

[StrictlyTech]

Hello, I have been trying to run my machine with HC-06 BT and UGCS but I can't be the correct COM port to connect. Can anyone help me?

[gerritv]

@StrictlyTech I think the HC06 is Slave only, the HC05 can be slave or master, although if using it at the Grbl end I don't think it matters. I assume you are using a PC to connect to the HC06 then I would try to remove UGCS from the equation and make things a s simple as possible. E.g. use Putty as a terminal to connect to the HC06/Grbl end. Get that to work then try UGCS.

[StrictlyTech]

@gerritv Ok I will go ahead and try that. Thanks

[StrictlyTech]

I downloaded Putty and began sending Hello World to it. I got Arduino communicating with Putty through BT. I am able to turn the onboard Arduino LED on and off by entering 1 or 2 into Putty via BT. However, when I try to enter G00 X-1 into Putty, nothing happens. Putty actually doesn't even show that I am entering data into the command window (the screen just remains blank). Also, when I hook my scope up to the X-axis step pin, I do not receive any readings.

[gerritv]

I am really confused now, what is loaded on the Arduino? Is it Grbl or is it something else? PuTTY doesn't echo what you are typing, it expects the other end to do that. For Grbl,, enter a '?', that should send you a response if all is fine. The default Grbl baud rate is 115200, is that what you have the HC06 configured to run at?

[StrictlyTech]

The image below is my wiring setup (I hope this will help some). I did NOT change anything in the GRBL folder/files. I do have my Bluetooth set at 115200 baud rate. My laptop is Bluetooth compatible as is successfully pairs with the HC-06. Do you see anything wrong when looking at my setup?

[StrictlyTech]

Ok, I see! Sorry, I was running the Putty wrong with GRBL, I was trying to enter a g-code command. I entered '?' as you said and the Putty and I received this...(see image below). Since it seems to be communicating with Putty, why not may it be communicating with UGCS?

[gerritv]

From the response I would say that you are running an old version of Grbl, pre 1.1. Depending on the version of UGCS it might not like the old Grbl. Also because you are using HC06/05, there is no DTR signal to reset Grbl on startup. Using putty you could send a Reset (ctl-x) or use the Reset button on GrblPanel. UCS has a Soft Reset button on the Machine Control tab. For any sender that supports both, the response to the Reset is vital as it tell the sw what version of Grbl is running.

This Issue list is for GrblPanel, you might try it and see how that goes. GrblPanel works with both old and newer versions of Grbl. If that works then I recommend asking at the GitHub for UGCS: https://github.com/winder/Universal-G-Code-Sender