How to assign the 4th amplifier as U axis

[steve.milici]

The setup I have given you puts PMAC into a “pure position” mode as a voltage output. The DAC output follows the commanded trajectory. There is no PID loop to try to “fight” following error. This is commonly used in piezo systems or other “drives” that provide the PID and require only pure position command.

 

What exactly is the hardware you are connecting to the PMAC?

[Raghav]

The setup I have given you puts PMAC into a “pure position” mode as a voltage output. The DAC output follows the commanded trajectory. There is no PID loop to try to “fight” following error. This is commonly used in piezo systems or other “drives” that provide the PID and require only pure position command.

 

What exactly is the hardware you are connecting to the PMAC?

 

Yes, its a Piezo actuator. I have a stain gauge sensor output which provides the displacement in terms of voltage. Can it be used along with a A/D converter and form a closed loop? But the issue is the sensor output voltage is available only when the Piezo is in closed loop in their amplifier. So I'm confused and since there cannot have two closed-loops, I was asking for the method to control in open loop.

Can you suggest me in this case.

[tahoe brian]

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

[Raghav]

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

 

Hi Brian,

Yes I did that. As I mentioned 29000 counts provides me 8.85V which provides me 20 micron displacement. 1450 cts provides me 1 micron.

[tahoe brian]

So, what specifically is the symptom of your problem?

[Raghav]

So, what specifically is the symptom of your problem?

 

When I try to move the axis in FRAX mode and generate features, it doesn't produce the desired design feature. But this is not the case with the tuned linear axes based machining. So I'm not sure of the exact cause of this issue and how to overcome this with the current open-loop setup

[curtwilson]

It is important to understand what the concept of "vector feedrate" does and how it works. The purpose of a vector feedrate command (F...) is to permit the user to command a move in any direction in a plane or space and have the tool speed be the same in all directions, with PMAC automatically figuring out how fast each axis must move to get that net tool speed. This concept really only makes sense in 2D or 3D Cartesian space, which is why the default "feedrate axes" (FRAX) are X, Y, and Z.

 

People get in trouble when they try to add a 4th feedrate axis, because it no longer makes geometric sense. I don't think the units of your U axis are the same as those of X, Y, and Z. I think you need to leave your feedrate axes at the default of X, Y, and Z. When you command only a non-feedrate axis in feedrate mode, the parameter Isx78 controls the speed of the move, not the latest F value.

 

All of this is independent of the issue of if and how the servo loop is closed -- this issue is with the trajectory generation of commanded positions.

[tahoe brian]

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.

[curtwilson]

Brian:

 

You are correct that if the U axis is defined in the same units as the Y and Z axes (and you are not trying to do a simultaneous X move), then with U as one of the feedrate axes, you can do feedrate-based moves that make geometric sense.

 

This is why we give you the flexibility of the FRAX command, instead of reserving the functionality just to the X, Y, and Z axes, as most controllers do. However, the flexibility does lead to some confusion.

[tahoe brian]

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.