gSender - Hal + Rotary support Early Alpha

[KGN]

We’re super happy with how gSender has been adopted by the hobby CNC community since it’s original release. We’re continuing to grow both new users and new features and are working to create a product that meets everyone’s needs.

Part of that is growth is reaching out to newer portions of the greater CNC community. As such, we’ve begun steps towards supporting two new areas - alternative firmware, and rotary addons.

The first such firmware is grblHAL. We chose this firmware for a few reasons - it’s similar enough to GRBL to be a good first addition, and we’ve identified it as a strong candidate for the updated Longboard controller releasing later this year.

Rotary and 4-axis is also something we’ve been repeatedly asked to support. This is also an area we’re looking at developing our own version of, and have taken some preliminary steps at how we’re going to support it at a software level. We’ve taken steps at supporting files with A-axis commands for both Grbl and grblHAL firmware flavours.

Please note that this is an exceptionally early release - we really want to get this out there to start gathering feedback as soon as possible. A number of functionalities may or may not work unexpectedly with your hardware. This is our first time branching outside of supporting specifically our machines, so there will be some growing pains as we fine tune the new firmware support.

grblHal Support

Choosing your firmware flavour should be as simple as selecting whether you want to use GRBL or grblHAL before connecting.

This is a MVP which includes all expected common functionality (visualization, sending, jogging, DRO, MDI, probing etc.), surfacing, calibration and firmware (minus flashing), macros, laser and (now) Rotary.

Functionality and ease-of-use should be the same experience regardless of what firmware flavour you’re using - all HAL specific functionality are handled behind the scenes so you can continue to interact with the program as you’re used to. Try connecting, loading jobs, jogging, probing, checking out our Firmware tool and other surfacing etc. tool interfaces and anything else you’d typically do on your grblHAL enabled CNC machine.

We’re going to continue to work on further support for HAL specific functionality, along with clean up any rough edges moving forward. Look forward to network connection, flashing, and cleaner toolchanges coming in future releases.

Primarily, this build has been tested on the Flexi-HAL CNC controller in collaboration with Andrew from Expatria Technologies.

Rotary Support

Full rotary support is on its way to gSender soon, you will now be able to run your files that have A-axis movements with ease. We are still working on improving rotary for gSender, you may see some features that don’t quite do anything as we plan on working on them and adjusting a several things in the coming weeks. We do have a few great features that we would like you to try out though:

Visualization

The visualizer in gSender will now be able to visualize A-axis movements for users to see, in addition, we decided to add an object that represents the stock material, which rotates accordingly during a job. We also updated the outline feature to work with rotary files more correctly for those who need to use it with rotary. We plan to refine the visualization in the coming weeks to improve it further.

Rotary Mode

Since GRBL does not support the rotary axis, we decided to get creative and come up with a good workaround. We have implemented a feature named “Rotary Mode” where some firmware values are adjusted to mimic the A-axis movement behavior. You will be able to load 2+1 axes files that utilize the A-axis. You will notice that the Y-axis is disabled in this mode as the A-axis takes its place during a job and the fact that the Y-axis cannot be used when the A-axis is being used, so it is disabled in the app until you Rotary mode. This feature is meant for Grbl machines specifically.

A-axis Support

A-axis movements are not handled on machines running Grbl , so we found a way to mimic the behavior in gSender and allow users to run files that have the A-axis. gSender will interpret A-axis movements as Y-axis movements now, this pairs with the rotary mode feature that helps us achieve this. This behavior only applies to GRBL to allow the app to read A-axis movements correctly.

A-axis Control and Display

You can also control and see the position of the A-axis from gSender. A-axis control works just like all other axes, you have access to jog control buttons on the user interface, as well as the shortcuts on your keyboard or gamepad. The A-axis position readout is available and again works the same as the other axes, you have the ability to zero or go to the zero position, and update the position manually via the position input. Once we’re satisfied that all this functionality is working as expected and no other requests are made for features we’ve forgotten, the plan will be to refine the look and location of these buttons so that they can be implemented more seamlessly into gSender’s existing interface

Download

Note: this is not an EDGE build, it contains completely new functionality aimed at grblHal/rotary users. EDGE will continue to receive updates independently while we continue to move it towards a new, Main release in the coming weeks. Once we’re satisfied with how progress is continuing with the HAL and Rotary support version and Edge is looking relatively bug-free, then Edge will become the new Main and HAL/Rotary will become the new Edge. To make this happen, we’d greatly appreciate and and all feedback you can provide

You can find the binaries for Hal/Rotary on Github.

Release hal-rc1 · Sienci-Labs/gsender

How you can help

Use it! Please try to keep feedback to this single topic thread so that we can more easily distinguish comments that are HAL/rotary specific - we want to avoid the headache of trying to sort feedback between Main, Edge, and Hal/Rot. Any feedback in this thread about functionality either not working or not working as expected will be taken into account. As always, keep in mind this is a very preliminary release, so if you’re especially attached to your work process, bits, or expensive materials then feel free to stay away until the product is more fleshed out.

[AndyCXL]

Fantastic!! Will download and start testing.

For the log, my hardware is:

• ShapeOKO 3XL with HDZ upgrade, inductive proximity sensors
• Teensy 4.1 on Phil Barret’s break-out board
• Self-made rotary 1.8deg/6:1 belt/Rotary axis (identical to the Sienci proposed setup)

Grbl HAL 1.1f configured with

• XYZYA (5 axes, with Y ‘ganged’)
• Inductive proximity sensors on X, Y, Z and A to permit homing
• Homing and Soft limits enabled
• Considering dual-Y sensors with Auto-Square (have the bits, but yet to be installed)

$I+ report
[VER:1.1f.20220325:ACC/HALTEENSY4.1]
[OPT:VNMSL2,71,1024,4,0]
[NEWOPT:ENUMS,RT+,HOME,ES,TC,SED]
[FIRMWARE:grblHAL]
[NVS STORAGE:*FLASH]
[DRIVER:iMXRT1062]
[DRIVER VERSION:220325]
[DRIVER OPTIONS:USB.2]
[BOARD:T41U5XBB]
[AUX IO:4,3,0,0]

gSender running on Apple Mac Catalina (MacBook Air 11, Intel i7, 4GB, Intel 3000 graphics with 384MB)
Principal linear project CAD/CAM: Autodesk Fusion 360 on Apple, with Neil Ferreri’s PP with tweaks
Principal rotary project CAD/CAM: Vectric VCarve Pro on Apple, with Neil Ferreri’s PP with tweaks (iMac Intel Xeon, 32GB, Radeon Pro with VMware Fusion running Windows 11 X64, also MacBook Pro M1-Max 32GB with VM Fusion running Windows 11 ARM)

[AndyCXL]

First test results:

• Install .dmg - success, however first run froze at splash, force-quit and re-run snapped into life. Saw the same ‘first freeze then OK’ on iMac/Intel Ventura 13.2.1
• Select Connect HAL machine, connected first time and recognised the HAL welcome signature - success
• Import settings - failed, but a different list of parameters might be the root of this. Set my defaults by hand and all good. Noticed new entries for Rotary axis in shortcuts.
• Check machine dimensions correctly read from GrblHAL - success
• Import macros - success
• Open linear (XYZ file), check visualiser - success
• Open rotary (XZA file), check visualiser - partial success. Large dimension file not showing full model. Smaller dimension gcode version of same CAD model shows in full. Some sort of clipping seems to affect the larger dimension visual (I can provide zips of both if requested)

3D Large Finish 8thBN.gcode.zip (434.0 KB)
3D Small Finish 16thBN.gcode.zip (160.3 KB)

• Home machine (XYZ) - success

• Home rotary (A, using my $HA macro) - success

• Move rotary and set zero using Rotary tab - success

• Move rotary and Goto Zero using rotary tab - success

• There is no ‘Home Rotary’ function (not presumed to be a feature of the plain vanilla rotary machine? Would be nice if this were a setup option to enable if hardware supports it) EDIT re-running this over lunch, it seems I didn’t get the full screen layout on the first run… Now there is a quad of homing icons XYZ and A, all of which work - success

• Noticed very right side of screen is ‘off screen’ even in full-screen mode. Screen is 1366x768 MacBook Air 11”, 4GB RAM, 384MB graphics Intel HD “3000”

• Move rotary and check stats show position on Rotary tab - success

• Run linear air job (same as used above) - success, including starting spindle (VFD analogue not ModBus)

• Run rotary air job (small file used above) - success. X, Z and A moving, Y not moving - which is correct

Not tested - turning on ‘Rotary Mode’ in rotary tab, as I believe this hijacks the Y axis, if I have read the story of development so far, and my machine has a permanent rotary/A and doesn’t need this (nor do I want $ settings being made accordingly - however, having the various testing function available for permanent rotary setups could be useful)

Still to test: Surfacing function, probe function, checking other rotary gcode files to see if any common factor exists behind the clipping noted above

Observations:

• Some issues with importing defaults, but I think I have seen this before with the ‘live’ gSender import/export and it looks like the same code has carried over to this Alpha (not sure if this is a bug, or a deliberate ‘JSON is different’ protection choice)
• Rotary tab ‘arrow’ icons do not easily convey movement direction, might be better if the arrows were curved to indicate forward (top fwd) or backward rotation
• In surfacing tool ‘widget’, cut depth field defaults to 1mm. Editing this by overtyping results in field value flipping to 0.001 and no attempt at overtyping differs from this. The only way to choose, say 0.5mm, is to select only the first 0 after the decimal point and overtype just that one character
• In surfacing tool ‘widget’, there is no ‘depth per pass’ option. Maybe it is not required, but equally it is not obvious that what is set will be a single pass - reading the gcode ‘layer comments’ suggests the author expected multiple passes to be possible
• $$ console command to show all $ settings does not include A axis (103, 113, 123), whereas ‘live’ and ‘edge’ do show these
• Keyboard shortcuts for A+ and A- jogging don’t appear to be working. I have a self-made jog-dial pendant that emulates a keyboard and sends these shortcuts and all work except A+ and A-. Manually typing them doesn’t work either. Works in ‘live’ and ‘edge’
• Home ‘all’, equivalent to Grbl command $H is not an available icon any more. It is in ‘live’ and ‘edge’, and its absence is not ideal for me. I do like the separate X,Y,Z and A homing buttons, but I would prefer to retain the ‘home all’ too.

A very promising start, and nothing I would call blocking or serious found to date. It is worth noting that I have been using gSender ‘live’ and ‘edge’ with my HAL installation for a good while, and aside from the connect signature recognition (corrected in this Alpha) and the keyboard shortcuts on A, there have been no real issues.

[AndyCXL]

Unrelated, but perhaps of interest, I installed the second Y proximity sensor and re-compiled GrblHAL 1.1f to use Y-axis auto-squaring. It works like a charm! Nice to know that if the Y-axis ever gets out of true, homing Y will correct it.

[Condor00]

Hello KNG!!
I read and re-read the article and frankly, it is flying over my head! Am I the only one that is saying HUH??? I’ve been around computers since 1995 so not a total novice. It would be extremely helpful if you could do a video and show differences and uses between what we are used to and the new grblHAL.Thank You in advance.

[AndyCXL]

@Condor00 The development of GrblHAL came about as the original Grbl was starting to show its age and its internal architecture was never designed for features like rotary axes. Grbl gave a software platform that would run on affordable microprocessors, the Arduino product with Atmel processor, that unlocked the hobby end of the market as opposed to the LinuxCNC/Dedicated PC/Expansion Card that was likely the alternative at the time, and probably the forbear of Grbl’s functionality. A little potted history.

You may have a Grbl based machine (most hobby grade machines are), or a newer GrblHAL based machine. There are subtle differences between the software that makes the Sender software have to be aware and recognise which is which.

In the CNC world, axes have traditional names: X, Y and Z are the best known and likely obvious. When it comes to 4,5,6-axis machines, what are the axes called? Tradition has settled on A, B and C. So the first rotary axis added to a XYZ machine will most likely be known as A. Grbl reads these XYZ axis names as they are used in the gcode to say which axis to move. GrblHAL reads these and also reads the ABC names when present.

There are other new features in GrblHAL that may become mainstream expectation on hobby machines, it’s not just about rotary axes.

[_Michael]

I’m assuming that HAL is Hardware Abstraction Layer, I’ve seen other software projects with HAL in the name and that’s what it meant. My understanding is that it’s how the code is structured, where the HAL layer and above contains the common functionality and then they just have to implement a different layer below the HAL for each chip set they want to support.

It’s a more modern design made for reusability, if my understanding is correct.

[Andy1]

Here is some more reading, first page pretty much says it all, a good explanation.

https://www.grbl.org/what-is-grblhal

[KGN]

Yeah, both previous responses have more or less covered “what” grblHAL is - It’s a more modern version of the GRBL firmware, designed in a way that makes it easier to port to various hardware by separating firmware functionality from hardware specific code.

Right now, GRBL (vanilla) is locked to the Arduino - which has been fine, but doesn’t give us much room to expand with peripherals or new features. There’s also the price-to-power ratio, which the Arduino is not so hot on - it’s not the cheapest, and relatively low power being aimed at the hobby market.

The HAL portion means we’re not locked into a specific microcontroller for our new board design - we can source something that is more powerful for less or equivalent cost. And, looking to the future, if we need to alter the design of the board or can’t source that part anymore, we don’t have to throw out the entire firmware, just rewrite the HAL portion to work with the new hardware - we’ll never be in a situation where we’re handcuffed by our firmware choice.

The above point is the big reason we went grblHAL over some of the other (VERY good) modern firmwares available right now - the other features (multi axis, etc.) are pretty ubiquitous in new firmware flavours, but we wanted to pick something that wasn’t locked to a specific microcontroller, which is a less common ask.

I expect we’ll have plenty of livestreams, documentation, and information available for both grblHAL, Rotary, and the new Longboard as the projects continue - this is mostly just an early preview version of the software side that can help us validate expected behaviours.

[Condor00]

Thank You for your explanation. It really helped.

[Fishon]

I am hopeful the new Longboard will have additional ports so borh spindle and laser can be plugged in at the same time. Also tool changer option.

[Drebz]

What are we talking cost wise for the upgraded longboard? I just received my new Longmill mill and am worried now my longboard will be out of date in a few months.

[Andy1]

Kevin
GRBL remains GRBL, the difference is the hardware abstraction layer if I understand correctly. I assume Sienci’s gSender will pick up the additional functionality Rotary , additional axis etc that Arduino can’t accommodate. I am not sure how that is accomplished but I see an io header on the flexi hal controller board for a Raspberry Pi4b which are even now ridiculously hard to obtain to say nothing of the price of these things. PrintNC has been focused on Linux cnc , is this where we are going??? That decision pushed me towards an Expressif 's ESP 32 solution using FluidNC for my build of the PrintNC after watching cumbersome videos of folks dealing with the hardware abstraction layers. Anyway , i’m curious to see how all this turns out, sounds ambitous.

[AndyCXL]

@Andy1 You are correct in observing that gSender may have to pick up/intervene in the Rotary functionality, in the case where the physical Y axis wiring is hijacked for Rotary/A jobs and Grbl is on the controller. This is a smart move from Sienci, in my opinion, as otherwise Rotary working is denied to users who have current machines and controllers. gSender will, if ‘Rotary via Y’ is switched on (Rotary tab), read A axis in the gcode and present this in the viewer, jog etc, but inline silently translate this to Y before it is sent to the controller.

For me, as long as there is still the ability to operate a permanent Rotary axis (ie: Rotary via Y is OFF), as I have with the advantage of GrblHAL and my own controller upgrade, I get the benefit of the new preview/jog/homing etc functionality without gSender translating A for Y. My testing of this Alpha release suggests it does work and is already quite usable.

[Andy1]

Morning Andy,
Agree, with my PrintNC machine I also use gsender (1.17) for the interface albeit with FluidNC which in my case resides on the developers (Barton Dring 6 pack (axis) ) controller. I was able to use gSender Edge as well, however since 1.2.4 that ability has been lost. I am concerned that the next round of upgrades of gSender (1.17) will do away with my ability to use it and hence i’ll loose my visualizer which would be unfortunate for me.

Anyway, I am looking a rotary axis as well (on the fence with a model, lost sienci’s proposed model, I see you made your own ). I wouldn’t mind having a look see , how big is it?

Since you have phil barrets board, I’m curious as to why you would want to swap a Y for an A. Couldn’t you just add another motor and label it A. After all the rotary does not need to reside on your CNC table?

[AndyCXL]

@Andy1 My Rotary is a 4-jaw with 600mm (just under 24") between centres and a throw (maximum diameter of workpiece) of 120mm (just under 5") - so the centre-line of the axis is about 60mm (about 2.5") above the bed. The 600mm is purely down to the size of my machine along the X axis.

I don’t want to swap Y for A. I have a permanent A, so don’t need to do that. What I was pointing out in my comment was that Sienci do want to offer Y swap A and permanent A, and they seem to have found a neat way to do that.

My setup is to have the Rotary axis permanently mounted on the CNC bed (bolted down), I don’t have the space in my workshop for anything separate. Plus, on the ShapeOKO 3XL there is ‘dead space’ where the X gantry can’t access - when X is fully to the back, the X beam plus the front-to-back depth of the Z axis leaves an inaccessible area. My Rotary is mounted just on the edge of this area, so I am not losing much usable table space on the machine this way, and get the Rotary permanently mounted.

I believe the original post you refer to is: First Tests on the LongMill Rotary Axis Add-on

[AndyCXL]

@Andy1

I was able to use gSender Edge as well, however since 1.2.4 that ability has been lost

What changed, do you know?

[Andy1]

No idea just no response from gSender, initialization ?? Thats what makes me nervous about implementing any further upgrades to ver 1.1.7. I don’t know which sand box is updating which

[AndyCXL]

It sounds like the ‘echo’ that Grbl and GrblHAL give to the sender isn’t being recognised, whereas before it was. Might be a change in the controller software’s response and might be a change in which echo signatures gSender recognises.

My GrblHAL gives out ‘GrblHAL 1.1f’ when it boots/is prompted, pre-HAL Grbl gives ‘Grbl 1.1x’. I don’t recognise your FluidNC controller software, but do you know of any command that causes a re-start that might force it to give out various startup messages - which gSender might recognise. Failing that, connect to your controller with a USB/Serial comms package (PuTTY for example) and see what it receives…?

For example, in GrblHAL from a command console (eg: the one in gSender), typing $RST=& forces a partial reset, and the confirmation string the controller then sends is recognised by gSender as ‘I am here and awake’. Fortunately, in this Alpha release I no longer need to do this - gSender now recognises GrblHAL wake-up natively.

This might be getting a little off purpose for this thread, so perhaps an admin might want to break this off to its own thread.

[AndyCXL]

An observation and a feature request in this Alpha.

When probing, GrblHAL gives an immediate PRB: report when the probe triggers, even if the axis keeps moving through its deceleration cycle before stopping. Issuing a G38.2 or G38.4 probe currently waits for the axis to stop and the co-ordinates are compromised by this ‘post trigger’ movement.

If GrblHAL outputs a PRB: report, capture this into global.state (?) and make it available to the macro sub-system to allow more accurate probing. I can imagine that the state of ‘G38.2 issued but failed’ will have to be considered - if an error follows a G38.x then nullify the PRB co-ordinates somehow - to avoid macros taking the last probe position, wherever that was, even if the probe failed.