Advanced Search

Is there a real delay with rigid tapping when we're using ethercat?

I'm running my old okuma mill with a mesa setup and it's working just fine. Although max I've tapped is 600rpm.

Don't really know how fast the Spindle encoder is read by the mesa. But i guess it's definitely updating every servo thread cycle.

Can't we expect the same performance for rigid tapping with ethercat?

I think there is a small but important distinction here between a process/sequence watchdog and a true safety watchdog.

A true safety watchdog is about detecting potentially dangerous or uncontrolled physical motion and forcing the system into a safe state (typically STO / safety stop), for example:

If |actual_velocity| > Vmax_safe when the axis should not be moving → trigger STO

If |pos_cmd - pos_fb| grows beyond a safe limit → trigger STO

If encoder feedback is lost while moving → trigger STO

If an axis moves while it is not enabled → trigger STO

If the real-time servo thread watchdog trips → trigger STO

If a safety PLC reports an invalid condition → trigger STO

These kinds of checks usually live in the safety layer (drive safety functions, safety PLC, safety relays, or core safety logic), not inside a process component.

What the current code is doing is more a sequence/process watchdog: it detects that homing did not start in time, did not finish in time, or the drive reported an error. That’s important, but it’s not the same as detecting unsafe or uncontrolled motion.

So I agree with Hakan’s point: the component should probably just signal a fault condition via an output pin, and the machine/safety layer can decide whether that becomes a controlled stop, an axis fault, or in some cases a real E-Stop.

I would just edit the ini file but that means you cant use pncconf or stepconf again. be sure to read ini file docs and homing configuration docs

Thank you for the tip about using offset to square it up. I was never really sure what it was used for. One of the things I added to this machine was adjustability. I'm sure glad that I did. I worked on it a bit getting it back to square and it's now within .5mm. I'll use the offset to get it the rest of the way. I would like to get auto square working. I've confirmed the inputs and the state of homing using halshow. I've never used halscope before. Do I set it up like halshow? What should I be looking for? Thanks both of you for the help!

I believe in the BIOS you can set some options about performance mode in the power section. Further more with ThinkPads have you tried to install tlp and disable some power saving options there? I can imagine that this can help too. But maybe it does not work with the optimizations you have done from before.

You don't do estop in the component.
Have an ouput pin flag for this condition and connect that to machine estop pin if you like to,

Hallo, bei mir ist die Situation ähnlich. Ich habe neu eine gebrauchte High Z S-1000/T mit einer AMB FME-1050 und werde die vermutlich auf eine China-Spindel mit 2.2kw oder 3.5kw umrüsten.

Der Nachteil der Bürstenmotoren ist, dass sie weniger effizient sind und mehr Wartung brauchen. Eine China-Spindel wird höchstwahrscheinlich mehr Drehmoment haben.

@Andrax
I think we’re actually very close in spirit here, but there is one important distinction worth making.In the current code, the triggers for global_estop() are:

• drive reports error, or
• start watchdog timeout, or
• run watchdog timeout.

All of these indicate a sequence / handshake failure (homing didn’t start in time, didn’t finish in time, or the drive signaled a fault). They are not, by themselves, evidence of uncontrolled or runaway motion.So from an industrial point of view, this logic is more a process watchdog / fault handling than a true safety watchdog. Using a global E-Stop here is a very conservative choice (and understandable for a “fail-safe” CNC-style approach), but conceptually it mixes two layers:

• Fault handling: homing failed, timeout, drive error → abort sequence, raise alarm, inhibit motion.
• Safety / E-Stop: hazardous or potentially uncontrolled motion → immediate safety stop (usually hardware/ STO).

That’s why I was suggesting that most of these cases could be handled as axis/sequence faults rather than a global E-Stop, unless there is real evidence of dangerous or uncontrolled motion (e.g. runaway, loss of feedback, velocity growing when it shouldn’t, etc.).So the current logic is consistent as a conservative “stop everything on any homing failure”, but the triggers themselves are not proof of uncontrolled motion — they are proof that the homing sequence didn’t progress as expected.

To square add HOME_OFFSET to your ini. If you are 2mm out of square, the difference in this value needs to be 2mm

You  might do a halscope plot of both limit switches and both joint positions
when homed to get a better idea of whats going on.

chatgpt has a lot to learn. This is the official home comp template
github.com/LinuxCNC/linuxcnc/blob/master...onents/homecomp.comp
these are the pins which are added to joint.N but you can add others
 hal_bit_t *request_custom_homing; // input  requests custom homing
 hal_bit_t *is_custom_homing;      // output verifies custom homing

Andrax, the best way to learn C code is to read it as you understand basic control mechnisms

Crumbs I was sure that the angle used in M19, was the angle after an index pulse, but can see now its after the enable edge.

The spindle position after an index pulse is the angle relative to the index pulse, not the enable.
The enable arms the hardware to detect the index and when index has  been detected by the
hardware, signal the driver that index has been detected. The counter hardware also either latches
the count at index (Mesa hardware does this) or clears  the count at index so that the spindle position
is set to 0 at the index position.

Thank you for getting back to me. That had already been changed in the original file but I forgot to change it in what I posted online. It still has the same problem. Currently it is on joint 2. The constant homing issue has left the gantry a little out of square. It seems like whichever side is closer at the start has the problem

Both joints of a gantry need negative home sequence numbers,
but your ini file has a negative and a positive:

[JOINT_1]

HOME_SEQUENCE = -3


[JOINT_2]

HOME_SEQUENCE = 3

Hello, I finnally got my cnc plasma table running been a little over a year in the making. Very thankful for all the people on this forum who helped me get it going such as Tommylight and Rodw. With this being said im not perfectly happy with the qtplasmac interface. It is light years ahead of mach 3 but still missing some. From my understanding the way it works is the qt takes over the Z axis entirely and automaticly inputs Lead ins and feeds from the material specs, Its like 70% of the way to being a cam software in itself. This kindof makes a mess if you want to use sheet cam or something similar.  you will have options double up that have to be over ridden, aswell as theres not really a great way to run sheetcam via linux as far a i know. So I am embarking on the wild journey of creating a open source cad/cam intergration into qtplasmac. I think with the modern advancements of ai I can have this project shipped in a few weekends. My qeustion for everyone on this forum is what essential features would you like to see? what improvements could be made? My goal is to give a little back to the community and make my software free/opensource or if it turns into a massive project make it so cheap that it can be sold on a one time very minimal fee to cover dev costs with no encryption so pirating is easy for anyone who cant pay the cost.