Advanced Search

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.

Hi everybody! I am struggling to get the MPGs working with my 7i77. These are differential encoders, and are wired into TB4 (z axis and x axis). Whenever I go to launch LinuxCNC, the computer crashes without warning like something is shorting or there is some hardware problem. 
When I unplug TB4, LinuxCNC will at least launch. 

Are there any jumpers i need to move around on the 7i77? The MPG wheels are supposed to run 5vdc…

Why?

This method was used on older NC machines because there wasn't enough memory. But nowadays, transferring data block by block no longer makes sense.

My company is already part of ETG
We make ethercat hardware and are licensed for it

Hi, I'm struggling with LinuxCNC RPi distro, Remora, NVME V5 over the past week. I have flashed multiple versions of the firmware from Scott Alford's github page, but I can never get anything to work. here is the progress so far - I am able to ping the NVEM with no problem but when I do command tests like this one: 
halrun
loadrt threads name1=servo-thread
loadrt remora-eth-3.0
addf remora.read servo-thread
addf remora.write servo-thread
setp remora.enable 1
start
show pin remora.status
I get a false reading and from what if know so far, without a true result, I'll never get LinnuxCNC to communicate with the NVEM. I'm currenly have the 3.1.4 beta on the NVEM but with or without an uploaded config file, I get the false result: show pin remora.status: false. Is the issue to do with the eth driver or something .. as now I have almost given up  .. I have provide any readouts from commands from terminal? I know the NVEM is very picky at how it interprets code etc .. I was hoping this was going to be easy
Thanks is advance.
 

Hi, I’m working with LinuxCNC and trying to control motion from Python , similar to MDI.

The goal is to stream G-code commands dynamically (generated in Python), but still preserve trajectory planner behavior such as:
* continuous motion
* G64 blending (no full stops between segments)

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.

What I would like to achieve is something like:

* sending multiple G-code commands ahead of time (buffered)
* without waiting for each command to complete
* so the trajectory planner can see upcoming segments

Questions:

1. Is there any supported way to stream G-code from Python into a buffer (not strictly MDI) so that  G64 still work?
2. Does LinuxCNC provide any interface to feed the interpreter continuously (like a queue or pipe) instead of executing discrete MDI commands?
Any pointers or best practices would be greatly appreciated.
Thanks!

To use Ethercat, you need to become a member of The Ethercat Technology Group (ETG). Membership is free. www.ethercat.org/default.htm
But membership is only open to companies or businesses and you need a tax number or equivalent in your country.

Linuxcnc is nothing, just a loose community of users. We don't even have a bank account.

This has been explored by a number of the development team members over the years. Most recently by Steffen Moller who lives in Germany where the ETG and Beckhoff are domiciled. (I may have prodded him in this direction)
I had the opportunity to raise Linuxcnc with Martin Rosten, Chaiman of the ETG when he visited Australia a few years ago. There is no way forward.

But now etherlab have a repository and also host the linuxcnc-ethercat driver and I put that repository into the Linuxcnc installer, there isn't really any need for linuxcnc to get involved. (Except to manage the code base).

I would recommend you and Grandixximo as manufacturers join the ETG.

I have been working on a turn-mill kinematics component. 
 

I am not able to understand how the G43 and G54 and G92 offsets should be accounted for in the kinematics.
I would like to do polar as well as cylindrical interpolation using these kinematics.
Polar interpolation will be turned on by G12.1 and off by G13.1
Cylindrical interpolation will be turned on by G7.1 and off by G7.2
It also uses the adaptive feed to slow down when the radius (Joint 0 position) is very close to 0 i.e., joint 0 is very close to the centerline of rotation.
Any comments on how to account for the offsets or general comments for this component are welcome and appreciated.
-automata

I think is mostly architectural and organizational reasons, not strictly a license conflict. Both LinuxCNC and the IgH EtherCAT Master are **GPLv2**, so there's no real incompatibility there AFAIK. The separation exists because the EtherCAT master is an independent kernel subsystem, linuxcnc-ethercat is essentially a glue layer between two separate projects. Keeping it out-of-tree also lets it move faster without going through LinuxCNC's core review process. There is one additional wrinkle: the "EtherCAT brand and technology" is owned by Beckhoff, which adds an IP layer on top of the open-source licensing.