It's a bit confusing trying to figure out what Mach4 will and won't do. My goal is to control the new lathe well enough that it can thread accurately granting any physical stability will play into accuracy but if the control system is accurate then I can work on the physical. My thoughts on threading is that Mach4 would have to know where the spindle is as well as where the X and Z axis are. I have searched the forum and find conflicting information so here I am. The forum seems to indicate Mach4 will perform threading and second Mach4 can use my Yaskawa Sigma V servo drives but for the life of me how? The servo drives can be controlled three ways from what I read. Via Mechatrolink, Analog voltage and pulse train reference, and via USB connection (I have played with this a tad using Yaskawa's SigmaWinPlus). So how do I get Mach4 to perform one of these protocols? Next, one would think an optical encoder would be needed on the spindle. How to get Mach4 to read the encoder?

Keshka,
We do lathe threading almost everyday with 1 if not 2 lathes here in the shop with Mach4.
By this point, we have threaded 10's of thousands of parts. 
As far as your motors and encoder goes... you will have to be sure you get a motion controller that can control your drives and read an encoder.  I think the most common way to control motors is Step and Direction, so the pulse train in your case.   
You need to make sure your motion controller can have encoder feedback for the spindle.  I don't know which controllers have this feature, you may have to do some research on your own for that.  We use the HiCON Integra from Vital Systems.  It works very well. 

Hi.
lathe threading is a realtime process and it largely enacted by the motion controller, not Mach4 at all.

Mach4 provides the numeric parameters to the motion controller, and the motion controller handles it from there. Mach4 is at best a supervisor.

There are a couple of variations of the one theme, but the idea remains the same. If the spindle is rotating at some fairly slow but known and constant speed
then its index pulse is used to start the thread. This allows multiple passes as you cut one thread....so your spindle must produce a single index pulse per spindle
revolution. In addition you can use either an index pulse or, depending on the motion controller, an encoder to measure the exact speed of the spindle.

Ideally the spindle speed would be constant, but as the  cutting starts it will slow a little. The controller needs to know the reduction in speed so it can slow the Z axis advance
to have the thread retain the programmed or desired pitch. For example if the spindle is rotating at 600rpm, or 10 revs/second and you wish to cut a 1mm pitch thread
then the Z axis must advance 1mm per rev or 10mm/second. If as a result of the cutting the spindle slows to 550rpm the Z axis advance needs to be slowed to 9.166mm/second
in order to maintain the same pitch. Clearly a absolutely constant and rock steady spindle speed is very VERY desirable for threading.

Some motion controllers use the spindle speed as feedback to try to maintain the spindle speed constant.

I'm not familiar enough with the Hicon to be definitive but believe it has this feature. The ESS with which I am familiar definitely has this feature, that is to say that it can use
either an index pulse or an encoder pulse to slightly alter the PWM to the spindle drive to secure constant spindle speed for threading. This feedback feature may help with
underpowered spindles, but still there is the HIGHEST possible advantage to a powerful spindle of significant rotational inertia for lathe threading.

Craig

Hi,
is your spindle driven by a servo? If it is then that means that the spindle is 'position capable' and can in fact be used as a Caxis.

As you know all CNC machines rely on coordinating movement between axes. Thus a straight cut at 45 degrees would be g1 x50 y50 f500,
whereon both the X and Y axes move at the same speed. But there is nothing to prevent you from coordinating a rotary axis and a linear axis.

For example g1 c3600 z -10 f360

This would result in the C axis rotating 10 times, ie 3600 degrees, while simultaneously the Z axis moves 10mm toward the chuck, ie a 1mm pitch at a rate of
1 rev (360 degrees) per second. Note that Mach would coordinate the acceleration phases also so you would end up with a perfect thread.

This approach does not require any specific hardware support from the motion controller. It does require that the spindle or Caxis can rotate at precisely the right
rate so that it can stay coordinated with the Z axis, ie the rotational 'authority' of the spindle is paramount. In this regard it is a similar requirement that the spindle
be capable of a constant speed irrespective of the load as I noted in the previous post.

Craig

I guess perhaps I might word my question differently. Suppose I ask Mach to execute a G code (G3) to cut a circle. This requires varying the rate and position of the X and Y axis on a mill. Old school parallel port - a pin was set indicating direction and a series of pulses or "steps" are then sent at a varying rate describing the motion of that particular axis. Meanwhile, the second axis is sent similar information simultaneously and coordinated with the first axis controlled by it's own set of like pins on the parallel port. Mach was in charge of the pins. Mach, pulse by pulse decided how often, when and how far each axis moved.

Now given a servo rather than steppers. They receive commands such as positioning, constant speed, constant torque, home. Mach4 no longer uses the parallel port but some intermediate software they call a "plugin". While steppers are more of a digital device (step or don't), servos are analog (move this way, this fast, that far, let me know when your done).

I have Yaskawa Sigma5 drives and servos. The drives are quite smart and handle all tasks of making sure the motor is where and when it's supposed to be. ....via commands. I see nothing that will marry up Mach to these drives nor any way to create something that does (software/hardware).   

Hi,

Mach4 no longer uses the parallel port but some intermediate software they call a "plugin". While steppers are more of a digital device (step or don't), servos are analog (move this way, this fast, that far, let me know when your done).

Mach4 systems are an open loop Step/Dir control system.

Mach4 is the trajectory planner and posts numeric data describing the position of the controlled point in 1 millisecond time slices. That data is buffered by a motion controller.
In Mach's early days that was a parallel port, but these days an external motion control board is used, an Ethernet SmoothStepper for example. It is the motion controllers job to
turn the trajectory data into accurately timed pulse streams, very much analogous to the parallel port of old. Note that the plugin is the code written by the motion controller
manufacturer to adapt Mach4's output to the particular controller and provide firmware for the controller. Again note that the plugin is SPECIFIC to the particular CONTROLLER,
you cannot mix-and-match at will.

The step direction pulses are fed to the stepper drives or servo drives. I use Delta servos, the B2 series particularly, and they accept Step/Dir pulses and behave very much like steppers,
just on stereoids!

Yaskawa servos are very popular, and most models, not all, but most, have pulse control ie Step/Dir and so can be driven by Mach4 and a motion controller.

The servo itself is closed loop, but the loop is closed by the servo drive....not by Mach4/motion controller. That is what makes Mach4 an open loop system. Of course the servos faithfully
follow the commands of Mach4 and so the distinction is moot. If the servo cannot for whatever reason keep up the servo drive will error out 'following error' and signal Mach accordingly.

What you need to establish is if your particular servo drives can accept pulse inputs. There are Mach4 controllers that can close the loop and produce +10-10V analogue signals to the servo
if you wish to use torque or velocity mode....but cost extra and more complexity. I would be surprised if you COULD NOT drive the Yaskawa drives with pulse input.

Craig

Thank you Craig, that was put in a way that made sense to me. Unfortunately, my series of drives have no interface for pulse inputs. Yaskawa used something called MECHATROLINK that communicates over a form of RS485. My drives can also be controlled via a USB port using a program Yaskawa calls SigmaWinPlus but so far Yaskawa doesn't want to talk about that saying SigmaWinPlus is only for testing. Frustrating because I have it hooked up on my work bench and using that program my pc can make that servo do all kinds of cool tricks. It looks like it would take quite a bit on my part to add an RS485 interface to my pc and write code (a plugin) for Mach. So far, no response from ArtSoft about obtaining the SDK. Trying to reverse engineer the USB protocol even worse.

Hi,

It looks like it would take quite a bit on my part to add an RS485 interface to my pc and write code (a plugin) for Mach. So far, no response from ArtSoft about obtaining the SDK. Trying to reverse engineer the USB protocol even worse.

You're going off the deep-end there. Writing a plugin for Mach4 is not easy at best and you don't have the inside knowledge of the Yaskawa MECHATROLINK protocol, which is going
to make it even harder. Worse still is that the data comms over the RS485 link has to be in realtime, and your PC IS NOT A REALTIME DEVICE. Quite frankly you are on a 'hiding to nowhere'.

Some alternatives to consider:
1) Buy some Yaskawa drives THAT ARE pulse input capable
2) Buy matched servos and drives that are pulse capable, and that is the industry norm
3) Buy Yaskawa drive that are Ethercat capable, and then shell out more money to get the Mach4/Kingstar/Interval Zero Ethercat solution
4) Buy a Yaskawa MECHATROLINK  controller

The last option is going to be expensive and you become locked into Yashawa's proprietary protocol. Option 3) is likwise expensive requiring both new Ethercat drives AND a new PC loaded
with Kigstars/IntervalZero' s software, but at least you'd have an Ethercat solution, one of the industry standard protocols.

Options 1) and 2) are a toss up. Yaksawa gear is expensive so a new drive is likely to be nearly as costly as new Delta servo/drive/cables kit. The quality of Yaskawa it that good that its
probably worthwhile saving your existing servo motors....but then again how old are they and how much work have they already done? New Delta servos on the other hand are good quality,
shy maybe of Yaskawa, but still good, and they'd be 'crispy' new and set for twenty plus years service.

Craig

Hi,
at the beginning of this thread you posted:

Via Mechatrolink, Analog voltage and pulse train reference, and via USB connection

Does your servo drives not have 'pulse train reference'?

Craig

No, Craig. Unfortunately it does not. Yaskawa is acting rather stubborn on this issue. They want me to go out and purchase a "controller" that would manage the drives via the METCHATROLINK connections. 

It's looking like my best option is to sell the drives and replace them with the version that is pulse compatible. Pity, these drives are all over the place used and have lots of "brains" to them.

The MECHATROLINK route, I am surprised it's not been done already. The SDK route does not bother me as I have been a software developer for decades and supposedly, MECHATROLINK is open source.

You mentioned something that confused me (easy to do!). You state that "Mach4 is the trajectory planner and posts numeric data describing the position of the controlled point in 1 millisecond time slices." ....IE, timed. Granted any pc running winders can interrupt that timing at any time but given that an instruction set sent in that millisecond might be in the form "move X 3 steps and Y one" (with the expectation said move will be completed within that millisecond or instructions would be dropped.). This all implies "hand shaking" of some sort. The controller would need to send "complete" to Mach before another set of date is sent. An interruption at that point would not crash a machine. It would just wait for the next instruction.   Lots of interruptions would equal some really odd R2D2 noises when cutting a curve to say the least.  Given, that frequency is not adequate to mange the level of detail the motors require but it is plenty fast enough to send commands via MECHATROLINK or via plugin to some other controller and letting the servo drive handle the details I would think. I am only beginning to analyze MECHATROLINK so it may be more involved but the papers published about it suggest that is the concept behind it.