[nmorong]

OK, So I tried your code for printing an error message to the console only when the axis state changes to disabled. This works as expected.

I then added the following into the for loop with the print line. It compiles but does nothing to the DAC output. Maybe I'm misusing the DAC command, but nothing I've tried in a C program has any effect on the DAC output.

DAC(8,0);

After further experimentation, I have realized that the voltage is remaining at the last commanded DAC voltage when the axis is disabled. For example a move of 30000 counts results in a remaining DAC voltage of -3.517V, and a move of -30000 counts with the same settings results in a remaining DAC voltage of +3.517V. If I use a console command I can reset the DAC output to zero and re-enable the axis and it doesn't move.

[TomKerekes]

Hi Nate,

You are correct there is a bug where the Kogna DAC is not being zeroed on disable. We will fix this in the next release. A work around would be to add:

	        KOGNA_DAC(0, 0);

in your Drive enable/disable code.

If the Drive is being enabled/disabled when the Axis is being enabled/disabled I wouldn't think it would matter what the DAC is when the drive is disabled.

[nmorong]

Thank you Tom.

Glad to hear I'm not going crazy. And you are correct that as long as I have the drive enabled/disabled with the axis, it doesn't matter. But in case I do something stupid, like take stuff apart and get the X and Y drive enable wires crossed putting it back together, I will feel better adding the code to zero the DAC.

-Nate

[nmorong]

Now that the axis is behaving as expected, I started over trying to tune it.

I have been unable to find settings where it seems happy with both a 400ipm rapid and a low following error. I care a lot more about accuracy than speed, so I started shooting for a max speed of 300ipm but with as little error as possible at 100ipm and under.

I played with the PID settings, then filters, then added some velocity feed forward. The attached error plot is my worst test of various speeds and move sizes. I was also testing with and without a ~100lb chunk of granite on the table.

I expected the bandwidth to be higher in the bode plot, but if I'm understand it correctly my 0 crossover is about 20hz, and phase margin is about 30-35 degrees. I am doubting the usefulness of the bode plot here, because I had to increase the amplitude a lot to get a time plot where the steps in position aren't too big. But from what I think I have it looks OK.

Unless I get some feedback that I'm totally wrong and it's going to be unstable, I plan to move on to trying to tune the Y and Z axes tomorrow.

-Nate

[nmorong]

So I'm stuck here. I got the Y axis to where I'm happy with it, but the Z is stumping me.

The Z axis on this machine is fairly heavy, and does not have a counterweight. It servos and moves OK, but at the start of every move there is a spike in position error of at least 60 counts (~.006"). There is a visible and audible jerk as the motor jerks in the opposite direction of the motion commanded. It sounds worse in the upward direction, but I think this is due to backlash. The Z axis does have a little (maybe .001") backlash. This jerk doesn't occur where the move commanded from the step response screen reverses, only at the moment motion begins.

Any thoughts? I've tried a bunch of different gain adjustments and nothing seemed to make a difference. I also tried setting the max integrator very low, also to no effect. The motor behaves normally when disconnected from the load.

[nmorong]

Well now I feel dumb. I realized that the axis is momentarily disabling before each move, and the move is starting from a position that deviates from the commanded position by however much the axis has dropped during the moment it was disabled. So I can ignore this error, as it won't be present under normal circumstances.

[TomKerekes]

Hi Nate,

Looking good.

I have been unable to find settings where it seems happy with both a 400ipm rapid and a low following error.

I see about 1700 DAC counts are required to do 300ipm. So 400ipm would be 1700 * 400/300 = 2267 is more than the DAC range of 2047. So I think you will need to change the Amplifier Gain to be able to go 400ipm. Also the max output is 2048. This should be set set to 2047. 2048 wraps around (is actually -2048) and can cause big problems.

[nmorong]

I adjusted the amplifiers (Amplifier manual called it Cal Speed) to use as much of the DAC range as possible after I gave up on the 400ipm rapids. I might be overly cautious, but I never liked how the machine sounded stopping at the end of long rapid moves when it was stock anyway. I may go back and try to tune for higher speed if I end up dissatisfied in the future, but for now I think I'm happy as long as it stays stable.

I'm making a big fat assumption that the acceleration units in the original machine parameters were in in/s^2, but if that's the case I have it accelerating faster than stock in both X and Y, which is probably a real world performance increase even with the lower rapids. I think the assumption is probably correct, because I ended up right at what I assume is stock for the Z, and the X and Y have the same motors and don't have to work against gravity.

Thanks for warning me about the max output, I can see how that's a big problem if it wraps around! I'll change that.

[TomKerekes]

Hi Nate,

I adjusted the amplifiers (Amplifier manual called it Cal Speed) to use as much of the DAC range as possible after I gave up on the 400ipm rapids. I might be overly cautious, but I never liked how the machine sounded stopping at the end of long rapid moves when it was stock anyway. I may go back and try to tune for higher speed if I end up dissatisfied in the future, but for now I think I'm happy as long as it stays stable.

ok. Note: rapids are performed with 3rd order limited Jerk, so can be quite smooth even with higher velocities and accelerations. So if you re-visit this try lower values of Jerk.

[nmorong]

I did the run-in on the rebuilt spindle and set up the limit switches and soft limits in Kmotion. I have the 3 motion axes homing and played around with configuring them in KmotionCNC and everything appears to be working.

I still need to set up the spindle as a servo axis, for now it runs at the full range of speeds when I command a DAC voltage from the console but immediately faults when I try to get it to servo as a Kmotion axis. I'm pretty sure I just need to figure out the drive tuning in the Parker software. Then on to the the MPG, front panel buttons, toolchanger, etc.

[nmorong]

I got distracted with the mechanical side of things again. I decided to take EVERYTHING apart for a deep clean. Including the ballnuts and the linear guide trucks. What a PITA. Then I decided to replace the linear guides. So that's kept me busy for the moment.

The spindle now works just fine as a Kmotion axis, I was dealing with a safety feature of the servo drive. The drive won't re-enable until it gets a second, delayed, "yes I really want to re-enable the drive" signal. I had to adjust my code so that the drive enable bit is not cleared until after a .1 second delay when the Kmotion axis disables, so that the momentary axis disable before motion from the step/response screen doesn't disable the drive.

On to the toolchanger. I'm trying to decide how I want to orient the spindle. I could set up the spindle encoder as an axis with no output, and use the encoder index pulse as a home, then command a move that puts me in the oriented position. OR, I can activate the orient roller and jog until it drops into place, disable the drive so the roller and the servo aren't fighting each other, and re-enable the drive after the tool change is complete.

The second method seems like a better option to me, because I have a proximity switch that gives me a way to mechanically confirm the the spindle is oriented correctly before proceeding with the tool change. It also doesn't require that I reset the orient position if I take the spindle encoder belt off or change speeds. (The spindle encoder is directly coupled to the spindle with a timing belt, this is a different encoder than my spindle drive axis, which is using the simulated encoder from my spindle servo drive. There is a poly-vee belt between them, with 2 different speed ranges)

I guess I need to confirm if KmotionCNC will handle the spindle motor axis disabling/re-enabling gracefully while running a program.

[nmorong]

Well I have everything working... I think. All my buttons work, the toolchanger works, and the mpg works. I'm sure my C programs are embarrassingly kludgey to someone who actually know what they're doing, but they work. I may need to revisit servo tuning to try to reduce the dithering between encoder counts if surface finishes aren't as good as I'm hoping. I have very little backlash now that I've redone everything, and I can see the table moving bath and forth about a micron at rest using a micron indicator. If this doesn't cause a bad surface finish I'll leave it alone.

Now I need to figure out a fusion360 post and make some test parts to see if everything is OK.