You should try the setting the tolerance at .0001, (.001 & .0005) are to big for this setting
I'm having a stalling problem. I've tried a lot of things to solve it, and no luck, so I'm looking for some ideas. I have a 3 axis mill (Acer knee mill CNC conversion), Galil DMC-1842, DC Servo motors, and Camsoft Pro v16.7.
The machine stalls in the middle of running a CNC program. By stall, I mean Camsoft completes a move and then ceases to execute further moves, and it stops, leaving the spindle running. No error or reason why. I hit ESC, tell it to back up to the last command, it goes back one G code block, then I tell it to continue, and it works from there (until it stalls again at some later block).
The problem is 100% repeatable - i.e. the given G-code program will always stall at the same point. No single G-code command will cause it. It takes a series of commands to happen. E.g a series of arc moves with a Z component, or an X/Y move after an Arc move. Yet these moves by themselves never cause the issue. I can also single step through the offending section of code and it does fine.
That's important. It seems if there is a slight delay from one G-code block to the next, the problem goes away, or improves significantly.
Here's what I have tried:
TOLERANCE - If I increase TOLERANCE, it improves the issue (less stalling), but doesn't make it go away. TOLERANCE is normally set to 0.0005. I have increased it to 0.010, but it doesn't make it 100% disappear. Larger values cause other problems which are expected like odd arc moves.
I also thought bad servo tuning, but I can program back and forth X, Y, or Z moves all day long and never encounter the issue. So I don't think it's tolerance, or bad servo tuning.
I may be wrong, but before I go further, I wanted to ask if there is something I'm missing. Has anyone else seen this problem? The telling part is that everything works if there is a delay between commands like single step, or in a couple cases I used a momentary pause and was able to make it go away.
You should try the setting the tolerance at .0001, (.001 & .0005) are to big for this setting
I remember this problem on my large lathe six years ago. My memory is a bit foggy but it was caused by a poor combination of TOLERANCE BLEND and POSERROR commands. I do remember Earnie (Camsoft tech) walked me right through it. it took several trials to make the machine do my bidding. Here's some reading for you:
Are there any other settings to increase performance and accuracy of the machine?
Yes, the ADJUST.FIL file will provide a method to set an error correction factor at different places along the ball screw. Just enter the position in the ADJUST.FIL file at which point to do an offset correction and an equal sign followed by the value. You can also use the VOLUME.FIL file. This file is much like the ADJUST.FIL file in the sense that it will look up positions in the VOLUME.FIL file based on a user-defined table along the X and Y axes. This file is designed for 3-axis machine tool types using X, Y and Z-axis positioning. The principle function is to look up a position along either the X and Y axis and apply the Z position in the look-up table to the current Z-axis position to compensate in 3D for the bow or curve in the table. The NEXTMOVE= setting in the CNCSETUP.EXE program tells the control to issue the next motion target position to the motion card when the table arrives within the amount specified after the NEXTMOVE= setting. However, the table will not move until it has finally reached the target position. The need for this setting is to get the target position ready for the next move. Once it is issued, the G code display changes on the screen to the next move. A value too big causes the G code display to show the next move prematurely and a value too small can cause the machine to stop and dwell for a few milliseconds on each move. Another command that affects when the table moves to the next position is the BLEND= setting in the CNCSETUP.EXE program. This is a time value not based on any reference value. This can be set to a negative number to cause the machine to start the next move before it gets to the target position issued. Not all motion cards use the blend setting. (See the motion card integration documentation.) There is no stable advice on what to set this value at. It is our advice that you decrease the value negatively until the test part is within tolerance and all jerkiness is removed from motion. Please call the motion card manufacturer directly if you have problems with any jerkiness or rough unstable motion. There are many factors and issues to get advice on. There is a tolerance setting in the CNCSETUP.EXE program called TOLERANCE=. This setting will set the system wide tolerance and the axes display readouts to the desired decimal precision. There is a system wide tolerance value to set under the LOCK Icon in the CAD/CAM system, which affects the G code program and drawing independently from the controller.
What would cause my motors to turn off and lock up the table while executing my G code program?
This is caused by an excessive position error. When the commanded position varies from the actual position, as reported by the encoders, that is greater than the TOLERANCE you specified in the CNCSETUP program, then that motor will automatically turn off or go limp. This is a safety issue that will keep the motors from running away or stop the machine from undue stress while trying to move the table against an immovable object or travel with too much resistance. You can either increase your tolerance size or search for the cause of the resistance or possible binding. You can also temporarily override this safety feature for diagnostic purposes only with the POSERROR logic command. The answer may be as simple as:
The ball screw is binding at a certain place along that axis.
The ACCEL or DECEL values are too steep for the weight and load on your machine causing too much stress on the motors. Just lower the ACCEL or DECEL settings in the CNCSETUP program to make more gradual feedrate transitions.
Your servo motors need to be better tuned. Inefficient servo tuning will cause the motors not to perform to the maximum ability.
Your TOLERANCE setting may need to be higher than what it is.
Use the Test Axis motion feature in the Diagnostic window. Check the box entitled Coordinated Move / Error Checking to have the controller tell you what is wrong.
What are the differences between POSERROR and TOLERANCE?
The TOLERANCE sets the overall tolerance factor the controller uses to satisfy motion positioning and math functions internally. When the control reads the current axes positions to see if the commanded position has been reached, it must satisfy the given target position within this tolerance before it goes onto the next move.
The POSERROR command turns on or off excessive position error checking and allows you to optionally set the tolerance for excessive error. If during travel any of the coordinated axes fall outside this tolerance for more than 60 milliseconds, the motors automatically will be shut down.
The POSERROR gets its information from the tolerance setting and then internally the system sets the POSERROR to 10 times the tolerance for the allowable following error in encoder counts only. For example, let's say that the tolerance setting is set to .001. If 40 encoder counts = .001 for tolerance, then 10 times 40 = 400 encoder counts for position error. This is what is being allowed for the following error (400 counts).
Now the tolerance setting by itself with or without the POSERROR will wait for the system to be within tolerance of .001 before it will issue the next G code position to continue on to the next move. Therefore, if the machine never gets to the commanded position within the tolerance setting, then it should not issue the next line of code and hang up until it is within tolerance.
You can override the POSERROR, which is turned on by default, and increase the following error to allow for spongy like performance and/or bad servo tuning so the machine can lag behind the default 10 times tolerance setting. However, the control will still not issue the next command until the machine has reached the target position within the tolerance setting.
I hadn't considered POSERROR. That should help diagnose things. I have played with TOLERANCE and improved things with a large TOLERANCE (e.g. 0.005), but did not get rid of the problem.
My encoders are rotary encoders on the servo motors, not linear scales on the bed. So, there are no issues with ball screw or table inaccuracy with respect to this problem. The Camsoft system can't see this inaccuracy. When it stalls, it occurs in no particular location on the axis, but instead as a result of certain moves. Again, G02/03 X.. Y.. Z.. moves are the worst. But, I've seen G01 X.. Y.. moves that follow an Arc move having problems as well.
I've never had the problem when moving a single axis - ever. I did a test on X, Y, and Z independently, moving back and forth with different feed rates and distances. Ran it long enough to find the issue if it was going to. No stalls.
It sounds like I'm on the right track. I need to spend more time checking my servo tuning, and messing with ACCEL, DECEL, etc.
But, how should I proceed to tune my servos? I'd like to use the Galil tools (their nice "scope" application), but if I install the Galil tools, it will install the Galil driver and screw up the Camsoft driver from what I understand. Should I just do that, and then re-install Camsoft afterwards to re-install the correct driver? The Camsoft Diagnose function doesn't have anything like the Galil tools. Or am I missing something.
AND, it will not install on top of Camsoft. I've had a truely awful time getting both softwares on the same computer but it can be done. My method: wipe the harddisk, install OS (I use XP SP1), install Galil, install Camsoft, install IO card drivers. ONCE its running: CLONE the disk at least twice so you never have to do it again.
Getting your control computer to run Galil, Camsoft, IO drivers is the hardest part of doing a Camsoft refit. The last two Camsoft upgrades went in without a hitch but I have had to start at the beginning to upgrade. For some reason, if you have the old 1700 Galil cards its dang near impossilbe. I've talked with both Camsoft and Galil. They both agree - its the other vendor's problem.
Ha, that's what I figured. FYI, I have a Galil DMC-1842 (the econo series 4 axis PCI based card).
I'll install the Galil tools on a spare hard disk and tune with it, then swap back to the Camsoft disk when done. Actually, I've been wanting a non-Camsoft bootable system anyway to try some other software. So, when I'm done, I'll probably leave the system multi-boot with the two disks installed, or make two partitions on the same disk using my cloning/partition management software.
Thanks for the help.
I (mostly) resolved my stalling issues. It was just servo tuning (bad servo board settings and bad Galil PID values).
My DC Servo boards were adjusted to output only 10A torque when they are capable of driving 25A max. My motors are 45A (X and Y axis) and 65A (Z), so I set the servo board gain to allow 25A at max torque (just shy of 25A actually to prevent clipping). That made a big difference. At 10A, the motors were underpowered for the machine.
For the PID values, I put a second hard disk in the system and set it up for multi-boot, installed GalilTools and used it to tune the PID values using their scope function. Wow, huge difference. Under Camsoft, it no longer stalls with a TOLERANCE of 0.0005", and with TOLERANCE at 0.0001" it is only stalling for certain high feed rate and rapid moves. I have a little more work to do in GalilTools. With the GalilTools' scope function, I can see exactly where the problem is and tune it out.
Fixing the servo tuning also solved several other problems. Lots of issues with the jog wheel for example. Fortunately, it also finally revealed the real issue I've been trying to solve - a Z axis cumulative error during X, Y, Z arc moves. I'll explain that in a different thread.
Thanks again for your help guys!