Advanced Search

with which version of LNC is it possible to use the hal_bridge component?

hi grandixxmo, any further development on the 9D S-curve branch?
what is the area of testing we need to look at.
If we can setup some direction, we will get multiple volunteers to help check the work that is already done.
-automata

You could, but you risk more damage if you accidentally connect the 5V  to a 3.3V signal.

Most likely the inputs of the 26LS32 has been damaged so the chip needs to be replaced.

This takes care and protection of the nearby plastic connectors with some kind of
insulation from the hot air gun heat (I typically use some paper sticky labels on
the green connectors)

Hi all. I have an open PR (#3969) that adds a new rotary axis behavior and would like input from people who actually use rotary axes. The problem it tackles is the long unwind: after a job that accumulates rotation, a simple G0 A0 takes minutes spinning back to zero. Related, CAM output of G1 A45 from A350 normally does the long way 305 degrees instead of the short 55, unless you use sign convention everywhere. WRAPPED_ROTARY exists but uses the input sign as direction, rejects values outside plus or minus 360, and does not wrap the DRO or 5423 to 5425 parameters, which some users find awkward.

The PR adds an INI flag, AXIS_x ROTARY_MODULO equals 1, mutually exclusive with WRAPPED_ROTARY. With it enabled the default mode is M26, where every absolute rotary move takes the shortest path. G0 A0 from any accumulated value goes the short way, no long unwind. There is also M27 which uses the sign of the input to pick direction and modulos values above 360. So A45 goes forward, A-45 backward, A720 becomes A0. DRO and 5423 to 5425 are wrapped to 0 up to 360. Internal motion-side position stays accumulated so stepgens, encoders and PID see no discontinuity. Multi-turn winding is done with G91 incremental, same idiom as Heidenhain IA+, Siemens, and Fanuc G91.

If you use rotary on commercial controls this should feel familiar. M26 default matches Fanuc rot_type 2 and Heidenhain M126 and Siemens DC. M27 matches Fanuc rot_type 1 and Heidenhain M127 default and Siemens ACP/ACN. The axis flag itself is the LinuxCNC equivalent of Fanuc parameter 1008 ROAx, Heidenhain shortestDistance, Siemens MODULO axis config.

What I want to hear: does this behavior fit how your CAM emits G-code, would M26 default plus plain absolute output Just Work for you or would you need M27 sections, are there kinematic configs (coupled 5-axis TCP, gantry rotary, weird mappings) where you think this would behave badly, and do you have test G-code you would like me to run through it before merge.

PR is at github.com/LinuxCNC/linuxcnc/pull/3969, original issue github.com/LinuxCNC/linuxcnc/issues/3902. Branch grandixximo/linuxcnc:rotary-modulo, builds clean against master. Happy to iterate on design if there are cases I am not covering. Thanks.

Hi, I did try it but did not work.

I have abandoned the idea of setting up the Linux Cnc in the nuc.

I tries the same operations in an anther compact mini itx system with i3 processor, it just worked fine.

Might be some network issue, due to the realtek nic driver.

Thank you,
Antony.

ffffrf wrote:

7. MOST IMPORTANT: so I have tried a traveling steady rest - the problem is, all of the tools have slightly different Z offsets (imagine a R handed 55 deg insert tool vs a parting blade - I guess I could solve this by having even more customized tool holders such that the actual cutting point of the insert of each tool type are all exactly lined up to the guide bushing, but I found this hard to do in my previous project which is why I was trying to pursue the W axis method (in addition to it being useful once I create the Y axis
 

I don't think you're gonna be able to get every tool exactly on the same Z point using separate tool holders.  But you can certainly set a Z-offset for each tool even without the additional W-axis.  You mount the tools as close as you can to some Z-point, and then set a Z-offset for each one to get them spot on.

The only thing a separate W-axis + fixed location bushing would help with would be getting clearance for tool changes without having to pull the partly-machined part back through the bushing.  Although now that I think about it, that'd be a pretty good reason to have one...

My ramblings about loading the stock was meant to get you thinking about the stock remnant.  Even if your Z has 12" of travel, you won't be able to cut whatever stock is inside the headstock/bushing once the new Z spindle nose is up against the back of the headstock.

Even if the bushing is only 1"-2" long, if it's mounted in the old headstock you can't cut whatever length the headstock is.  The Taig headstock looks to be about 4" long.  Add ~1" for a pulley to power the rotating bushing... so 5" long.

That's 5" of waste for every 12" piece.  If you use 18" stock it hurts less, but about 1/3 your stock simply can't be machined because the sliding headstock runs in to the back of the fixed headstock.

I suggested a traveling steady because you could build it very, very short, but still have a powered bushing.  The steady frame gets bored in place (as in Andy's vid) for a couple of AC bearings, and you make a bushing carrier 'spindle' which is just barely longer than the bushing.  The frame could even have a mount for a small servo built in.  If you get the whole thing down to 2" long, that's WAY less waste per piece of stock.

If you aren't keen on a traveling steady mounted to the X/W carriage, making a new - really short - fixed headstock would cut way down on stock waste.

hmm linuxcnc 2,9 doesn't have the hal_bridge component nor a way to use it.

That may be why it wasn't working too

Could probably get it to work in 2.9, but it would take some experimenting.

Hey thanks for your detailed response and definitely gives me some food for thought, I wanted to respond by point:

1. Yes plan is to remap T and use a W axis, and agreed that W would only be called during tool changes
2. My initial plan was to have a bushing with radial set screws to give enough friction to have the unpowered lathe headstock spin by friction, however, I agree I think it would probably be better to just slave two servos together so I will probably do that
3. I do plan to add a Y axis with two vertical axis at each end of the X axis cross slide but that is still a work in progress to design
4. I currently do have adjustable height tool holders and will use those temporarily
5. I do think I have space to slide the stock in - my maximum stock diameter will be 1/4 inch so around 6mm
6. As far as advancing the stock - I am not sure I am picturing what you are suggesting correctly, the new Z axis will be 12 or so inches so I will have about a foot of stock loaded in at a time, most of my parts are small so each bar of stock will be plenty of parts and I will just manually enter a new 12 inch bar of stock by retracting the new Z axis and unloading it. I don't mind this part being inconvenient for my use case as I only do very small volume parts
7. MOST IMPORTANT: so I have tried a traveling steady rest - the problem is, all of the tools have slightly different Z offsets (imagine a R handed 55 deg insert tool vs a parting blade - I guess I could solve this by having even more customized tool holders such that the actual cutting point of the insert of each tool type are all exactly lined up to the guide bushing, but I found this hard to do in my previous project which is why I was trying to pursue the W axis method (in addition to it being useful once I create the Y axis

Normal config should work as is from the wizard.
No need to change PID nor anything else for open loop stepper, there is nothing to choose, except the step/unit and maybe rarely timings.
Even if the drives are "closed loop", there is no difference from normal open loop stepper drives as the loop is closed on the drive, not in LinuxCNC.

Thank you for reporting back.
If you have a github account, could you please also post there about this.

Hello,

i have now change from axis to gmoccapy and what a wonder.. it works as exspected.. it looks like it is a bug in the AXIS-GUI.

So for comprehend the behaviour on Display Axis do following:

Change your Machine to Lathe:
Set in *.ini
Lathe = TRUE
Then Start LinuxCNC normal
Test moving on Axis - on my Lathe only X and Z
Touchoff Z-Axis set any value and click okay

After this you can not move the Z-axis again but X is moving normal.

Thanks for your reply.
Actually i have got it to work
optimizeMachineAngles2(1); this was set to 0
So it was: optimizeMachineAngles2(0)

I always say AI will bring us a lot of problems, even if i am using it for some things and for some things its great, like claude ai for building apps, scripts, etc. (e.g. the python script for surfacing timber stock works perfectly and looks really professional - it loads the gcode with one click to linuxcnc and i can just click start and even the simulation looks okay), BUT it was claude who told me to put a 0 there, it was 1, but unfortunately earlier i had other wrong settings.

Sorry guys for your time if you have read my long text.
Currently ROTARY POCKET is running and X stays at center, just moves a tiny bit for ramp in. I also checked the g-code for ROTARY PARALLEL LINE MODE and it give correct g-code, X stays at 0 (center of workpiece) and doesnt move.

When generating the g-code, i uncheck my machine configuration and use only the post processor.

Maybe this will help someone.
Br, Denis

Is your machine moving correct? I mean when you use MDI is it moving as expected?

On my machine the rotary axis is "a c-axis", but the Linux machine thinks it is the a-axis. No issue whatsoever I just put an a instead of a c into the g-code and I am done. (for now).

Given that the subscription cost almost 1.5k$ not surprising that there are not many answers.

Is there no one that could explain how it works?
I cant manage to get it to work, impossible. The X and Z axis always wants to turn around the rotary axis (making circles like they would move around th rotary axis) exactly like the end mill does in the fusion 360 simulation - workpiece is not moving but the endmill moves rotates around the workpiece - of course physically its not possible on the machine.,
The X axis should be on center, the rotary axis turns and Y axis moves along the workpiece and Z-axis adjustes the depth. I see videos of on youtube where it looks like it should, but i dont understand why i cant get it to work.

Just merged a fix for this in linuxcnc-ethercat upstream (commit 678314b, issue #457). For EL1014 units that map their inputs at 0x3101:01..0x3101:04 instead of the modern 0x6000/0x6010/0x6020/0x6030, you can now use type="EL1014-legacy" in your XML and the driver routes to the right PDO addresses. No more -typedb=false workaround needed for that variant. Untested on hardware on my end, if anyone has the affected revision, please confirm and post back.