When threading in Mach4 and a mation controller - which part is responsible for threading calculations/implementation?

I read a post on Warp9TD that it was the ESS that did the calculations/implementation and Mach4 simply displays the results/positions/CSS etc

Is it the same for all motion controller plugins that support Threading on Mach4?

thanks

Edit: or does Mach4 have the basic threading code and a plugin enhances it???

Hi,
lathe threading has to be done in real time. Any event information, say an Index pulse, were it to be communicated back to Mach4 would take many milliseconds
depending on the refresh rate of the motion control. As an example the ESS default reporting rate is 25ms. Imagine an Index pulse and it takes up to 25ms just to be reported back to Mach4?
But it gets worse. Mach4 makes a decision and then sends out trajectory information to the motion control.....but it has to pass through the motion buffer. Again as an example the ESS motion buffer
is by default 180ms. Thus an Index signal from the machine could take as long as 25 +  180 = 205ms before the machine can respond. Just not going to happen.

Threading must therefore be autonomous within the motion control.....it does not matter whether its an ESS or a Pokeys or a UC300, they all have the same essential characteristics, namely a reporting cycle
of several to tens of milliseconds and a motion buffer of tens to hundreds of milliseconds. Those delays preclude Mach4 from 'doing' the threading, it must be done by the motion controller.

You might reasonably ask then 'Why are there these long delays?'. The Windows OS is not a real time operating system, and never has been. Windows will do a little of this job, then move on to the next job,
until it eventually gets back to the start, and picks up that first job again. If that job is controlling a  machine....the machine need continuous service ALWAYS, otherwise it will stutter and stall,
no good for CNC. As a consequence any Windows CNC software must calculate  part of the machine trajectory in advance and store it in a buffer for the motion control to 'digest'. Hopefully Windows
can get around to Mach4 again and fill up the motion buffer before it runs out...otherwise the machine will stop with the dreaded 'Run out of Data' message.

So you can shorten the motion buffer, at least with the ESS that I'm familiar with, but you cannot make it zero as that would require that Windows gives Mach4 continuous service.....and that is not how Windows
behaves. I've been told if you have a reasonably powerful PC and very un-cluttered with other software and services you might be able to reduce the motion buffer to 30ms to 40ms. I've never tried it,
I just leave it at 180ms. You can also increase the plugin frequency. By default it is 40Hz, or it sends back data frames to Mach4 every 25ms, but you could increase that to 100Hz or even 200Hz.
What effect it has on the rest of the ESS I do not know.

Even were you to reduce the motion buffer and reporting frequency it would still be something like a 50ms delay between an Index pulse and the machine responding....and that's way WAY too slow
for threading. Delays for effective real time control, lathe threading for example must be a few microseconds, maybe as long as 20 microseconds. Windows PCs cannot do that WITHOUT
some sort of motion buffering.

Each motion control will handle lathe threading their own way, but broadly similarly. In particular they need to be able to measure between encoder pulses (or index pulses) and thereby determine the exact
rotational speed of the spindle. Then they must calculate the advance rate of the Z axis to produce the right pitch, and lastly must use an index pulse to synchronise the start of the thread.
All-in-all its quite a task. For quite some years the UC300 series of motion controls did not support lathe threading at all. In the end they did bow to customer demand.

The bottom line is that single point lathe treading is done and supported by the motion control board. Those boards are proprietary and the software is not open to view or edit. Aside from anything else
most motion controls use an FPGA which is programmed by Verilog or similar software. Most unlikely therefore that you or I could reasonably interpret much less edit or craft our own code.
To my knowledge you have to use what features the motion control manufacturer has provided and live within its limitations.

If that does not appeal then use LinuxCNC. LinuxCNC runs on a specialist Linux distro which is, or at least is very close to, real time. Then you could write your own threading code in C.

Craig

Hi,

Each motion control will handle lathe threading their own way, but broadly similarly. In particular they need to be able to measure between encoder pulses (or index pulses) and thereby determine the exact
rotational speed of the spindle. Then they must calculate the advance rate of the Z axis to produce the right pitch, and lastly must use an index pulse to synchronise the start of the thread.
All-in-all its quite a task. For quite some years the UC300 series of motion controls did not support lathe threading at all. In the end they did bow to customer demand.

I think this is correct, but only generally so.

This is in the Plugin Development section of the mach4 API doc:

Threading
Motion plugin threading procedure.
A plugin must use either one of two threading interfaces. (Or none if threading is not supported.) This interface is defined when the motion plugin registers its motion device with mcDeviceRegister() using the Type parameter bitwise values of DEV_TYPE_THREAD or DEV_TYPE_THREAD2.




DEV_TYPE_THREAD: This interface is defined if the motion controller is capable of shrinking or expanding the time of the way points in regard to the spindle speed. The core profiles the moves and they are output with EX_THREAD movement types in the execution_t struct from mcMotionCyclePlannerEx(). Only the G32 moves are marked with EX_THREAD.
The challenge is to to derive a ratio from the programmed spindle speed and the actual spindle speed. If the speed is slow by 1%, then the way point timeslice time should be increase by 1%, etc... The higher the frequency that the actual spindle speed can be read, the greater the thread accuracy.

The entry and exit moves from a G76 are considered "normal" movement types and do not require any spindle synchronization.



DEV_TYPE_THREAD2: This interface is defined if the motion controller wants to handle the complete coordination of the threading tap move. With this interface, no moves are profiled by the core. Instead, the complete move points are provided in the tap_t structure.
Using the DEV_TYPE_THREAD2 interface (Not implemented currently)
When DEV_TYPE_THREAD2 is selected, the core will send a synchronous MSG_THREAD_START message. When this is seen by the plugin, it should:

Retrieve the thread_t struct information with mcMotionGetThreadParams().
Profile the moves and synchronize the spindle according to the thread_t struct information
Acknowledge any MSG_REPORT_MOTOR_STOP messages with mcMotionSetStill().

If I'm interpreting it correctly Mach4 plans a trajectory for the thread using the programmed rotational rate and the pitch, and the move is marked EX_THREAD. The motion control  waypoints
are typically 1ms (1000us) apart. When threading however the time between waypoints is either increased or decreased to match the actual spindle rotation rate. Say the spindle is 2% faster than the programmed speed
then the 1ms waypoint clock is increased by 2% to 980us rather than the normal 1000us.

This is clever, it allows Mach4 to do the trajectory calculation but allows the motion control the freedom to 'alter' its waypoint clock to suit the actual conditions. A PC, and thereby Mach4, is a very strong
numerical calculation device, while FPGAs are not. This arrangement allows the PC to do what its good at while the FPGA can do a subtle clock change, something for which it is good at, just like altering
the divide ratio in a phase-locked-loop.

Craig

Craig

Thanks for the replies. Perhaps I should give a little background as to why I asked.

I upgraded a Mach3 machine to Mach4 + ESS + MB3.

All went well until I hooked up the spindle encoder(s). I tried an Omro Rotary encoder AB+Z and a single Slot type optical encoder with a disk with holes in it.

The RPM reporting was irratic generally and worse when I enabled A channel threading. The threading did work, but on 50% of the time. The other 50% the G-Code just stopped on the G76 line (forever). After many weeks of fiddling, changing, testing and then finding out that the ESS was basically end of life for the Hobby version because Andy the main dev has gone (went over 18 months ago) I was forced to rip it out and install another system.

I went with Pokeys. The Pin numbering/documentation is "challenging" but when I finally got my head around it... it all work fine - first time!

Then I noticed a little bug in the system - that is easily nullified, but I reported it to Pokeys anyway.

Bug:
When Threading in Lathe(Encoder) mode  - (this is using the AB + Index on the rotary encoder) the thread cuts at 0.02 larger than the commanded thread.

e.g. G76 X9.02 Z-19.0 R0.0 P0.44 Q0.015 F0.75 the thread will report it is cutting at 0.77 in Mach4  - BUT it also cuts a 0.77 pitch thread. So Mach4 is actually reporting the correct thread that is being cut.

So if I set the line to G76 X9.02 Z-19.0 R0.0 P0.44 Q0.015 F0.73 Mach4 cuts a perfect 0.75 pitch thread. OK so not the end of the Earth, a little annoying at most.

Then comes the strange bit. If I set threading to Lathe(Index) e.g. Only using the Index for threading on the Encoder. The then line G76 X9.02 Z-19.0 R0.0 P0.44 Q0.015 F0.75 Cuts a perfect 0.75 and Mach4 reports 0.75 pitch correctly.

So I thought well, Mach4 is always cutting the thread it is reporting to the user e.g. it's just showing whats happening. So I figured the problem was Pokeys.

Pokeys got back to me a couple of times asking for system/setup details, but the last email they said "Have you been contacted by the Mach4 support team regarding this issue?"

Hence me asking the initial question - to get an idea of what the score was on the Mach4 - Plugin threading interaction.

thanks again