[nmorong]

Hi,

I’m starting the retrofit process of my 1995 Milltronics Partner 1 VMC control to a Kogna/Kmotion control. I’m also making a few modifications as part of the process. My goals are to end up with a more capable and reliable machine, and to understand it well enough that going forward I can improve and repair it easily without needing to source obsolete and expensive parts. I’ve attached an unfinished wiring diagram. Please excuse my terrible diagramming skills, this is not my strong suit. I still have a lot of stuff to figure out but I wanted to see if anyone points out anything wrong with the axis control and feedback portions of the project. There is a lot of stuff based on information from the original electrical schematics of the machine, and I expect to change some stuff as I go.

The machine had the Custom Servo Motors AC servo option, with a 12.5HP AC servo spindle and a max spindle speed of 4400RPM. In my opinion most of that horsepower is useless at that speed in a 4500LB machine, and I want more spindle speed. Most versions of this machine had a max spindle speed of 7500RPM, and I feel comfortable assuming that they didn’t make a special spindle for this option. I guess if I’m wrong I get to buy the spindle I want anyway. So I plan to make 2 custom poly vee belt pulleys that will fit in the head and allow 7500 RPM. I might make a Fadal style 2 belt speed change system. I’m still undecided on this point, I really am not sure I need the torque. I usually thread mill anything over ¼” anyway.

The only component other than the control that I really want to replace in this project is the spindle drive, I have had to repair it twice and it’s an expensive component that is no longer made. I think that the problems are the result of running it on a rotary phase converter. The spindle motor is a 12 lead wye parallel to wye series to delta switchable motor, with a system of contactors that switch the power leads for each configuration depending on the speed range. I reverse engineered the switching system in the hope of keeping the spindle motor, only to find out that the drive is also shifting the commutation signals from the resolver with the different speed ranges. I thought about a few kludgy solutions to emulate what the current drive is doing, but ended up deciding to just buy a new spindle motor. I found a 5.2kW Parker MPP AC servo motor and Parker Compax3 drive. This drive is actually a 480V drive that can run at 240V, so hopefully it will be more tolerant of my power supply. The smaller motor should be perfectly adequate for my needs, and I would be more comfortable running this machine and my big lathe simultaneously on the limited power in my shop. Hopefully I’ll be able to sell the motor, drive, and contactor setup and recoup some of my costs.

I ran into a bit of a stumbling block with the Parker servo drive, it turned out to not match the (Factory) label. The drive I have is actually the version with encoder feedback, not resolver feedback like my motor. So I could have tried to find a drive with resolver input, or a different motor. Both of those options looked more expensive than a $150 Pico Systems resolver-encoder converter, and the Compax3 servo drive manual explicitly states that it CAN commutate a motor with only encoder feedback. If this doesn’t work I’ll figure something else out. I can probably fit an encoder to the motor if I need to.

Motor Brakes: I got the servo motor for the spindle cheap without knowing everything about it, and was surprised to find out it is a braked motor. Not a big deal, it’s a 24V brake and I’ll connect the brake to +24V DC power directly. The motor contains a rectifier so the input polarity doesn’t matter and it shouldn’t need a diode across the leads. I suspect this is also the case for the Z axis motor because it’s based on a standard Parker motor as well, but I need to poke around to actually confirm this before I take things apart.

Encoders: I have all encoder outputs going to JP8. Axis drives simulated encoders: RS422 Output Drivers, 5v 20mA. Notation is A’, A, B’, B, Z’, Z. I have assumed that the Z’ (Index Pulse) signal can be connected to ground, and the Z signal connected to a 5v tolerant I/O pin on JP7.

Spindle drive simulated encoders: Less information here, but I believe the signals are also RS422 5v. Notation is A, A/, B, B/, N, N/. I see no use for the index pulse signal here, this encoder gives the spindle motor position which I do not expect to stay rigidly coupled to the spindle position (Belt driven spindle).

Spindle Encoder: It turns out my machine already has an encoder physically coupled to the spindle with a timing belt. I need to verify that the encoder actually present matches the wiring diagrams that I have. It should be a 500-count encoder with outputs labeled A+, A-, B+, B-, Marker +, Marker-. It has a +5V and a ground wire, so I am assuming an output of 5v or less. I want to use this encoder to position the spindle for tool changes. Rigid tapping small stuff would be a bonus, but I don’t need it.

MPG/Buttons: I want to keep the MPG on the front panel, along with some of the physical buttons. The MPG is apparently a 5V quadrature encoder. I also want physical knobs for axis select and step size. I am assuming that it won’t be too hard on the software end of things to treat 3 Kogna inputs as binary 1 or 0 and not have to run more than 3 signal wires for a 6 axis selector switch. I am also assuming that I’ll be able to have a momentary switch toggle an output to on or off in software.

Grounds: I am trying to avoid possible loops. Some of the grounds/commons on the drives are connected together internally, some are not. I am assuming that it doesn’t matter for the encoder index marker pulses if the Z’ signal is grounded at JP7 or at JP8. If it’s not OK, should I use 2 inputs for the Z and Z’ signals?

I am posting this to document what I’m doing and to see if anyone points out any technical mistakes I may be making before I find out the hard way. I do have some choices still to make that I am interested in feedback on though.

I have a nice, powerful CAD/CAM PC located right next to this machine. I have contemplated using it for Kmotion CNC with an additional monitor, keyboard and trackball mouse located on the machine. Alternately, I would buy a cheap micro form factor PC and install it in the enclosure that used to house a CRT monitor. I am having trouble deciding between the convenience of having all my files in one place and CAM at the machine, or the reliability of using a PC that isn’t connected to the internet. Either way, I will have a larger monitor mounted where the machine monitor is currently located. But I am also trying to decide if a touch screen would be a good idea. I know opinions on touch screens on CNC are divided, and I’ve never used a CNC with a touch screen.

So, in summary:

Did I make any stupid mistakes obvious to someone else so far?

Is the way I plan to connect the encoders Z index pulse correct?

Should I run KMotion CNC on my CAD/CAM PC, or buy another PC?

Should I get a touchscreen for it?

Thanks to anyone who takes the time to read this,

-Nate

[TomKerekes]

Hi Nate,

I also want physical knobs for axis select and step size. I am assuming that it won’t be too hard on the software end of things to treat 3 Kogna inputs as binary 1 or 0 and not have to run more than 3 signal wires for a 6 axis selector switch.

Encoding should work fine just change the MPG C Program to look for the codes instead of individual bits. However I don't think it is wired correctly. Kogna/KFLOP JP7 inputs are logic inputs with very high input impedance (meg Ohms) that need to be driven high and low. It looks like the selectors are just leaving the inputs open rather than driving them low. Also since they are low voltage and very fast they can be noise sensitive especially if wiring is long. Since you have a Konnect with a lot (32) opto isolated 5/12/24V inputs you might consider using those instead. They are basically like an LED so will turn off if left open.

I am also assuming that I’ll be able to have a momentary switch toggle an output to on or off in software.

Not sure what this means? An input? For MPG Enable?

I have assumed that the Z’ (Index Pulse) signal can be connected to ground

No, the complimentary signal drives high and low and shorting it to ground would not be good. Just leave it disconnected. Kogna has 24 differential inputs why not use any unused for the Z Index Pulses?

I am assuming that it doesn’t matter for the encoder index marker pulses if the Z’ signal is grounded at JP7 or at JP8. If it’s not OK, should I use 2 inputs for the Z and Z’ signals?

See above


HTH

[nmorong]

Thank you Tom! I really appreciate the help. I probably should have diagrammed out just one axis first, to make sure I wasn't as confused as I seem to be.

I can move the switch inputs to the Konnect, no problems there.

For the momentary toggle, let me use an example of what I have in mind. I want a physical button for flood coolant on/off. I want to use a momentary switch, where one press results in a bit or a variable changing state from OFF to ON. This ON state persists until another action (button press, or M9) changes it back to OFF. A program looks at the state of the bit or variable, and activates the output for the coolant pump relay if it is ON.

I am finding the encoders to be rather confusing. None of specifications for the encoder signals I'm working with give a simple graph of the signals produced for the electronically challenged like myself. I (apparently incorrectly) assumed that the Z high and Z low were only in reference to each other with no reference to ground, and that only connecting one end would be an open circuit. If I understand you correctly, I should use JP14 pins (25,26) (27,28) etc. for the Z index pulses.

I got the Pico Systems resolver-encoder converter today, and connected the motor to the drive. The drive was able to learn the commutation and rotate the motor during setup, but faults when I try to jog it in the drive setup software. Hopefully I just have some incorrect selection in the Parker software.

-Nate

[TomKerekes]

I am finding the encoders to be rather confusing. None of specifications for the encoder signals I'm working with give a simple graph of the signals produced for the electronically challenged like myself. I (apparently incorrectly) assumed that the Z high and Z low were only in reference to each other with no reference to ground, and that only connecting one end would be an open circuit. If I understand you correctly, I should use JP14 pins (25,26) (27,28) etc. for the Z index pulses.

You might read this. The Driver's + and - outputs basically switch from less than 0.4V to greater than 2.8V relative to its ground in a complementary manner. The receiver checks which signal is higher than the other to determine the state. The difference must be > 0.2V to set the state. The grounds between the Driver and Receiver should be connected together. As long as noise or ground currents don't cause the two GNDs to differ by more than 7V the proper state should be maintained.

HTH

[nmorong]

This is where my being electronically challenged is showing itself. I did read the document you linked before I created the wiring diagrams, I just ended up thinking that it meant only single ended signals were referenced to ground due to the portion quoted below.

"Differential signals have 4 signals called A+ A- B+ B-. This method is much better because there is basically no reference to any ground and so any noise or differences between grounds have no effect"

-Nate

[TomKerekes]

I did read the document you linked before I created the wiring diagrams, I just ended up thinking that it meant only single ended signals were referenced to ground due to the portion quoted below.

"Differential signals have 4 signals called A+ A- B+ B-. This method is much better because there is basically no reference to any ground and so any noise or differences between grounds have no effect"

Well we did say "basically"

[nmorong]

So I think I've fixed it, I now have the encoders channels A and B going to the differential inputs on JP8, and the index pulses going to the differential inputs on JP14.

All switches, drive OK circuits, etc. is 24V and going to the Konnect inputs. Nothing is using JP7 anymore.

I'm working on the Estop wiring now. My idea is to have a system where all outputs except the Estop output are powered by a single 24V supply, and the Estop switch will be in series with a NO relay controlled by a separately powered Konnect output. That way either a user program could open the Estop chain by turning off the NO relay, or the chain can be opened by the physical switch. When the Estop chain is opened, a Kogna/Konnect input changes state and a delay relay is activated. The goal is to have the result of hitting Estop be a controlled shutdown initiated by user program, followed by the delay relay deactivating the 24V power for all drive enable and relay outputs.

I believe it is safer to attempt a controlled stop, rather than simply cutting power and allowing the machine to coast to a stop. I also don't want the Estop to damage the machine by applying motor brakes at full speed, etc, unless the controlled shutdown fails. I don't believe there is a point in having the Estop cut AC power to the drives. The capacitor banks in the drives still have enough stored energy to continue any problem motion after cutting power anyway.

I'll share a simplified diagram when I have it fully figured out so everyone can tell me I'm wrong :-).

-Nate

[nmorong]

I've attached a diagram of what I've come up with for the physically wired part of the Estop system. All servo drive enable inputs are powered from the output of the delay relay, so when it opens all drives are disabled.

-Nate

[nmorong]

I'm still working on it. I can't seem to get the Compax3 drive with resolver-encoder converter to work for commutation, and I'm waiting on another servo drive. I've ordered and am waiting on most of the electronic components.

-Nate

[nmorong]

I gave up on the resolver to encoder converter, and got ahold of another Compax3 servo drive, this one is resolver based. I also bought a touchscreen monitor and micro form factor PC for this machine.

I also get to rebuild the spindle... yay!!! When I pulled the pulley off I could see corrosion and crap has gotten into the upper bearings. It still felt fine, but I doubt it would live long at the 7500RPM I have planned for it. This is much more within my skillset than electronics, fortunately.

I got a couple breakout boards for the IDC cables from the Kogna and made up a mounting plate. I also ripped out ALL the wiring from the electrical cabinet yesterday, so I'm getting close to starting to put stuff together.

-Nate

[nmorong]

Attached is the latest version of my wiring diagram (mess).

[nmorong]

I have everything wired up, basically per the last diagram. I fixed a couple minor things and changed a few things about grounding.

I also built a front panel and mounted the touchscreen monitor, switches, mpg, etc. In theory the electrical part of the retrofit is done less the spindle encoder, which has to wait until I rebuild the spindle.


I tried to connect the PC to the Kogna with the ethernet cable, no luck there. The connection kept switching between "connected" and "network cable unplugged". It was a huge PITA getting the cables through the conduit to the front panel, and I might have damaged it. Or maybe I really need to use a shielded ethernet cable, it does run next to 110v AC power for the front panel power. I'll order a replacement cable, and get back to it after I've rebuilt the spindle and made custom pulleys.

[nmorong]

Update:

The spindle is rebuilt and installed. The drawbar is rebuilt and installed. Custom pulleys built and installed. The ethernet connection between the PC and the Kogna seems to be fine after I connected by usb and manually set the IP addresses. I guess it was a DHCP thing?

I've tested most of the inputs and outputs, everything I've tested so far is working as planned. I'm leaving stuff like the tool changer and coolant pump for later. I spent all day today fighting with the spindle servo drive, but it seems to be working now that I figured out that not only does it need +24v applied to 5 different inputs, the inputs have to be applied in a sequence with a delay in between. Or at least that's the voodoo ritual I came up with that gets me a little green light and motion with a voltage applied to the analog input. Most of my initial wiring design was correct, but the I/O to the spindle servo drive has a lot of changes.

So I guess I'm ready to begin configuring the axes and tuning the servos.

[nmorong]

OK I have the axes servoing and holding position. I am attempting to tune the X axis now.

Question for Tom if you're still watching this: Do you recommend I change any of the tuning pots on the axis drives before tuning in Kmotion? They have response and gain pots, and I am wondering if I am working against the servo drives in my attempt to get this tuned.

I know (some of) the original performance specs of the machine, so I'm trying to work from that. With V set to 17062 (=100ipm, max feed rate for the machine) I have it stable with an error of ~40 encoder counts (~.0039").
This goes down to less than .001" at 10ipm. I've attached an error plot. The P gain started to make things unstable at 3.9 with a D gain of 20, so I backed it off and then started adding I gain. I gain didn't cause any instability up to .0072, but no improvements were seen past .0036 so I backed off to that.

But the axis runs away if I increase the velocity with these settings. Max rapid with the old control was 400ipm, so something is wrong. Any ideas on what I'm screwing up?

[nmorong]

OK, more confusion.

When things have gone unstable/ran away, I've been hitting the physical estop button, disconnecting the servo drive enable inputs from the +24v power supply. It's easier and faster than trying to click on a button in Kmotion. This stops motion regardless of what speed signal the drive receives. But when I just disable the axis in Kmotion, the corresponding DAC doesn't go to zero, causing continued motion. Not just drift, watching the analog screen it had several volts applied with the axis "disabled". I think what happened was that because I had set the max following error low enough that at higher speeds, the axis was disabled in Kmotion but didn't stop moving.

Is this normal behavior? Did I miss a configuration step where I was supposed to set the output enabling the servo drive to turn off when the axis is disabled in kmotion?

[nmorong]

So I've added the code from watchenable.c to my initialization file in progress. So the axis actually stops when disabled in kmotion. I still think something might not be right though with the DAC not going to zero with the axis disabled, but for now it behaves normally and I'm moving on.

It's not stable at rapid speed, and I guess I'm going to have to actually learn what I'm doing to figure out the servo tuning. I think I was trying to get the following error way lower than I needed to, and had it only marginally stable. I'll try to post an update if I get it working OK in the end.

[TomKerekes]

Hi Nate,

Sorry I somehow missed your earlier posts.

Question for Tom if you're still watching this: Do you recommend I change any of the tuning pots on the axis drives before tuning in Kmotion? They have response and gain pots, and I am wondering if I am working against the servo drives in my attempt to get this tuned.

Usually you should set the Gain Pot such that at 10V the system moves at a bit higher velocity than you will ever use. This allows use of the full DAC range for maximum resolution and reduces the effect of analog noise. Since ~300 DAC counts are required to go 100ipm then 1200 DAC counts should be required to go 400ipm. So the Gain could be reduced to be a bit closer to 2000. But this is not very critical, mainly the point is to not be just using a tiny portion of the DAC range,

I know (some of) the original performance specs of the machine, so I'm trying to work from that. With V set to 17062 (=100ipm, max feed rate for the machine) I have it stable with an error of ~40 encoder counts (~.0039").
This goes down to less than .001" at 10ipm. I've attached an error plot. The P gain started to make things unstable at 3.9 with a D gain of 20, so I backed it off and then started adding I gain. I gain didn't cause any instability up to .0072, but no improvements were seen past .0036 so I backed off to that.

Regarding the plot: Notice during the move the error is mostly constant at about 40 counts and the servo makes no attempt to correct it. The Integrator is the part of the Servo normally used to correct errors that persist over time. The 40 count error persists because the Integrator is limited to 200 DAC counts. To move at that velocity about 300 DAC counts of output are required. So after the Integrator maxes out the position lags behind far enough to generate an extra 100 counts of of output from the P gain. 40 counts of error x P Gain 3.4 ~ 120 counts. So increase the max limit integrator to around 400.

But the axis runs away if I increase the velocity with these settings. Max rapid with the old control was 400ipm, so something is wrong. Any ideas on what I'm screwing up?

Its not clear to me why it would be unstable at higher speed. Maybe the integrator going in and out of saturation. Note to go 400ipm the max integrator should be increased to ~1500 to account for the expected 1200 DAC counts for that speed.

When things have gone unstable/ran away, I've been hitting the physical estop button, disconnecting the servo drive enable inputs from the +24v power supply. It's easier and faster than trying to click on a button in Kmotion. This stops motion regardless of what speed signal the drive receives. But when I just disable the axis in Kmotion, the corresponding DAC doesn't go to zero, causing continued motion. Not just drift, watching the analog screen it had several volts applied with the axis "disabled". I think what happened was that because I had set the max following error low enough that at higher speeds, the axis was disabled in Kmotion but didn't stop moving.

Lowering the Max Following Error should disable the axis if it goes unstable or runs away so you shouldn't have to hit Estop,

The DAC should be commanded to 0 when disabled. The actual DAC Voltage might not be exactly zero (due to analog tolerances and noise) causing a small drift. But the commanded DAC value should be zero. Might you have an Output Offset set to a non-zero value? Is the axis actually disabled?

[nmorong]

Hi Tom,

Thanks for the reply,

I will try setting the gain on the drive to use as much as possible of the DAC range. 400ipm is only using 2/3 of the drive/motor combo maximum speed, and the drive allows adjusting the max speed command between +/-7v to +/-13v, so there is additional resolution to be had there.

That makes sense with the integrator gain. I should have realized what was happening when continuing to increase I gain had no additional effect.

I don't know if it was actually unstable, I had just screwed up and set the max following error to 250 counts. When I tried a faster speed, the following error exceeded 250 counts and Kmotion disabled the axis. However, the DAC did not go to zero, and the axis kept moving. So I thought it was unstable and running away. But now that I set the max following error higher, it doesn't run away but it is NOT mechanically happy at higher speeds. I think it has something to do with the motor being rather overpowered relative to the rigidity of the machine, and I probably need to reduce max acceleration.

I do not have a non zero output offset in Kmotion, I used the console screen to command the DAC to zero, then adjusted the zero offset pot on the drive until the motor wasn't moving (with the axis drive belts off).

When I look at the analog output screen, is this showing me a measured DAC voltage or only the commanded DAC voltage? In other words, if there is something other than the DAC causing a voltage to be present at the drive analog input, would it show up on the analog output screen?

I tried the following C code to tell me if the drive was disabled in kmotion, (may have errors, I am recreating here from memory) but I gave up because the console screen was filling up with an ever growing list of "X axis disabled!" messages, even when it was enabled and servoing. I don't understand why this didn't work, but when I used your code from watchenable.c to enable/disable the drive, it worked fine. Is the Kmotion axis actually constantly enabling/disabling at a very fast rate, or is there something wrong with my code?

for (;
{
WaitNextTimeSlice();
if (!ch0->Enable) // check if X axis is disabled in Kmotion
{
printf("X axis disabled! \n");
}
}

[TomKerekes]

Hi Nate,

When I look at the analog output screen, is this showing me a measured DAC voltage or only the commanded DAC voltage? In other words, if there is something other than the DAC causing a voltage to be present at the drive analog input, would it show up on the analog output screen?

This shows the commanded DAC voltage. It should be exactly 0 if the axis is disabled. If the offset pot has been adjusted for no motion when DAC 0 is commanded I don't understand why it would still be moving. Please check what the DAC is commanded and the actual voltage with a voltmeter. Maybe there is a grounding issue.

I tried the following C code to tell me if the drive was disabled in kmotion, (may have errors, I am recreating here from memory) but I gave up because the console screen was filling up with an ever growing list of "X axis disabled!" messages, even when it was enabled and servoing. I don't understand why this didn't work, but when I used your code from watchenable.c to enable/disable the drive, it worked fine. Is the Kmotion axis actually constantly enabling/disabling at a very fast rate, or is there something wrong with my code?

That program should print no messages when the axis is enabled and infinite messages when disabled. Once many messages are sent it may continue printing for quite some time regardless if more messages are printed or not. Change the code to only print when the axis changes to be disabled:

#include "KMotionDef.h"

void main(void)
{
    int NewEnable, LastEnable = ch0->Enable;

    for (;;)
    {
        WaitNextTimeSlice();
        NewEnable = ch0->Enable;
        if (!NewEnable && LastEnable)    // check if X axis changed to be disabled
        {
            printf("X axis disabled! \n");
        }
        LastEnable = NewEnable;
    }
}

Note the CNCZone # code tags can be used to make code more readable.

Note you can also observe the enabled state on the KMotion Axis Screen

[nmorong]

Hi Tom,

I appreciate the help, that makes sense that it would create a backlog of axis disabled messages. I didn't think of that. I will try your code shortly.

I've attached an image of the screen showing the axis disabled, but the DAC at -3.517v. More than fast enough to be a little scary. I set the max following error back to 250 counts and reproduced the axis "runaway" on video, but the video is too large to attach here. I can email it or find somewhere to upload it if it's helpful.

I think I will try a C program to command the DAC to 0 when the axis disables in Kmotion. If this doesn't stop or nearly stop the axis I'll take the drive belt off so I can poke around with a voltmeter while it's "running away"

-Nate