jlmuir

On trying this again, I can't even set Kfff (Ixx68) = 1; even that causes the FE plot to be an inverse of the commanded velocity (well, roughly two horizontal lines that are the inverse of the commanded velocity).

Hello, PMAC Experts! How do I tune a pulse-and-direction stepper motor in closed-loop mode? I'm asking in general, but in case it's relevant, my controller is a Turbo PMAC2 VME Ultralite, my motor driver is a Phytron ZMX+, and my encoder is a linear encoder. On page 84 of the Turbo PMAC User Manual in the "Setting Up Turbo PMAC2 for Pulse-and-Direction Control" section, it says, "If using real feedback sensors, the motor should be tuned as a normal servo motor would be tuned." However, my experience has been that this is not entirely true. The method I have followed involves using the PMAC Tuning Pro2 application to do interactive tuning with two trajectories: first the Position Step to tune Ixx30, Ixx31, and Ixx33, and then the Parabolic Velocity to tune Ixx32, Ixx35, and (maybe) Ixx68. An example of this method is shown in Delta Tau's "Motor Setup Tutorial, MOTOR TUNING EXAMPLE, DC BRUSHLESS MOTOR" video: https://www.youtube.com/watch?v=VUIOqdN8nX4. The Position Step trajectory for my stepper motor does not seem to behave like a servo motor at all. The first difference I see for the Position Step move is with choosing the step size. The step size is supposed to be a half to a quarter of a revolution of the motor (for a rotary motor). In my case, the motor is a rotary motor, but the encoder is a linear encoder (i.e., there's encoder tape along the direction of travel); does that make a difference? I set the step size to 5000 which is half the number of encoder counts for one motor revolution. I left the step time at the default of 500 ms. 5000 counts / 500 ms = 10 counts/ms which is slower than the 50 counts/ms jog speed for this motor, so that should give plenty of time for the step move. I try running this move, and the motor doesn't move at all. I had to increase Kp (Ixx30) to 35 and decrease the step size to 2100 counts before it would move at all. So, this seems to not be anywhere near the same as a servo motor. What am I doing wrong? The second difference I see for the Position Step move is that my stepper motor does not oscillate about the commanded position as I add Kp. A servo motor is supposed to oscillate about the commanded position as Kp is added, but my stepper motor doesn't oscillate at all. As I add Kp, the rise-time decreases and the steady-state error decreases. If I keep adding Kp, though, eventually the stepper motor doesn't move at all and sometimes emits an audible tone for the duration of the step move. So, this too seems to not be anywhere near the same as a servo motor. What am I doing wrong? Is the Position Step move really appropriate for a pulse-and-direction stepper motor? If not, what is? How should the Ixx30, Ixx31, and Ixx33 gains be tuned? I then tried the Parabolic Velocity move. This seemed to behave a bit more like a servo motor. So maybe this is still appropriate for a pulse-and-direction stepper motor? As a final step in my Parabolic Velocity move tuning, I tried to add Kfff (Ixx68), but that didn't seem to work. I could set it to 1 which seemed like it may have helped a little, but adding more seemed to destabilize the system with the FE ending up as an inverse plot of the commanded velocity. So, even though the value range is supposed to be 0 to 32767, I could only set it to 1 before it would destabilize. This makes it feel like maybe this is not meant for a stepper motor? Thank you!

Thank you! That's exactly what I needed to know. It worked great!

Hello! I am controlling a stepper motor in internal-loop mode (i.e., without an encoder). What should the PID servo setup I-variables be set to (i.e., Ixx30-Ixx35 and Ixx68)? Should they all just be set to 0, except for Ixx34 (PID Integration Mode) which perhaps should be set to 1? Should they be left at their factory default values? Or something else? I'm interested in an answer in general, but if it helps to clarify my question, my specific case involves a motor controlled through a MACRO node, so this motor has MI910 (Encoder/Timer n Decode Control) set to 8 (Internal pulse and direction). The 16-Axis MACRO CPU SRM says, "If MI910 is set to 8, the decoder inputs the pulse and direction signal generated by Channel n’s pulse frequency modulator (PFM) output circuitry. This permits the 16-Axis MACRO Station to create a phantom closed loop when driving an open-loop stepper system." I'm asking because it doesn't make any sense to me to tune a PID controller when it has no way to read the actual position, hence no way to compute an error value between the commanded and actual position. And if it just uses the commanded position as the actual position, the error value will always be 0, so then it seems to me that no correction would ever be needed. Thank you!

Hello! I have a Turbo PMAC2 VME Ultralite that is connected to a UMAC MACRO station, and the VME crate that contains the Ultralite was powered off, and upon powering back on, the Ultralite M-variables M961 and M962 had become self-referenced, that is, they had lost their address definition! The commands "M961->" and "M962->" reported "*" and "*", respectively. Those M-variables were supposed to be defined as "D:$488" and "D:$48B", respectively. This occurred despite the fact that a "save" command had been issued to save parameters to non-volatile memory. None of the other Mxx61 and Mxx62 M-variables lost their address definitions for xx=1..32; it was only Mxx61 and Mxx62 for xx=9. The Ultralite firmware version (as reported by the "ver" command) is 1.943. The UMAC MACRO station firmware version (as reported by the "ms0,mi0" command) is 1.203. As an additional data point, I have another Ultralite and UMAC MACRO system that had this same problem when it lost power due to a power outage. Again, when it was powered back on, just M961 and M962 had become self-referenced; they had lost their address definition. The firmware versions are the same as in the first system. How do I prevent this from happening? Or is this a bug fixed in a firmware update? Thanks!