Add grblHal Controller

[MARIOBASZ]

I have a new Arduino Due with grblHal (6 axes, G5 for example).
I can't get it to connect, however if I send orders it moves the axes (similar problem already raised?).
If it can be included, as well as in addition to Smoothieware, and G2Core, I'd like to try it out running alongside bCNC.
Note: I have tried modifying COMPATIBILITY_LEVEL 0; one; 10 and does not solve the problem.
Greetings, have a good time.

[MARIOBASZ]

I guess that being able to read G5 (spline, smoothed line, between two points) code I think it will be very useful at least for me (to be able to run faster trochoidal strategy ?, for example). Have access to interpret more extended code of Linux commands too. I would definitely prefer to use bCNC with grblHal, instead of bCNC to create and modify, another sender to move the machine.
Greetings and hugs.

[darkfibre-nl]

@vlachoudis
I second the request for support for grblHAL, it supports many more 32-bit boards.
To a large extent it is compatible with the original grbl. It should, hopefully, require limited time/work to make bCNC compatible, and perhaps support the extra functionality grblHAL offers.

It may be interesting to know the developer of grbl itself is aware of grblHAL and mentioned it may be a promising base for the further development of grbl.

https://github.com/terjeio/grblHAL

[Harvie]

I am well aware of grblHAL and i fully support this project, it is the future of GRBL.
But what features do you exactly need / what is broken?

If the protocol is too much different from GRBL1, we can add new controller driver here:
https://github.com/vlachoudis/bCNC/tree/master/bCNC/controllers

We already support 6 axes. So what is the problem?

AFAIK G5 can be streamed over serial line from g-code file to machine. However probably it is not possible to display it in graphical preview or modify such code using inbuilt CAM feature.

More on G5:
I don't think this will happen in any forseable future. Every basic shape has to be supported across virtualy whole codebase and we have special handling for arcs and lines everywhere. And it even simplifies the development of bCNC. If we add G5 support, then every new feature will have to support it as well, which would make the development much harder. I don't say it is impossible, but it is HUUUGELY impractical with limited resources we have. This problem might easily apply on any other FOSS CNC software... There is no real gain in using G5 internaly, but it makes everything much more complex than using combination of lines and arcs.

Displaying G5 splines on canvas might be possible. But canvas code needs to be completely rewritten as native code, so there's no point of hacking it now.

Maybe we can add code to convert G5 to arcs. I am already doing this manualy when importing DXFs and it works very well. I've tried to use arcfit feature of bCNC on various splines and it does great job converting single spline to several arcs without loosing too much precision. (when compared with backlash of my machine). Also i beleive this is what automaticaly happens when we import splines from SVG files...

[darkfibre-nl]

My request may have been placed in the wrong place. Personally I do not have a need for G5, just bCNC working with grblHAL in general. I think my question is more of a support question, for which I'll open a new issue, if I do not manage to solve it myself.

Happy to hear you support grblHAL!

[terjeio]

The grblHAL extensions are following the original protocol structure, and if a protocol parser is written defensively it should just ignore them. I have looked into how some senders does the parsing and sadly some assume that the data content wise is exactly as described for legacy grbl. There are some extensions that require cooperation from the sender, notably the tool change protocol, but most do not.

An example:

Some of the extensions are due to the fact that some of the processors grblHAL supports cannot be hard reset on connect like the 8-bit arduino processors. This means that the sender should be able to query the state of grblHAL on connect and not only rely on a hard reset to bring it into a known state. One optional extension is that the alarm code can be added as a substate to the Alarm state in the real time report allowing the sender to take appropriate action. A well written sender for legacy grbl could just hard reset the controller to get the alarm code from the ALARM: message, but since hard reset is not always available for grblHAL I had to find a way to provide it - and adding it as a substate to the real time report state was the natural way to do it since it already done like that for the Hold state. So IMO a well written protocol parser should tolerate that for all real time statuses without crashing.

---

Other extensions that can be briefly mentioned is that the full range of offsets are supported, tool offsets for all axes, homing status, several additional real time report fields and also some new real-time commands. I have tried to summarize the extensions in the grblHAL wiki so please check that out.

I am ready to discuss further details and explain the rationale for the changes I have made if this is needed.

Terje - looking forward to more senders fully supporting grblHAL.

[phil-barrett]

I am the designer of a grblHAL Breakout Board. It is available on Tindie. I have a number of customers that are looking to use a Mac or Linux machine (RasPi is quite popular). In those cases, I recommend bCNC to them but currently they have to use grblHAL in compatibility mode. Unfortunately, that keeps them from using the full power of grblHAL. I would be happy to do testing and help debugging if needed.

I could see bCNC being used in a stand alone RasPi 400 based console running a grblHAL based machine. Not telegraphing any product ideas here...

And by the way, Terje Io (who commented before me) is the prime developer of grblHAL.

[avizienis]

Regarding grblHAL support, I just compiled a fresh 3 axis controller and it fails to work with the current version of bCNC. It's stuck in a reboot loop of several seconds with this output on each retry:
`rbl 1.1f ['$' for help]

[G54:10.000,0.000,0.000]
[G55:0.000,0.000,0.000]
[G56:0.000,0.000,0.000]
[G57:0.000,0.000,0.000]
[G58:0.000,0.000,0.000]
[G59:0.000,0.000,0.000]
[G28:0.000,0.000,0.000]
[G30:0.000,0.000,0.000]
[G59.3:0.000,0.000,0.000]
[G92:0.000,0.000,0.000]
[TLO:0.000]
[PRB:0.000,0.000,0.000:0]
ok
G90
ok
Run ended
2020-12-23 18:23:50.424531
Current: 2 [2]  Completed: 100% [0s Tot: 0s ]

`
bCNC version 0.9.14 from 2018 works flawlessly. So something went wrong during that time

[Harvie]

I recommend bCNC to them but currently they have to use grblHAL in compatibility mode.

@phil-barrett Can you please tell me what compatibility level do you use? is 1 enough?

[phil-barrett]

I believe my comments on Nov 4 were incorrect. You should be able to use Compatibility 0. Though, I have heard of people needing Compatibility 1 but in my recent resting, Comaptibility 0 was ok. Around mid December, I downloaded the current version of bCNC and it worked worked fine.

[Harvie]

For me bCNC seems to work relativaly OK with grblHAL level 0, however i did not tested this thoroughly and the pause/resume seems to be somewhat broken... I guess there are some differences... @terjeio do you have any idea why this might be?

[terjeio]

@Harvie Pause does what? A feedhold? Or just stop sending gcode to the controller and let any buffered commands run to completion?

Can you explain "somewhat broken" in a bit more detail?

[Harvie]

When i hit pause (yes feedhold) in bCNC the original grbl decelerates and waits until i resume or reset it. but if i remember correctly with the grblHAL i was not able to resume the operation from bCNC and i had to reset everything and start again.

[Harvie]

Oh no. I've just checked and the problem seems to be bit different. When the grblHAL is on hold and i reset it, it still stays on hold (unlike original GRBL 1.1). Which makes bCNC confused... At least this is what i think based on short observation. Is this done on purpose?

[Harvie]

Also when grblHAL raises some alarm, eg. "ALARM:14" it does not stay on the screen for very long and in half a second or so it replaced with generic "Alarm" without alarm number... I am not sure if this is problem in grblHAL or bCNC...

update: this can be fixed in bCNC by remembering last ALARM number.

[Harvie]

I've added grblHAL specific error messages to the bCNC, so it adds a bit to user experience in grblHAL+bCNC setup.

[terjeio]

Oh no. I've just checked and the problem seems to be bit different. When the grblHAL is on hold and i reset it, it still stays on hold (unlike original GRBL 1.1). Which makes bCNC confused... At least this is what i think based on short observation. Is this done on purpose?

No, and it does not behave like that for me (MSP432 driver). Which driver/version are you testing with ($I output)?

Also when grblHAL raises some alarm, eg. "ALARM:14" it does not stay on the screen for very long and in half a second or so it replaced with generic "Alarm" without alarm number... I am not sure if this is problem in grblHAL or bCNC...

Do bCNC take any action vs. the controller when an alarm is raised? E.g. attempting a reset and an unlock? It is possible this has been fixed in the test branch, at least for alarm 14. When I test from a terminal (PuTTY) it behaves as it should with test branch firmware.

[Harvie]

Do bCNC take any action vs. the controller when an alarm is raised?

Quite possible, but i've fixed it in bCNC today. "Alarm" is now ignored by bCNC when "ALARM:XX" is displayed on screen. That way the alarm number does not disappear.

No, and it does not behave like that for me (MSP432 driver). Which driver/version are you testing with ($I output)?

I am using ESP32 build with Huanyang VFD support (terjeio/grblHAL#68), which you consider rather experimental. Feels like the VFD error handling is bit weird at the moment. I will try without VFD plugin.

[Harvie]

@terjeio I think the realtime feed overrides do not work in bCNC when using grblHAL. Is that possible?

Anyway. Just tested clean grblHAL build on ESP32 (latest git without VFD plugin). And it seems to work reasonably well with latest pip version of bCNC (bCNC==0.9.14.312). Therefore i am closing this issue.

[Harvie]

I also replaced all mentions of GRBL in bCNC readme with grblHAL references, because i think all new CNC machine builds should use grblHAL rather than GRBL.