These should work better.
Here are a few videos of the machine cutting. The first shows the machine configuration from a distance. The second is cutting text. You can see the dwell I was talking about when cutting alot of arcs.
http://www.youtube.com/watch?v=iBO1SMwH7-g]VIDEO0039 - YouTube
http://www.youtube.com/watch?v=IdE26_JvRYE]VIDEO0041 - YouTube
The more complicated the letter the longer the pause?
Those graphs look pretty good. Max following error is less than 20 encoder counts for all 3 axes.
There is some limit cycle oscillation when sitting still of one encoder count particularly on the Y axis. See the attachment. Notice the encoder (red plot) is dithering by 1 count. If you find this annoying it can usually be eliminated by specifying a "Dead Band". Dead band can be used to tell the servo to reduce (or even consider as zero) any small error. There are two parameters for Dead Band - Range and Gain. The Range specifies how far from zero error the Dead Band should be applied. Specifying a value of 0 will cause Dead Band to be never applied. A typical value of 3 might be used so that when the error is less that 3 encoder counts it is applied. The Gain is the DeadBand factor to be applied to the error. Zero would tell the servo to ignore any error less than 3 counts completely. Or a Gain of 0.1 might be used to tell the servo to attempt to correct the error with an effort of 10% of normal. You will most likely have to play with the values for your system. You should realize that Dead Band will tend to make your system less accurate to a tiny degree so you should use the minimum necessary.
Your system could also benefit from a small amount of I gain. Notice in the attached plot that the axis is limit cycling 1 count but is also 3 count away from the target position (blue plot). I Gain would force this to zero sooner or later and never allow it to remain 3 counts away indefinitely. I gain will also help during the motion to apply the average output necessary to keep things moving rather than requiring some error to create the drive. I gain is very destabilizing so too much will quickly cause oscillation. Because it accumulates every servo sample (90us) it is usually a small value in the 0.001 to 0.0001 range.
I did notice a minor issue with your X encoder. It may be close to going bad. It looks like the AB quadrature signals that should be 90 degrees out of phase are more like 20 degrees out of phase. In the attached plot you can see the encoder changes in an irregular manner. Instead of even change is doesn't change for a while and then changes 2 counts rapidly. This also disturbs the servo as it thinks the axis is going slow, then fast, then slow, then fast. You can see this in the output (green). Probably not a big deal. Even a perfect encoder changes not at all and then suddenly one count so this is only twice as bad, but if the 20 degrees of phase goes down to zero it wont work at all so you should be aware of this.
Regarding the pauses. This is somewhat of a known issue and is caused by us flushing the USB buffer on each Rapid motion (G0). Then to start a new motion enough coordinated path needs to be downloaded to be sure any Windows stalls won't be a problem before motion can begin. How much Windows buffer time do you have specified in the Trajectory Planner Configuration. Reducing it to 1 or 2 seconds may be enough. If you get the dreaded "Unexpected buffer underflow" message then you have reduced it too much.
Also "Corner Rounding" can generate lots of tiny vectors if the "Facet Angle" parameter is set very small.
Another workaround is to change your GCode to use all coordinated motion Paths (all G1 G2 G3) without any Rapids (G0). In this case you can eliminate the pauses entirely. You may want to set high feed rates for the "rapids".
We are looking int a better solution.
Thanks a lot Tom. That sounds like things are moving in a good direction. I will set the dead band for 3 counts and adjust the I gain as you suggest. Also I removed that encoder and later put it back on so the problem might be my fault. I don't know if it can be adjusted to fix the problem. My circles and radius look terrible and I'm pretty sure it's because of backlash. When jogging the x axis in k-motion Cnc I set the step size to .001. It takes 32 thou before a change in direction in that axis starts. I'm not really sure what to do to compensate for this. I think I understand that the amount would be the number of encoder counts that equal 32 thou of motion. I do not know how to set the rate because I don't know what it relates to or how it is computed? I also am wondering about feed forward and if it would be helpful in my system? I would like to know what to set the Output to to equal 3 amps? Is this peak or continuous allowed current? I think I can set the error to 200 and that should be more then I really need? Thank you so much.
That seems like a lot of backlash. I wouldn't expect software backlash compensation to completely solve that. Backlash compensation requires that the backlash is consistent and there is enough friction to stay on the "correct side" of the backlash and the servo doesn't overshoot, etc, etc... But it is worth the try. The Rate value in KFLOP for backlash compensation is simply the linear rate that the backlash compensation is applied. The way backlash compensation works is that when the direction reverses the axis must quickly jump ahead to take out the backlash. If the rate is too slow then the machine path won't be corrected quickly enough and won't be correct. If it is too fast then it may cause a jerk and an overshoot. I don't think there is any method other than trial and error to find what works best. The rate is in encoder counts per second so for example if your backlash value is 100 counts and the rate is 1000 counts/sec the jump will happen over 0.1 seconds.
Regarding peak current it looks like you are already peaking at about 3.5A. See the attached current plot. You can't really set the current, but rather the servo will command whatever current is required to perform the motion you are commanding. So if you increase the acceleration the required current will increase. There is a Max Output setting to limit the peak current. If the motion requires more current than allowed, the current limit will result in the motion falling behind the trajectory, and a following error will result. I misstated the output range in an earlier email. The Current Command output is 11bits or +/-10bits or +/-1024 counts. So your Max output setting of 200 is 200/1024*35A = 6.8A. SnapAmp can drive up to 15A peak when driving 4 motors. You need to check what your motors will allow safely.
Thanks Tom that clears things up for me.
Alright this is a little off topic from this thread. I am fairly happy with performance and with a little tweaking I think I'll be fine. Now I would like to add home switches. The switches I have are standard lever activated no/nc type. I'm not sure what I need to do to connect them. Do I add +5v and ground then connect to a input or is this a bad way to do things. (basically I'm lost). I see all the inputs and outputs but don't know where power should come from. I will connect them through the 50 pin on the snap amp if I can. Also I need to create a c program for startup. I know I need to paste all the settings from the config screen into a program. Also I need to add the axis enable and coordinated motion setup for the axis I'm using. I would also like to tell it not allow the machine to run until I have homed the axis or if home is somehow lost. Last I would like to know if I can setup software limits so if a program commands a move that is outside of what I set as travel limits the machine will read an error and stop motion. This is to prevent hopefully ever hitting a real limit. Also as an extra protection for me until I add negative limits at a later time. Thanks.
Regarding Home Switches: SnapAmp has (8) 5-12V opto isolated inputs. So connect an OPTO_PLUS pin to the +12V supply and connect the respective OPTO_NEG pin to one end of your switch. Connect the other end of the switch to GND (the +12V return). Ideally use an separate isolated supply to avoid all the limit switch wiring from picking up noise and injecting it into KFLOP GND but it is not absolutely necessary to use a separate supply. See
Normally you would need to write a short C program to then Home. User Brad wrote a MasterHome program that might be helpful. By just specifying a few parameters for each axis describing the direction, speed, switch polarity, offset, etc... it should do the rest. I'd like to try it out.
Regarding Init C Program. Yes paste the axis settings, enable commands, and DefineCoordSystem command into the program. I'm not sure of a way to keep things from moving until you home. Maybe just don't enable the axes in the Init.c program but rather in the Home program, but if you are using Mach3 I don't think it will allow Homing until the axes are enabled.
We still need some work on soft limits. You can add a "watchdog" loop at the end of your Init program that will continue to run and watch the position. It can then set "virtual" limit bits which the Axis can then be configured to watch. Use the "Disallow Drive Into Limit" Limit switch mode. Something like the code below.
#define COUNTS_PER_MM 200.0
for ( ;; )
if (ch0->Position < 10.0 * COUNTS_PER_MM)
if (ch0->Position > 300.0 * COUNTS_PER_MM)
I am using the k-motion Cnc. Can I just put the enable axis and homing routine at the end of the init c program so it will home automatically at startup? Thanks.
A few other questions. Can the 5-12v supply and ground be used for more than one opto input? Can these be used to operate a relay to start my spindle and another to turn on motor power? do i need anything between the supply voltage and the opto plus like a resistor? Lastly should I put the snap amp voltage clamp and supply enables in my init c program and where should I locate it? Thanks.
Yes you can put the homing sequence at the end of your Init program if you wish. See the SimpleHome3Axis.c for an example of the code you might use.
Yes add the Voltage Clamp and Peak Current initialization to the Init program. Probably at the very beginning is best.
No the 8 opto inputs on SnapAmp are inputs only. To drive a relay you would need an output. SnapAmp and KFLOP have lots of GPIO that can be used but they are all 3.3V so you need something to convert or amplify the signals to drive a relay. Winford sells a small board that can do this. Another option is to use a 3V solid state relay.
The SnapAmp opto inputs have internal series resistance so you can apply upto 12V directly to them. And yes the same power supply can be used to drive multiple opto inputs. That just means that the optos won't be isolated from each other, but they will all still be isolated from the main KFLOP/SnapAmp/PC DC ground.
I have been thinking about soft limits. Is there a way to tell the control if the number of encoder counts in the positive direction is more than the total counts available for travel then to stop motion before the encoder reaches that maximum value. Likewise if a command will create a count of less then zero to stop motion before that happens. Thanks.