Request: Support for grblHAL

[phil-barrett]

grblHAL is a multi-platform 32 bit version of Grbl. It adds new features like canned cycles, tool change and a number of control and reporting options as well as things like input button pin invert. It also supports ethernet and wifi connectivity.

Currently, grblHAL needs to be compiled to run in compatibility mode to work with UGS but in doing so it omits the new features and control options. It would be great if UGS was able to work directly with grblHAL native. Basically, I believe the issue is handling the additional messages that grblHAL generates.

grblHAL currently runs on 13 different microcontroller platforms. I have a breakout board for grblHAL based on the Teensy 4.1 that I sell on Tindy. Currently I don't recommend UGS to my customers but would like to be able to. This is especially true for Linux and Mac based platforms. I'd be happy to help with any questions. The github repository for grblHAL is here and the issues section is quite active. TerjeIo, the developer, is quite helpful and, I am certain, would be more than happy to help. There is even a thread about using UGS.

Minimal viable product features:

• [ ] Streaming file, pausing and stopping
• [ ] Processing of Gcode states
• [ ] Status report for machine coordinates
• [ ] Status report for work coordinates
• [ ] Jogging
• [ ] Homing
• [ ] Firmware settings
• [ ] Overrides
• [ ] Connection over TCP

[breiler]

Your break out board looks really nice, I think that I will order one for myself for Christmas. 😄 I took the liberty to add a few MVP-features checklist to help us keep track of the support implementation progress.

[phil-barrett]

Thanks. I have one customer that is rather pointed about wanting UGS and nothing else! He would be over the moon.

I think it should be relatively easy to add support though those are famous last words more often than not!

Contact me through tindie and we can work something out.

Phil

[andrewfernie]

I saw the commit for basic GrblHAL support so tried the nightly. No problem getting it going on Windows with the latest GrblHAL running on a Teensy 4.1.

One minor issue is trying to use a keyboard shortcut to run the homing routine. I assigned Alt-F6 to home so that I could run it from a programmable keyboard. This works fine with a standard grbl controller but not with GrblHAL. Doesn't matter if I use my programmable keyboard or typing Alt-F6 on the standard PC keyboard, there is no response. Unplug the controller and plug in a standard grbl controller and it works. All my other keyboard shortcuts work fine with either controller.

No problem running home with the UGS UI button, so not a big deal, just strange that home doesn't work as a shortcut.

[breiler]

@andrewfernie thanks for the report, I'm currently building a test rig to test all the basic functions. I'll have a look at this once I get up and running.

[terjeio]

A couple of observations regarding TCP connection:

After connection is established a soft reset is sendt to the controller. This responds with the welcome message, and after that silence from UGS. I have checked that the welcome message is actually delivered on the wire - both with PuTTY and my own sender.

grblHAL accepts realtime commands from the serial port when another stream has control. If I request a real-time report after connection is established this will be sent to the TCP stream as well as to the serial stream. When UGS receives this report it logs the welcome message and request settings and parser status. After that is seems to work as it should.

**** Connected to 10.0.0.119 @ 23 baud ****

Real time request from serial port sent...

GrblHAL 1.1f ['$' or '$HELP' for help]
>>> $$
$0 = 10.0    (Step pulse time, microseconds)
$1 = 25    (Step idle delay, milliseconds)
...

If disconnecting and reconnecting sometimes (always?) the reconnect happens after a delay of more than 10 seconds, this without any indication in the UI that a connection attempt is in progress. Perhaps the connect button should be disabled while this is ongoing? I do not get a delay when reconnecting with my sender so I believe this delay is on the UGS side.

Currently grblHAL sends a push message on connect: [MSG:TELNET STREAM ACTIVE]. This will be removed in the next commit since it confuses UGS. The message will still be sent to any other connected stream(s), this to inform them that they are no longer in full control.

[tcurdt]

I also ran into this when sending a M6. The board changes into "tool" mode, and while UGS keeps the connection open it goes into disconnected mode.

sender:
3F                                        ?
board:
3C 49 64 6C 65 7C 4D 50 6F 73 3A 2D 37 36 32 2E  <Idle|MPos:-762.
30 30 30 2C 2D 35 30 36 2E 30 30 30 2C 2D 31 2E  000,-506.000,-1.
30 30 30 7C 42 66 3A 33 35 2C 31 30 32 33 7C 46  000|Bf:35,1023|F
3A 30 3E 0D 0A                            :0>..

sender:
54 31 20 4D 36 0A                         T1 M6.
board:
6F 6B 0D 0A                               ok..

sender:
3F                                        ?
board:
3C 54 6F 6F 6C 7C 4D 50 6F 73 3A 2D 37 36 32 2E  <Tool|MPos:-762.
30 30 30 2C 2D 35 30 36 2E 30 30 30 2C 2D 31 2E  000,-506.000,-1.
30 30 30 7C 42 66 3A 33 35 2C 31 30 32 33 7C 46  000|Bf:35,1023|F
3A 30 7C 41 3A 7C 54 3A 31 3E 0D 0A       :0|A:|T:1>..

Seen with Universal Gcode Platform 20230126