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