Advanced Search

Outstanding, thank you!

DRO shows identical position at arc entry and exit — LinuxCNC believes the machine returned to the correct point. But probing a fixed reference shows X shifted +9.3mm and Y shifted -12.2mm. HLFB is configured at 20 counts and did NOT trigger. This means every commanded step was executed by the motor. The error is in the arc interpolation — the step path LinuxCNC generates to trace the circular arcs does not sum back to the correct physical position.
LinuxCNC version: Master (2.9), running on Raspberry Pi 5 (4GB), Debian Bookworm, Mesa 7i96s over ethernet (hm2_eth), SERVO_PERIOD = 1000000.

Indeed I Did Wired it
TB1 Pin7 Input A-, B-
TB1 Pin5 Input A+
TB1 Pin3 Input B+

I would check the 7I77s 5V supply, my guess is that it droops
when you connect the MPGs, either from a wiring error or
too much current.

Does the 7I77 have 5V power supplied to TB1?
 

This may not work for you, but I discovered that I had to leave all Power Management stuff ON, but set times to zero.  If I turned off Power Management I still got screen blanks, auto-logouts, and all the other nonsense.

PCW wrote:

Are the drives step/dir connections single ended or differential?  (single ended is suggested for opto-coupled inputs)

 

Clearpath brushless servos use single-ended opto-coupled inputs.  The 'drives' are built in to the motors - there's no separate drive, and they're powered by (up to) 75VDC.

I'll attach the manual this time...

-Set up the THC, any fine tuning without it is useless when THC is active
-25A for 5mm thick is way to low, roughly 10A/mm is OK
-with working THC, you need to fine tune air pressure (exclusively while the air is ON), voltage=cut height, feed rate
-cut quality will vary based on air moisture, material being cut, nozzle type and wear, so use new nozzle for fine tuning and after you have things working properly

DRO shows the error. Probing the same physical reference point before and after the program gives Y 51.252 before and Y 48.583 after — a 2.67mm shift. HLFB is configured in ASG In-Range mode with 20 count threshold and did NOT trigger during the operation. This confirms the motor followed the commanded path accurately — the error is in what LinuxCNC is commanding, not in the motor execution.

Hi PCW,
you where right: It is no hardware issue.
I managed to use pncconf to get around the problem. Unfortunately pncconf does not support the 7i90 with spi, but I managed to generate a configuration and then change the hm2 driver manually. I hope the rest of the configuration will be no problem, otherwise I will ask in the Basic Configuration Forum.
Thanks again!

Hi all, Firstly great crowd. Love your work.Ok so I have bult a table. Setup is as follows: 1.2mx1.2m cutting capability. Mesa 7i96 card. THCAD2 THC, Unimig Razorcut45 CNC enabled cutter.X Y, Y1, Z config. I have set the THCAD2 to 1:1 10v High status, and the Unimig at a 30:1 ratio, which should produce a roughly 5V at top end signal. I do not have any resistors in the mix.I have the cutter running but only WITHOUT THC. It cuts, BUT it does not do this nicely and I do not know how to best tune the system. I started on 5mm steel. (probably a little ambitious.). And I dont have enough knowledge on how to set the speeds, heights etc.. to get a clean cut before THC. Then I will need to solve THC. But thought best to get basic answer on settings for the 5mm first then the THC. So settings are as per the images below. I have not performed any other settings other than servo setups and max speeds. Unimig fires off, so Arc on/off work. Arc OK seems to be ok as when has no steel, it shuts off. THC yet to get working. 

Thank you for working on this... advanced lathe stuff is a little niche in LCNC-space.

I don't know how the kinematics coding works, but maybe consider not hard-coding 'JOINT_0, JOINT_1, etc" and let the user/integrator determine which joints/axes are the rotational, axial, and radial ones.

Reason being someone with a mill and a 4th axis might want to rotate the A or B axis and use Y instead of X for the radial moves.  Would make the kinematics more flexible for different setups.

In addition to a tool-slide, I have a linear slide bolted to the headstock of my lathe used for a parting tool.  I've defined it as axis V, joint 3... and it'd be nice/interesting if I could mount a live tool to it and use polar/cylindrical interp on it.

Perhaps expose some HAL pins, or an INI section with explicit statements like:

[MILL_TURN]
RADIAL_JOINT = 0
AXIAL_JOINT = 1
ROTATIONAL_JOINT = 2

Would permit adjusting the kinematics to suit edge cases, even it if defaults to the standard X/Z/C arrangement.

Regarding offsets... I'd think G43 would be pretty straightforward, but I'm no expert.  I've attached the programming manual for my Emco lathe, which has Emco's interpretation of the Fanuc 21TB polar/cylindrical interpolation.  Please see pages 35-39.

To summarize, 21TB:

• Only permits cutter compensation to be programmed after polar/cylindrical interpolation mode has been engaged
• Cutter comp must be turned off before disengaging interpolation
• "The coordinate system must not be altered" - I take that to mean G92 offsets must be zeroed before engaging interpolation

Hope this helps a little

Could someone provide an example of how this works? I’m having trouble understanding how MDI blending is supposed to behave and how to implement it correctly.

The problem I see is that standard MDI execution appears to process commands one-by-one, so the planner does not have enough future segments to perform blending. This results in stop-and-go motion.

That is not correct. Linuxcnc supports stacking (blending) of MDI commands.

I was planning to write a simple DSL for generating motion.

The idea is to have my own commands and then translate them into G-code. If I don’t want to modify the existing interpreter, the obvious way is to just convert everything into standard G-code but then I’m limited by what G-code can express.

Another idea I had was to keep most of the logic in Python and send something like a stream or batch of motion instructions to LinuxCNC, so it could still handle them with proper blending (G64) and without stopping at every segment.

I realize this sounds a bit hacky, but I’m trying to find a balance between flexibility and still using the built-in trajectory planner instead of reinventing it.