Mach3 Retrofit to 1989 CNC Lathe

[jim_cliff11]

Hi Tom, yet again thanks for your reply. Your help has been invaluable!

I've cracked on well today. All 3 axis (X,Z and spindle) are now configured in the config / flash screen after loading KanalogInitialPID.mot and setting subsequent channels. I then went on to start tuning via the step response screen with the following results:

Chan1 - Increased the P-Gain, adjusted velocity, acceleration and jerk.

Servo motor sounded like it was vibrating unhealthily. Also what would cause the resulting dither in the green command output plot? Surely this isn't good?

Chan 1 - Having dropped the P-Gain down slightly I got the following plot:

Which looked and sounded much better.

Any thoughts Tom? Both the X axis (chan1) and Y axis (chan2) are now set identically in terms of step response. Both give very similar plots. When enabled and zero'd both fluctuate by 2-3 encoder codes which is good enough for me!


Not as much luck with the spindle.
When zero'd using standard settings (0.2p gain) the spindle juddered backwards / forwards violently.
http://81.138.85.180/~jim_cliff11/20...O-00000028.mp4

And gave me the following step response plot:

I increased the gain to 1 very briefly, but the intensity and speed of the judder motion was concerning.

Dropping the P gain down to 0.05 reduced the intensity of the judder to a safe level
http://81.138.85.180/~jim_cliff11/20...O-00000029.mp4

And gave me the following poor results:


I found a page on Dynomotion referring to the setup of an open loop DAC axis to control spindle. I'm guessing if I configured the spindle this way without encoder feedback I wouldn't have the judder issue. Realistically this isn't a viable option as it's essential I have encoder feedback on the spindle for threading (the majority of my work). What would be the best way of producing a healthy step response plot (if its even needed for spindle control), eliminating the judder, yet maintaining closed loop encoder feedback?

Thanks once again

[TomKerekes]

Hi Jim,

Regarding:

Plot #1 - Yes unstable. Reduce Gain or otherwise tune to make stable

Plot #2 - Reasonable. Some comments:

Only using 100 DAC counts output (100/2047 = %5 of Amplifier capability)

Zoom in or Plot Error to see amount of following error.

Consider adding I Gain to reduce following error. You might read this:
https://www.cnczone.com/forums/dynom...ml#post2131108

Jerk, Acceleration, and move size too small to achieve max Velocity.

You might read this article
Dynomotion


Plot #3 - Yes unstable. Reduce Gains or otherwise tune to make stable

Plot #4 - Spindle control is likely to be slow and poor at low speed. But it should still be possible to control closed loop with proper tuning.

Seems stable at that P Gain but Output is extremely limited to 10 DAC counts.(0.5% of full output). See this Post/Thread for an explanation:
https://www.cnczone.com/forums/dynom...ml#post2128860

I think the Step Response Screen is still a good tool to tune and understand the Spindle Control. But Servo type control when stopped causing dither and such can probably be avoided in normal operation by disabling the Spindle. So I wouldn't be too concerned about it at this point. Adding some Deadband might stop it.

HTH
Regards

[jim_cliff11]

Thanks Tom,

The link you posted to the Dynomotion wiki page explains the tuning process in depth! I'm surprised I missed that article. Either way, it makes a lot of sense, so I'll have another go on Monday. Some of the values shown on that page for velocity, acceleration and jerk are much higher than the values I used in the screenshots. I'll increase the step size to give the servo's more room to push for optimum values.

In terms of P-gain, what is the maximum value that can be used? I know the higher the value the lower the following error, but this also leads to drive instability. When I'm putting in a max P of 1.5 and hearing the servo vibrate or sound unhealthy, I then drop it right down out of fear of damaging something. I've seen on some threads people using Kanalog have tried gains of 5+.

Taking all the above into account I guess I'm just worried about damaging a drive or servo. Is there a risk of this or would the drive just trip?

Moving on to the spindle for example, if I increase P-gain to say 3, would I be right in thinking dither / judder amplitude would reduce but frequency increase? Potentially this movement would then be unnoticeable. But is there any risk of damaging the drive changing these values?

Like you say I could avoid the judder by disabling the spindle axis, but then I get drift which causes the axis to spin slowly until it's enabled. Neither are ideal. I'd rather have the judder unnoticeable when spindle enabled, without risk to the drive.

Thanks

[TomKerekes]

Hi Jim,

In terms of P-gain, what is the maximum value that can be used? I know the higher the value the lower the following error, but this also leads to drive instability. When I'm putting in a max P of 1.5 and hearing the servo vibrate or sound unhealthy, I then drop it right down out of fear of damaging something. I've seen on some threads people using Kanalog have tried gains of 5+.

There are many factors that determine overall loop gain. Encoder Resolution, Amplifier Gain, Motor Torque Constant, Gearing, Mass, etc... So every system is different. The idea is to have as high of gains as possible and still have a good margin of stability. But some parameters like D Gain or lead compensation can add damping, slow the system down, make it more stable, then possibly allow other Gains to be allowed to go higher.

You might reduce the Max Following Error. In that case if something goes wrong the Axis should be quickly disabled before things get too violent.

Moving on to the spindle for example, if I increase P-gain to say 3, would I be right in thinking dither / judder amplitude would reduce but frequency increase? Potentially this movement would then be unnoticeable

Probably not in this case. If the system was stable at higher gains the dither might be smaller and higher frequency. But it would likely be unstable. Its hard to say why the performance is poor. It could be that the amplifier response is very slow. There might be a delay when switching directions. Or something non-linear at low speed. If you get the Spindle tuned as best as possible the plots should tell you what is happening.

Like you say I could avoid the judder by disabling the spindle axis, but then I get drift which causes the axis to spin slowly until it's enabled. Neither are ideal. I'd rather have the judder unnoticeable when spindle enabled, without risk to the drive.

Normally when a Drive is completely disabled there shouldn't be any drift. Maybe you are confusing commanding an Analog Speed of zero which is likely to have some drift.

With low enough gains you should be able to have the corrections gradual enough to hold a position. Unless the amplifier has some quirk where it has a jump in speed around the zero crossing.

Regards

[jim_cliff11]

The Z axis is the only one I've had good results with so far today. I've reduced velocity by 30% of max and have found a good acceleration and jerk value. The servo responds well, sits at commanded 0 with little fluctuation in encoder counts and hums nicely. All sounds smooth.

http://81.138.85.180/~jim_cliff11/080418/Z.mp4




X on the other hand. The command and actual values come out well with P = 6. But the servo sounds horrendous. Vibrating rapidly when at commanded 0 (enabled), I can actually feel the vibrations through the machine. The only way to eliminate this vibration and have a smooth sounding servo is reducing the P to 1. But then I'm using 200DAC counts and have poor command and position plots. In the video below, right at the end when I disable the axis you can grasp just how bad the vibration had been.

http://81.138.85.180/~jim_cliff11/080418/X.mp4




The Spindle is just a nightmare. Smoke was coming from the motor or the belt before, so the whole thing isn't doing it good. You were right Tom, increasing the gain has no effect. The spindle "judder" is now more like a yoyo at commanded 0. Amplitude starts off high with a low frequency, then each time it switches direction the amplitude gets higher, the frequency lower. Sort of a like a reverse pendulum effect. When the drive is disabled, it slowly rotates. When it is enabled @ commanded 0 that's when I get the judder. See below:

http://81.138.85.180/~jim_cliff11/080418/Spindle1.mp4



I feel like I'm wrong in treating the spindle like the Z or X axis, wrong when trying to get similar results and wrong with the encoder input somehow. It doesn't have to be accurate like the actual axis, just give me an RPM reading and provide basic feedback for threading. The required function of the spindle is completely different from that of the axis. And as such, I don't know what results to expect in the step response when setting a spindle up with encoder feedback. What should a good step response plot look like for a closed loop spindle? Also would it be worth changing the input channel to read just the Z pulse (1 pulse per rev)? And not the A and B channels?

Had enough today, the spindle is annoying me and I cant loose the X vibration. Can you make any sense of all this Tom?

Thanks

[TomKerekes]

Hi Jim,

I see progress. But I think you are still missing a basic concept. With simple P only Gain the output will be limited to:

Output = Error x P

I think you understand that to go faster you need more output to keep up. If you cant keep up with your selected speed you should realize you have basically 3 options:

1 - slow down
2 - increase P Gain
3 - increase max limit error.

You seem to be aware of #1 and #2 but missing #3.

Our first choice to get more Output to move faster is to increase P Gain. However if the system is unstable or the increase will make the system unstable that is not an option. So we might consider increasing max limit error. In fact if the system is already unstable we may need to decrease P gain significantly and then much increase max limit error to be able to go the desired speed. Please read:
Dynomotion

On a side note: once the Position is following the Command well (red and blue plots overlap), the Command + Position Plot is not very useful. So include an Error Plot so we can see how well things are following.

Here are some comments:

Z Axis
Looks reasonable but might be borderline unstable. You might reduce P somewhat to see if the oscillation on the output reduces. As stated above you may need to increase the max error limit.

Only slightly more than 1/2 the Output range is being used (1100 of 2047 counts). You can probably get higher speeds if you wish.

X Axis
Similar to Z but more unstable and clipping at 1200 DAC counts due to the max limits error x P gain limit as describe above. Reduce P Gain and increase max error limit for a more stable system that can move faster.

Spindle
Totally unstable. Reduce P Gain dramatically and increase max limits error to a huge value to achieve a stable system. ie P = 0.01 or whatever is necessary to achieve stability. We need to have a working stable system first regardless of how slow and low performance to then understand things and try pushing in different directions. It may be that the Spindle Amplifier is more like a Torque Amplifier than a Velocity Amplifier. You might read this:
Dynomotion

I wouldn't give up on driving the Spindle Closed Loop yet. No matter how slow, delayed, poor the Spindle response is, there should be some tuning that works with it. It may be nothing like a Servo Axis but it should still work. It may be that all that works is extremely low gains that results in the equivalent of you watching the encoder RPM and gradually turning a knob to gradually increase the speed until the speed is correct.

HTH
Regards

[jim_cliff11]

Brilliant reply Tom, the max error limit makes much more sense now and I can see how it plays a critical part in the tuning. I’ll do some more reading and try to get my head around it a little better. I’ll have another go tomorrow night and keep you posted with my results.

By the way Tom I can’t tell you how much I appreciate your help and support. It is second to none.

Apologies for my consistent questions. But when this is done I hope to share my circuit diagram and knowledge with others.

I’ve also just bought a 6 tonne mill with 40 ATC which I’ll be retrofitting later this year with Kanalog if I can get this lathe right.

Thanks again

[jim_cliff11]

Opened up early this morning so I could have an hours play.
Adjusting the max error limits and dropping P I've got the following results:

X step response:


Dropped the P down to 1.5 which reduced the oscillation massively. I then increased error to 100,000 counts, and dropped it down until velocity was effected. Eventually settling at 1500 counts. I'm only using 1200 DAC bits max, so just over half of amp capabilities, but velocity is perfect for the lathe, the servo plot looks stable and servo oscillation is massively reduced.

Z step response:


Dropped P down to 3 and eventually ended up with a 600 error count which seems well enough. I'm only using half the amp capacity @ 1100 DAC bits, but again the drive sounds healthy and I don't need any more velocity. What do you think about the two above error plots Tom? Is there any reason why I have to use the full 2047 DAC bits? If the drives respond well, and error count is minimal I'd be quite happy sitting at 50%. What do you think.

Spindle step response:


Video @ http://81.138.85.180/~jim_cliff11/09...O-00000008.mp4

Reduced the P right down to 0.01 and increased until it became unstable. Settled with 0.07 which left me with a very slight, but gentle oscillation at commanded 0. Increasing error to 100,000 counts made a big difference, and I managed to reduce this to 12,000 counts. The command position and output plot above shows a MASSIVE improvement between between command and actual positioning. Any more than 100,000 counts/sec velocity caused the spindle to oscillate 2 or 3 times before dampening itself out at commanded 0. It'll be interesting to see what this equates to in RPM. Again only using 700 DAC bits, but by far I'm getting the best results yet with the above settings, so I might have to live with it. Unless theres any other tuning routes I can go down? Any thoughts overall Tom?



Not 100% sure how to perceive the above error plot, so I'll do some more reading tonight. Does it look reasonable though?

I've a link below to the spindle drive if it helps. I'm fairly sure it's speed control.

https://www.boschrexroth.com/country...KDA03_PRJ1.pdf
https://www.boschrexroth.com/country...IAX01_ANW1.pdf

Thanks,
Jim

[TomKerekes]

Hi Jim,

By the way Tom I can’t tell you how much I appreciate your help and support. It is second to none.

Thanks. You don't know how much I appreciate your patience and attitude. Maybe you could post a review on our site.

What do you think about the two above error plots Tom?

X and Z look good for only having P gain.

Is there any reason why I have to use the full 2047 DAC bits? If the drives respond well, and error count is minimal I'd be quite happy sitting at 50%. What do you think.

If you don't want to use full speed then that is fine. There is no need to allow it or tune for it.

The X and Z errors are probably still too large to get good machining results. You should determine your axes resolution so you can relate the 700 count error to a real distance. See:
Dynomotion

Then the next step might be to add I Gain to reduce the amount of errors. See:
Dynomotion

Reduced the P right down to 0.01 and increased until it became unstable. Settled with 0.07 which left me with a very slight, but gentle oscillation at commanded 0. Increasing error to 100,000 counts made a big difference, and I managed to reduce this to 12,000 counts. The command position and output plot above shows a MASSIVE improvement between between command and actual positioning. Any more than 100,000 counts/sec velocity caused the spindle to oscillate 2 or 3 times before dampening itself out at commanded 0. It'll be interesting to see what this equates to in RPM. Again only using 700 DAC bits, but by far I'm getting the best results yet with the above settings, so I might have to live with it. Unless theres any other tuning routes I can go down? Any thoughts overall Tom?

Regarding Spindle. What you have may work fine. There is a large error of 10000 counts. But with a spindle you may not care. Probably more important for a Spindle is how it reacts to sudden load changes (cutting forces).

Regarding DAC range/usage. Again it depends on your requirements. If you don't ever need higher RPM then there is no need to allow it or tune for it

Do you know how many encoder counts per Rev the Spindle has? If you determine that you can determine the RPM.

You might make a tiny size move, or even zero to investigate any dither you have. You may be able to get rid of it with Deadband.

Regards

[jim_cliff11]

Thanks tom,

I’ll calculate the resolution tomorrow and see how it pans out. I’m sure I can fine tune the axis more so to reduce the error count some more.

My worry at the moment is the spindle. The encoder is 1024CPR which will equate to 4,096 in total. Does that mean that with an error of 10,000 counts the spindle is roughly 1 turn out of sync? If so, that will mean that basically I can’t cut threads with the current setup I presume? As Kanalog doesn’t have an accurate position on the spindle?

Cutting force wise I’ll just have to try it, but with a gain that small is there a possibility the spindle will just stall as I sink the tool in?

[TomKerekes]

Hi Jim,

My worry at the moment is the spindle. The encoder is 1024CPR which will equate to 4,096 in total. Does that mean that with an error of 10,000 counts the spindle is roughly 1 turn out of sync? If so, that will mean that basically I can’t cut threads with the current setup I presume? As Kanalog doesn’t have an accurate position on the spindle?

Actually 2 turns behind I believe. But no, cutting Threads is based on the encoder measurement of where the Spindle actually is. The commanded position and error is basically irrelevant.

Cutting force wise I’ll just have to try it, but with a gain that small is there a possibility the spindle will just stall as I sink the tool in?

I don't think so. The Amplifier should do a reasonable job of maintaining speed (besides the momentum). Think of it like having a speed control potentiometer to the Amp to set the RPM. But if for whatever reason the speed does start to slow down KFLOP will adjust the Pot until the speed becomes correct.

Regards

[jim_cliff11]

Hi Jim,

Actually 2 turns behind I believe. But no, cutting Threads is based on the encoder measurement of where the Spindle actually is. The commanded position and error is basically irrelevant.

Ahh ok I see. Sorry for the back to basics questions. So what your saying is; regardless of where the commanded value of the spindle is, and how high the error count is.... as long as Kanalog is receiving the actual spindle encoder position (which it is) then it will know when to pickup the thread cut in sync with the previous pass?

If there is a drop in spindle rpm during a cut then the Z axis will back off to maintain the correct thread pitch?

Is the above correct?

Moving forwards I need to some how accurately measure the ball screw pitch to calculate the resolution. Or strap a set of 1m digital vernier to the bed to get a distance reading and equate this back to encoder counts. Any tips on the best method for this?

Many thanks once again Tom

[TomKerekes]

Hi Jim,

Yes. See this recent video.


I’m not sure the best way to calibrate. Basically move a large distance and number of counts. Somehow measure the distance moved. Divide.

Regards

[jim_cliff11]

Hi Tom,

X & Z encoders are 2500 x 4 = 10,000 counts / rev. Given both ball screws have a pitch of 10mm. I've calculated my axis resolution as 1,000 encoder counts / mm (25,400 counts/inch).

Going back to the step response, I've had to reduce my velocity for Z axis (longitudinal), which has lowered the error amount to an acceptable(ish) region of 80 counts (0.08mm). However my DAC number of bits is now 750, although I can live with this if that's the best I'll get. I'd rather have accuracy over speed.



Velocity for X axis (traverse) has also had to be reduced, but I'm not happy with the error count still, which comes in at 180 (0.18mm). I really need to refine this to below 0.08mm ideally. However, I can't increase P above 1.6 because the servo becomes unstable. This leaves my only option as reducing velocity which in turn drops the DAC bit count to just 500. I can't understand why I can increase P so much higher on Z without instability! If I'm forced to live with max P @ 1.6 is there anything else I can to bring the error count down?



Regarding the spindle, I've haven't tuned it anymore to be honest. I think the results posted previously are the best I can get for the time being. I can always look at re-tuning later on. Spindle encoder count is 1024 x 4 = 4,096 counts / rev. Does Mach3 auto calculate the RPM or do I need to include a script for that?

Thanks again

[TomKerekes]

Hi Jim,

I wouldn't start slowing things down yet. P Gain is only one of several things that can be used to reduce the errors. BTW with only P Gain there will always be significant error. This is because the output is simply Output = P x Error. In order to have a big output to move at high speed there must be some Error.

It looks like your system might be only borderline stable. You might reduce P gain some. Then put your Velocities higher, unless you really don't want high speeds.

As I said in the previous email the next thing would be to add I Gain. See:
Dynomotion

Velocity Feed Forward is another option. That basically tells the servo if it is being commanded to move at a certain speed, then the Amplifier will likely need this nominal amount of Output, so immediately add it in so no error is required to create the motion.

HTH
Regards

[jim_cliff11]

Ok, I’ll resort back to my previous settings and have more of a play with P, I and velocity feed forward. My error count on both axis are much lower with higher P, but obviously instability is a huge issue. Hopefully I-gain and v feed forward will yield me better results.

While I work on this I’ve begun configuring mach3turn and have a few questions to keep me going:

1. When enabling axis in Mach3 (in my case X and Z), how does mach know which axis relates to which channel in KMotion?

2. When tuning axis in Mach3 I’m guessing I need to convert from counts to distance for velocity and acceleration eg. 10,000 cnt/10mm = 1000 cnt/mm. velocity (60,000 cnts/sec in KMotion) into Mach3 therefore = 60,000*0.001(mm/1cnt)=60mm(per sec)*60(seconds)= 3600mm/min. Acceleration (200,000 cnts/sec in KMotion) into Mach3 therefore = 200,000*0.001= 200mm/sec2?

3. Do I set the spindle up in Mach3 as spindle in the tuning config? Again, how does Mach3 know “spindle” relates to Chan0 in KMotion? Also when mach asks for steps per mm in the spindle tuning screen, is this actually meant as steps per revolution?

I’ve been following information in https://www.dynomotion.com/Help/Mach3Plugin/Mach3.htm

But can’t find the answers to the Q’s above. I have my basic init file configured containing the settings for each drive. This is enabled on pressing the reset button in Mach3.

Thanks

[TomKerekes]

Hi Jim,

When enabling axis in Mach3 (in my case X and Z), how does mach know which axis relates to which channel in KMotion?

Mach3 doesn't really need to know. KFLOP does. See the reference below in the link you listed:

Besides C code to configure each axis, other commands such as those shown highlighted below may be used to enable each axis (and set the destination) and to define which axis channels are in the coordinated motion system. The DefineCoordSystem(0,1,-1,-1); statement defines a two axis coordinate system where X is axis channel 0, Y is axis channel 1, and the Z and A axes are not used.

When tuning axis in Mach3 I’m guessing I need to convert from counts to distance for velocity and acceleration eg. 10,000 cnt/10mm = 1000 cnt/mm. velocity (60,000 cnts/sec in KMotion) into Mach3 therefore = 60,000*0.001(mm/1cnt)=60mm(per sec)*60(seconds)= 3600mm/min. Acceleration (200,000 cnts/sec in KMotion) into Mach3 therefore = 200,000*0.001= 200mm/sec2?

Yes I believe that is correct.

Do I set the spindle up in Mach3 as spindle in the tuning config? Again, how does Mach3 know “spindle” relates to Chan0 in KMotion? Also when mach asks for steps per mm in the spindle tuning screen, is this actually meant as steps per revolution?

Again Mach3 doesn't really need to know such things. Mach3 just tells our Plugin to run at such an RPM and so forth and the Plugin and KFLOP handle things from there. Since your Spindle should be controllable like an axis by issuing Jog commands to the Axis you should be able to use the SpindleMach3Jog.c example. Modify it to use the Axis you are using in your system.

#define SPINDLE_AXIS 4 // axis set up as Spindle, possibly Step/Dir or Servo

See the reference below in the link you listed:

Mach3 generates Spindle Messages for On, Off, and Speed Changes. Specify a KMotion Spindle Speed User Program to handle and perform appropriate actions for the various Mach3 Spindle Messages. A default SpindleMach3.c program is included in the default installation that will simply print the messages and desired speeds requested by Mach3. Note that speed is a relative fraction of the max currently selected pulley's speed. Because KFlop/KMotion is likely to be controlling the motor speed regardless of the selected pulley, this is usually more appropriate. An appropriate User Program to perform the appropriate actions to actually drive the spindle should be created to replace the default program that simply prints the requested operation. There are included examples for Spindles controlled by a DAC output (SpindleMach3DAC.c) and for Spindles controlled by Step/Dir outputs (SpindleMach3Jog.c).

HTH
Regards

[jim_cliff11]

I owe you an apology Tom!

I was jumping at getting Mach3 setup too soon, instead of spending time fine tuning the servo motors. Besides there is plenty of help and information regarding Kanalog / Mach3 setup, and if I'd looked hard enough I probably would have found it. So again, apologies for wasting your time.

I did a little more reading last night and had another go tuning tonight. Below are the results from the X axis:



I've added a small amount of I to eliminate the consistent error. This has had a huge effect. Also dropping acceleration to keep up with error and adding feed forward velocity has improved the plot. Judging from the two plots above, I get an initial 75 count increase in error before the servo catches up and corrects it. Once up to speed the error has a range of about 6 counts (0.006mm). Would you say this is reasonable or is there more tuning I can do to reduce the dither / fluctuating error count? Also what would be the best way to reduce the initial increase in counts (or is that an inherent function of any servo system)?

Regarding the Z axis:



Similar sort of results to the X to be honest. That initial increase in error count followed by a fluctuation / dither of around 10 counts. Is this good enough or should I tune further?


On another quick note; would you recommend mach3turn or KmotionCNC for my requirements? I know in the early days of KmotionCNC, mach had better functionality. But these days I'm not so sure. The mach config is on hold until I get the tuning right and look into KmotionCNC properly.


Once again, your help has proven priceless!!
Thanks

[TomKerekes]

Hi Jim,

No worries. Just wanted to point out that the info was there.

I think those results are probably usable. It is unlikely for you to be cutting metal at those speeds and while accelerating.

But I would expect you to be able to do better. You didn't describe how you came up with those values. I would have expected higher Velocity Feed Forward. For example I see that to move at 90000 counts per second the Output required to g that fast is ~100 DAC Counts. So the Velocity Feed Forward to do this would be 1100/90000 = 0.0122. But you have 0.008. btw its usually best to eliminate I Gain while tuning Feed Forwards. You might re-read PeterTheWolf's Thread. He has videos showing how he worked through tuning things.
https://www.cnczone.com/forums/dynom...ml#post2131028

To have optimal performance you should also come up with two different sets of motion profile parameters. One for cutting and one for rapid moves. See:
https://www.cnczone.com/forums/dynom...ml#post2133822

Once you get all the axes working it should be fairly easy to run either Mach3 or KMotionCNC. We think you will get better performance with KMotionCNC. A number of Lathe Users report success. But KMotionCNC is lacking the setup wizards that Mach3 has.

HTH
Regards

[jim_cliff11]

Hi Tom,

To be honest the FFV value was just trial and error. I didn't take it much higher in fear of causing instability. I have however tried your value of 0.0122 for the Z axis and funnily enough calculated the same value for X. This value gave me the following step result plots:

Z:


X:


Both axis are now giving me a max following error of about 16 counts, which to seems minimal. I feel like I'm going to be unable to smooth out the dither anymore because of stiction / external forces etc. I've increased I-gain slightly to try and pull the error down further, but I don't thin the system would benefit from increasing I anymore.

What are your thoughts?

I've also settled on KmotionCNC for my controller. I've generated my initial startup perimeter file from the axis calibrations, and defined my axis accordingly. As you know the spindle is operating from a closed loop (encoder feedback) DAC axis, but I haven't defined this is the DefineCoordSystem command. Axis velocities / acceleration and counts so far have been loaded into tools, trajectory etc for Z and X. I can now successfully JOG my axis using the on-screen arrow buttons!!

I've setup spindle control as described here: https://dynomotion.com/Help/KMotionC...dleControl.htm
And adjusted MySpindleDefs.h accordingly.

I can now control my spindle CW and CCW using the KmotionCNC spindle controls!! It also shows the RPM reading! When I click 'On CW' the spindle rotates CCW if I am looking straight at it. Vice versa for clicking 'On CCW'. I'm guessing the view is that I should be looking from behind the spindle? I do however feel the spindle will take more tuning as at low speed it will judder as if it's not to sure where it's supposed to be.

At the bottom of the init file I have adjusted and added the following for spindle threading control, which I'm hoping will work.

    
DefineCoordSystem(1,-1,2,-1);
ConfigureSpindle(1,0,0.1,0.1,4096.0);

I need to try various G-code to test threading CSS etc. My problem now is with KmotionCNC. When I try to manually execute G-code I get the error below. This also applies to loading in complete G-code from the samples and trying to run:



Can you shed any light on this Tom?

Another thing, I need to add to my initialization file the following IF or case statements for the safety circuit. But in honesty I'm not to sure how to implement this into the file, or where abouts:

IF OPTO 0 (bit 136) = LOW then disable SW7
IF OPTO 1 (bit 137) = LOW then disable SW7
IF OPTO 2 (bit 138) = LOW then disable SW7
IF OPTO 3 (bit 139) = LOW then disable SW7

I suppose I could do:

IF ALL (the above) bits = HIGH then enable SW7, else SW7 = LOW?

I'll do some more reading tonight on C code. But if you can point me in the right direction on where to place this code in the init file that would be spot on!

As always, thanks Tom! Things are progressing