tahoe brian

Another way of asking the question...what causes the line cursor on the display (which indicates the currently executing line) to scroll to the next line?

Thanks Steve, correct me if I am wrong, but setting the M variable on will get the G code to display as "active". My problem is that the block execution area of the UI, where the completed lines turn yellow, current line turns red, etc., doesn't step through line by line. Sometimes it jumps several lines, sometimes it seems to work. I notice it more in Auto mode than MDI. I would like this display to step through line by line. my high-level code looks like: G61.1X_Z_A_B_ G61.1X_Z_A_B_ G61.1X_Z_A_B_ . . . G61.1X_Z_A_B_ etc., Are we talking about the same thing?

Perhaps this is not an issue in the latest version of NC, but I just wrote a User G-Code (G61.1) running in an NC 2.36 environment. The G-Code executes just fine. It is essentially a one-line canned cycle. The problem is getting the UI to properly display line execution in AUTO mode. I have a program that runs many lines, each line is the custom G-code and the parameters that get passed. The UI doesn't step through line by line in the display (i.e. doesn't highlight completed lines and current line properly). Sometimes it stalls and randomly jumps forward. The program itself executes just fine, it is simply a UI problem. I recall having to do something with M165, but I don't remember and don't know where to find it. Anyone have a fix?

I believe that the syntax (assuming you have line numbers) is OPEN FWD CALL 12.238

Raghav: perhaps if you post the axis definition statements for each axis, the code snippet that doesn't work, and a brief description of the machine geometry and specifically what you observe when you run the snippet, then we can help solve the problem. My guess is that there is some geometric violation.

Curt, assuming that the U axis definition is correct, shouldn't it work OK as long as the FRAX command arguments are limited to 3 orthogonal axes? For example, if the U axis is parallel to X and he wants to move and control speed in U,Y,Z space, then FRAX(U,Y,Z) followed by motion with the F feedrate command should work, correct? I do agree that four orthogonal axes would require transcending into different universe.

So, what specifically is the symptom of your problem?

OK, I understand now. It is not clear what your issue is with FRAX. First of all, what have you done about axis definition. You mention motor 4 and U axis. Have you defined the axis, i.e. #4->scale factor U+offset? (for example #4->2000U, where 2000 counts would equal one user position unit. Without an axis definition, or a correct one, things won't work if it is FRAX axis

If I am still following this thread properly, you have created an open loop spindle. You created a means of using the jog command to set velocity, but you have no position loop. Thus, you have no way of controlling the position of this spindle. It sounds like you were hoping to fool the PMAC into thinking it was doing position control by making the jog command control velocity. These are not the same thing. If you want to do position control you need to have a real position feedback. If you want to simulate position control you need to at least simulate position feedback.

ScottB, not directly related to the topic, but can you share the thinking used to develop your maximum jerk specification?

I am not directly answering your question, but S-curve acceleration is "constant-jerk" acceleration. If you set TA=0 and hence control accel with pure TS, then you control jerk by controlling TS. Sound reasonable?

Jeff, have you actually looked at the difference in the estimated velocity versus the actual velocity (assuming perfect encoder)?. I.e. perfect encoder would estimate velocity as deltaTheta/deltaT and the actual encoder would estimate it as (deltaTheta+errorTheta)/deltaT. It would surprise me that this would make a significant difference unless the encoder was terrible. This is because the error from count to count grows smaller and smaller as the resolution goes up. My hunch is that the effect of time and space quantization of the position signal once put through the difference equation is just as bad as the ripple due to the noise in position. If you have data on this it would be interesting to see.

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.

Is it possible that you have a wiring problem? Try doing the test with I330 set to zero. Also, what happens if you issue an "O" command. For example, what voltage do you get with an O10? In looking at your I variables, you have the DAC output address something that is not typical for Motor 3 (which doesn't make it wrong, but you need to make sure you are measuring the output on the correct DAC). I believe you have it pointing to an ACC24 card, is this correct?

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.

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.

The only ways that the DAC saturates using the method provided by Steve Milici are as follows: 1. If Ixx33 (integral gain) is non-zero. This needs to be set to zero to use this technique, as do all of the gains Ixx31...Ixx39 My guess is that THIS is the reason that Steve's technique did not work for you 2. If the DAC offset registers Ixx29 and/or Ixx79 are set to some large non-zero number. Set these to zero 3. If you improperly scaled your proportional gain Ixx30. To simplify it in your mind, the DAC output is a function of the error signal, i.e. difference between the command "position" (in this case your desired voltage) and the actual "position". If you set the feedback register to something that always says zero, then the error signal will = command - zero = command. Thus, if you set the scaling registers Ixx08 and the Ixx30 correctly, then the DAC output will be what you want and you shouldn't have a problem. As Steve said you will have to set the fatal following error limit Ixx11 = 0 or it will trip out when your command exceeds this value.

It sounds like you are going in a direction until you physically hit something, which causes following error to go up, and then you want to home in the other direction. I can only guess. Conceptually, if the jog acceleration is too low then the system may hit the fatal following error limit in the original direction before it can slow down, stop, and reverse. If your "trigger" is too stiff relative to how fast you can decelerate your system then this approach will likely always trip on fatal FE. You can try lowering the jog speed, raising the jog acceleration, lowering the warning FE limit, and raising the fatal FE limit.

Based on what I am reading, it sounds like your motor-encoder-amplifier system that you bought closes a velocity loop around the spindle, i.e. by giving it a command, for example an O command, you get a speed. Is this true? If so: 1. Make sure that this loop is well tuned, i.e. the speed follows the commanded speed well. Step inputs to the velocity is a good way to test this. 2. Close the position loop in PMAC using largely P and I gains, and feedforward as required. You probably won't need a lot of D. It sounds like your P gain is way too low and/or your I gain is way to high.

Perhaps you should post your program here, as well as any information about your axis definition statements if you are using them.

We have accomplished solving this problem before using the "big step" filter, Ixx67. Result is similar to what Curt suggests. Our issue was a parallel word where one bit would flip incorrectly. That said, this is a workaround, and you should attempt to solve your noise problem.

Once again I mention that powers of 2 indicate parallel data and not quadrature. I don't know your hardware, but clearly the problem is with a digital signal / parallel word, or an internal register. If you have an issue with serial device like a quadrature encoder, you get any number of missed counts. Also, the counts tend to be missed, i.e. the machine comes up short. Parallel data / powers of 2 error can have any polarity. This should help narrow down where the error is entering the servo loop. Of course, the cause of the noise could be many things. I once had the same problem with a VME PMAC and a 14V parallel feedback card where any one of the bits could fire. We never solved it, I am said to say, but it was isolated to one machine.

Please note that the G, M, and T commands in PMAC are essentially motion program subroutine calls to a specific subprogram, program number depending upon whether G, M, or T. You could make a custom G code, i.e. Gxx that calls the subprogram. Another option is the CALL command. Then in your subprogram you will be issuing a CMD"z(position)^-0.1". There are some details that you will need to work out, but this is the gist.

NORMAL defines the direction vector that points in the direction perpendicular to the plane of the circle. For example, if you point the nomal vector in the Z direction and you do a CIRCLE move in the X-Y plane you get a true circle. Now, if you point the direction vector in a direction that is an angle to the X-Y plane and then do a CIRCLE move in the X-Y plane, PMAC computes the CIRCLE in X-Y-Z space, but only makes the move in the X-Y plane, hence you get an ellipse. Think of it like the X-Y plane is cutting a cylinder whose axis is parallel to the NORMAL vector. If you play with this a bit you will understand how to do the algebra to get what you want.

Can you report on what is the frequency of the buzzing? Can you look at the following error in the frequency domain, i.e. FFT of the following error? Dead band in your case is likely two wrongs trying to make a right. If the buzzing is truly much higer frequency than the servo bandwidth and is happening primarily at one frequency, then you will likely get better performance by introducing a notch filter at the buzz frequency. On the flip side, if the buzzing is due to a relatively low frequency mechanical resonance then the notch will just kill your phase margin and you won't really get much of a benefit. In that case you will likely have to go with lower gain.