Jump to content
OMRON Forums

Issue with Linear axis


Raghav

Recommended Posts

Dear All,

I'm facing a weird problem with my linear axis. While I run a set of G-code it works fine and at times I face fatal following error of one of the axis and runs away. Since as a safety feature, we kill all the axis if there is an error. The following is the code which I ran

 

G01 X10 F20.0

G01 Z1 F20.0

G01 X-.5 F50

 

So after X moves to 10, Z starts to Z->1 and motion gets completed without error but sometimes there is a fatal following error in Z axis and machine axis trips. I'm not sure of why and what causes this issue. To add some more details about the machine, we have a 5nm, 20um scale encoder.

 

Maximum velocity Ixx16 is set to 6000 and max. acc. Ixx17 is set to 20. Also I set a point as 0,0,0 using PSET before running the above code.

 

I tried to run the axis at a feedrate of even 300mm/min and haven't faced this issue. But only with the above code, i face this issue randomly. Kindly let me know where I could have made a mistake?

Link to comment
Share on other sites

  • Replies 13
  • Created
  • Last Reply

Top Posters In This Topic

Are both X and Z axis part of the FRAX (feedrate axis)?

What are your TA and TS settings?

 

Dear Sina,

Yes both the axis are in Feedrate axis mode. We just mention LINEAR for G01 inside the PROG N1000. Neither TA nor TS is specified in the motion program. Default feedrate which we mentioned in the NC code is 20mm/min.

 

Isx20=40

Isx13=5

Isx87=0

Ixx16=6000

Ixx17=20

 

These are the values set in the PMAC. we don't specify TA and TS in our NC code. So what would be the reason for the sudden random motion. Also all the axes servo was cut off after this error. The only thing i could notice is that, the Z axis had an fatal following error in motor status. How to over come this issue? Also while i make a Jog move, the axis tends to move further more even after I remove pressing of the Jog + or Jog -. This happens in both PEWinPro and also our custom GUI. Will this be related to the random motion? Looking for your valuable reply. Thank you.

Link to comment
Share on other sites

From my experience, the most common reason for "occasional" fatal following error problems is that the fatal following error limit is set to a value that is close to what the normal following error is for the condition under which the problem happens. Since there is some variability in the following error from time to time it occasional exceeds this value. How did you decide what value to set your fatal following error limit to? It certainly needs to be set to a value larger than your typical following error. I don't know anything about your machine or what you are trying to accomplish, but it sounds like a machine tool of some sort. An easy way to look at "typical" following error would be for you to program the machine to make a continuous circular path (which creates constant acceleration) and then monitor the following error somehow. The simplest way is to use PEWIN and just look at a watch window while a PMAC motion program runs. Your machine should tolerate an acceleration of 0.1g, i.e. approximately 1000 mm/sec^2. Given that I don't know what the upper speed limit is for your high resolution system, if you program a small radius you get this acceleration at a modest speed. For example, you should be able to do continuous circles at 32mm/second with a 1mm radius. This is slightly greater than 0.1g. Now take a look at the peak following error and make sure that fatal following error limit is set higher than this by a margin of at least 2 if not more. These are engineering judgments that require more information than you have given. If you have no way of monitoring the following error, then you can do it blind by making the fatal limit smaller and smaller until it trips every single time and then increase it by some multiple that gives you margin. If the fatal limit seems to you to be set really high to make this test work at all then you undoubtedly have unrealistic acceleration limits set. You can look at the DAC output during these moves and make sure it is not saturated, which would indicate you are pushing the machine too hard. A fatal limit should be set large enough that any disturbance that the control system can compensate for will not trip the system -or- at a level that is so much larger than the typical following error that it clearly indicates a problem.
Link to comment
Share on other sites

How big is the lookahead buffer defined for this coordinate system? It is necessary to make sure the lookahead buffer is large enough for Isx20 setting and defined after the axis definition in order to support all of the axis in the coordinate system.

Dear Sina,

I haven't set any Lookahead buffer for the machine. In this case what shall I try out in order to avoid this random error?

Link to comment
Share on other sites

I agree that this could be a tuning or system limits issue. Can I assume that the Z axis is vertical? Does it have a brake?

 

Hi,

The tuning is tight and repeatable. The system motion is smooth without much friction as well. It is a horizontal axis without any brakes.

Link to comment
Share on other sites

From my experience, the most common reason for "occasional" fatal following error problems is that the fatal following error limit is set to a value that is close to what the normal following error is for the condition under which the problem happens. Since there is some variability in the following error from time to time it occasional exceeds this value. How did you decide what value to set your fatal following error limit to? It certainly needs to be set to a value larger than your typical following error. I don't know anything about your machine or what you are trying to accomplish, but it sounds like a machine tool of some sort. An easy way to look at "typical" following error would be for you to program the machine to make a continuous circular path (which creates constant acceleration) and then monitor the following error somehow. The simplest way is to use PEWIN and just look at a watch window while a PMAC motion program runs. Your machine should tolerate an acceleration of 0.1g, i.e. approximately 1000 mm/sec^2. Given that I don't know what the upper speed limit is for your high resolution system, if you program a small radius you get this acceleration at a modest speed. For example, you should be able to do continuous circles at 32mm/second with a 1mm radius. This is slightly greater than 0.1g. Now take a look at the peak following error and make sure that fatal following error limit is set higher than this by a margin of at least 2 if not more. These are engineering judgments that require more information than you have given. If you have no way of monitoring the following error, then you can do it blind by making the fatal limit smaller and smaller until it trips every single time and then increase it by some multiple that gives you margin. If the fatal limit seems to you to be set really high to make this test work at all then you undoubtedly have unrealistic acceleration limits set. You can look at the DAC output during these moves and make sure it is not saturated, which would indicate you are pushing the machine too hard. A fatal limit should be set large enough that any disturbance that the control system can compensate for will not trip the system -or- at a level that is so much larger than the typical following error that it clearly indicates a problem.

 

Hi Brain,

Thank you so much for your effort. I have not changed the Warning following error and the Fatal following error value from the DEFAULT value. I'm afraid that, I'm not sure of how to compute these values. Currently for our system, we have set the F.F error to be 160 microns and warning to be half of it. Since ours is a nanometer resolution machine, our following error cannot go more than few hundred nanometers. Currently, the following error is limited to lesser than +/-5cts. I'm now worried about the acceleration values which would have caused this random error. So I would like to check on this as I had changed the motion to segmentation motion by setting Isx13 to 5 and Isx20 to 40 based on the given calculations. the Ixx17 is set to 20 which provides me 100mm/sec^2 acceleration which is 0.01g. Will this be an issue? And the Isx87 was 1. Since I was not sure of the cause of this error, I changed it to 100. I'm still not able to understand whether my values are correct or I need to modify them. Thank you once again for the suggestion and I shall try to run the circular motion test. Hope you could suggest some more suggestions based on the information provided.

Link to comment
Share on other sites

You say that you are using the default value of fatal limit (Ixx11) is 32,000/16 = 2000 counts. If your resolution is 5 nanometers then your fatal limit is 10 microns. Yet you also say that you set it for 160 microns, which would mean that Ixx11 is set to 512,000. Which is it?

 

Also, you say that the following error is limited to +/- 5cts. I assume that this is with the slides standing still. This does not mean that it is 5 counts during hard acceleration. For example, if you did a step input test of 50,000 counts it would probably complete this test just fine ~ and the max following error during the test would be 50,000 counts. Then, by definition, if you did the same test with the ixx11 variable set to default of 2000 cts, it would fail.

 

My point is that the fatal limit should not be set based on how you would like the machine to perform, i.e. "a few hundred nanometers" (you could use the warning limit for that), but rather it should be set to disable energy to the slide if a condition occurs that the servo system can not stabilize, i.e. drive starts to saturate with large input, system behaves badly and oscillates, or some other unsafe condition such as excessive force occurs. In fact, under most circumstances if a large following error happens, but the machine is able to recover and remain stable, then you do not want the servo loop to trip, you want it to recover.

 

Study the following error during typical motions and set the ixx11 appropriately.

Link to comment
Share on other sites

You say that you are using the default value of fatal limit (Ixx11) is 32,000/16 = 2000 counts. If your resolution is 5 nanometers then your fatal limit is 10 microns. Yet you also say that you set it for 160 microns, which would mean that Ixx11 is set to 512,000. Which is it?

 

Also, you say that the following error is limited to +/- 5cts. I assume that this is with the slides standing still. This does not mean that it is 5 counts during hard acceleration. For example, if you did a step input test of 50,000 counts it would probably complete this test just fine ~ and the max following error during the test would be 50,000 counts. Then, by definition, if you did the same test with the ixx11 variable set to default of 2000 cts, it would fail.

 

My point is that the fatal limit should not be set based on how you would like the machine to perform, i.e. "a few hundred nanometers" (you could use the warning limit for that), but rather it should be set to disable energy to the slide if a condition occurs that the servo system can not stabilize, i.e. drive starts to saturate with large input, system behaves badly and oscillates, or some other unsafe condition such as excessive force occurs. In fact, under most circumstances if a large following error happens, but the machine is able to recover and remain stable, then you do not want the servo loop to trip, you want it to recover.

 

Study the following error during typical motions and set the ixx11 appropriately.

 

Dear Brian,

I'm not able to understand the above comment. I had set the wrong FF warning and error. I forgot to note the units while sending you the previous reply. I just left the FF with the default value. I'm not sure of how to define the FF warning and error for our machine. Since the machine has very low friction acting on it, I'm not able to decide on the values. I just want to avoid the sudden oscillating motion of the axis as I would lead to severe conditions. Also my JOG command doesn't decelerate immediately once a J/ command is sent. I'm not sure whether its a machine issue or the PC communication issue. Also I'm confused whether FF and JOG mode error caused due to the same setting issue. Kindly help me to overcome this issue. Thanks in advance.

Link to comment
Share on other sites

Note that the parabolic trajectory move in our Tuning software is a great tool for identifying steady state following error issues.

 

Dear Mr.Steve,

I used the Parabolic test and found the error is within the counts of 0 to 15. Can this value be useful to identify the machine state?

Link to comment
Share on other sites

It sounds like you have many adjustments to make. I am assuming that this is an air bearing, linear motor machine, or something similar. I recommend the following:

 

1. Tune the servo to get a good step response and a good parabolic response. Make sure the DAC output limits are set for your motor/amp combination.

2. Set your fatal limits Ixx11 on the linear axes to the equivalent of 100 microns, i.e. 320000.

3. Set your Ixx19 to the equivalent to 2000 m/sec^2. Jog the axes forward and backward while looking at following error and DAC output. If the following error is much smaller than 20,000 you could either increase Ixx19 (harder acceleration) or decrease Ixx11 (smaller fatal limit). You want a ratio of fatal limit to peak following error of at least 2 to 1, maybe 4 to 1. At the same time, if the DAC is near its peak limit, you may need to reduce acceleration to get some safety margin.

4. Once you are happy with Ixx19, copy this same value into Ixx15 and Ixx17.

5. Set Ixx16 for your largest expected programmed velocity. This might be limited by a number of hardware or process requirements.

6. Set Ixx20 to zero and set Ixx21 so that you get a peak acceleration that is similar to what you ended up with previously, maybe 2000 mm/sec^2 for your largest velocity that you just set.

7. Test jogging, aborts, and programmed moves. It fatal limit is still tripping from time to time, lower your acceleration values until it stop. If it is still tripping, and you feel that the acceleration is low, then you may have a hardware problem, i.e. an occasional problem with feedback or motor, but I doubt it.

 

I have oversimplified everything here, but this will probably give you a starting point. Remember, the PMAC is a computer. It has no idea about the physics of the machine. You need to analyze what the machine is physically capable of and program that into the controller. MOST OF THE DEFAULTS WERE SET UP FOR LOW RESOLUTION, LEAD SCREW DRIVEN MACHINES. They won't necessarily be correct for your system, or even close for that matter.

 

Once you get things working better you may have to go back and change some of these settings. Please appreciate that I have no idea what your machine is, so these are very basic suggestions.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.

×
×
  • Create New...