Advanced Search

If your current Mesa setup already delivers stable rigid tapping, and you’re not confident you can guarantee the same margin of performance and robustness with EtherCAT, then from an engineering and risk standpoint there’s no strong reason to change.

EtherCAT can certainly work and can reach high performance, but it requires more integration effort, tuning, and understanding of the drives and control cycle to achieve the same level of determinism you already have with Mesa.

If the goal is simply to get “the same performance” you already have, the change becomes technical risk without a clear benefit. In that case, the most conservative and rational decision is to stay with Mesa.

Moving to EtherCAT only really makes sense if there is a clear advantage (architecture, cabling, drive availability, industrial standardization, etc.) and you’re willing to invest the time needed for commissioning and tuning to extract the same level of performance.

It seems remora is working ok. There must be issue with GUI. Try using axis gui first. UART just shows startup msgs on remora.

sorry I thought I answered. Because the QTP post is shipped by Sheetcam its set up for it to be master (to be polite to Les). But there are some variables at the top of the post to make QTP to be the master. In this case, it just sends the tool number to QTP and it retrieves that numbered tool from it's list. QTP has a tool that takes an exported sheetcam tool library  and converts it to  QTP format. read the docs.

Finally Sheetcam has both widows and Linux versions of their software and a single license allows you to use both.

You should also look at monokrom as recent advances by Joco with the internal cam is pretty amazing! Plus it also does its own hole processing by replacing any hole gcode with optimized leadins.

This interesting,I have thiked on this in the past, and certanly there are a lot of tools all of them are separated eforts, I think the features that software  should include but not limited to:
-Open DXF natively and generate the G-Code,
-Includethe database aproach used in monokrome to optimize holes.
-Ease of use, from final user stand point.

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