gSender - Hal + Rotary support Early Alpha

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.

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.

1 Like

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.

1 Like

@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.

1 Like

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?

@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

1 Like

What changed, do you know?

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

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.

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.

I’ve coded two macros for gSender (or CNCjs, based on @neilferreri published examples) that bisect the error from a G38.2 followed by a G38.4 probe cycle. With these (one for front/left and one back/left) I am seeing approx 0.03mm error, noting that the step resolution on the ShapeOKO 3XL is (1.8deg-step and 8 micro-steps on GT2/20T) 0.025mm.

Macro logic is: Probe G38.2 fast to locate edge, retreat a little, probe G38.2 slowly and note machine position on completion, probe ‘away’ G38.4 slowly and again note machine position. Halve the difference, adjust for the probe/puck size and probe tip diameter, set zero.

Unless or until Sienci incorporate PRB: capture into gSender, this is likely as good as it gets. I have made a feature request accordingly.

Files attached, hopefully self-explanatory. The key controlling ‘dimension variables’ are all at the top of the scripts, so you can tweak according to your preference.

gSender Macro Probe Scripts.zip (4.0 KB)

As is usual: Caveat Emptor…

Hi everyone

Not quite sure if I can bring up this topic in this forum. I am trying to carve a leaf onto a cylinder. With Aspire I can draw and calculate the c-code and I have also downloaded the “gSender Hal and Rotary” program. After I plugged the rotary wire into a Y axis plug and transferred the g-code into g-sender, I can tell something is wrong because the cutter on the computer screen shows the cutter as being way to big as compared to my work piece.

When I turn the machine on the router moves very slightly left and right and it is hard to tell if it is rotating or not. Mayby somebody can tell me what I am doing wrong or what am I missing. I will appreciate any help . Thank

Yes Andy, holy smokes been looking for a while !

Thanks

I have done further testing, and of particular interest is the accuracy of the visualiser display. I have created a test rotary part in Fusion 360 (using rotary wrap, not the manufacturing extension) and been tweaking the Post Processor to get this working 100%.

GRBL output as viewed in NCViewer:

The same GRBL output then viewed in gSender Alpha HAL+Rotary 1.3.0

This gSender view is not connected to my machine (ShapeOKO 3XL+HAL+Rotary), only a dummy serial port on my iMAC Ventura, but I get the same visualiser result on my MacBook Air Catalina when actually connected to the ShapeOKO/HAL. An air-cut of this JOB using gSender Alpha HAL+Rotary appears to be fully correct - I will hopefully this weekend actually cut this test part and prove that.

I have attached the above GRBL file, the Fusion 360 PP and the F3D file so others can attempt to reproduce the same experiment - to prove or disprove whether it is my use/setup or in fact an issue with the visualiser.

Rotary GRBL and PP.zip (120.4 KB)
Rotary Experiments 2 v72.3mf.zip (196.8 KB)

The next release should fix the outstanding issues with visualization :+1:

1 Like

Fantastic to see such a responsive approach. I look forward to that release being made.

I have spotted one more oddity with this Alpha release. I was cutting a reasonably large .nc file (3.4MB), rotary, origin = Fusion 360, and clicked the visualiser ‘lightweight mode’ slider - the visualiser view reset, and the job halted and needed to be re-started. I had run the same job this week and no stop/reset had happened - it seems only the action of clicking the slider triggered it.
I don’t believe I have noticed this behaviour before in use of Released or Edge builds. I can post the .nc file if it will help understand the issue.

1 Like

With Vortex announced, the count-down to this Alpha being swapped to Edge, or in fact to Full Release must have started in earnest.
Do you have any estimations of dates for the next Alpha, first Edge?

We’re roughly targeting next week sometime.

1 Like

Certainly @AndyCXL! The plan as Kevin said is swap Rotary to Edge, then keep progress on that Edge thread with a focus more on Rotary and HAL support. Ideally it’ll be Main by the time the Vortex ships, but if we’re still not fully confident we can always leave it Edge till it’s vetted

1 Like