Jump to content
OMRON Forums

daraszz

Members
  • Posts

    4
  • Joined

  • Last visited

daraszz's Achievements

Rookie

Rookie (2/14)

  • First Post
  • Conversation Starter
  • Week One Done
  • One Month Later
  • One Year In

Recent Badges

0

Reputation

  1. I'm working on an application tuning a quad-HR2 axis (90° spaced) with a ~300mm diameter ceramic ring on an air bearing, utilizing SIN/COS encoders with ACI 24E3 to generate 2^32 cnts/rev. Operationally speaking, encoders are in the correct direction, as is the motor command. Mechanically the system is very well aligned (to Renishaw and Nanomotion specifications), and has been triple checked at this point. The main issue I'm dealing with is the velocity ripple. The ripple amplitude is roughly 5-10% of the velocity, at roughly 8-10Hz. I'm doing most of my tuning with a parabolic velocity move to best observe the behavior, but it's just as apparent at a constant velocity. Per some white papers on the subject of tuning Nanomotion motors on older PMAC2, I've set my friction feedforward (Kfff) to 10% of the DAC. I've tried removing this entirely as well, but it was clearly beneficial to have friction feedforward when using these motors. Other terms I've adjusted: Motor[x].Servo.SwZvInt = 1, but I've had integral disabled for most of my tests anyway Motor[x].Servo.SwFffInt as 0 or 1 (no visible difference in the plot) I've been adjusting my derivative term in Motor[x].Servo.Kvifb instead of Motor[x].Servo.Kvfb, so that the derivative gain contribution is assisting more on disturbance rejection. My proportional term is set relatively "low" compared my derivate term. The Nanomotion amplifiers are velocity mode amplifiers, so perhaps my Pgain should have more influence on the servo loop than the Dgain in this instance. I guess switching the dominant gain is one thing I haven't tried yet. Trajectory pre-filtering didn't have any noticeable effect (I wasn't really expecting it to, but it was something to explore). Similarly adding a low pass filter to the velocity loop didn't help very much; less oscillation, but a greater error amplitude. I was curious if anyone has had a similar setup, and how you got the servo loops to stabilize, particularly at velocity. My setup is pretty stable in steady state. Some parabolic plots attached. Thanks! 2022-01-06_13-16-59.bmp 2022-01-06_13-37-52.bmp 2022-01-06_13-42-37.bmp
  2. In the example below for writing in a EquWrite value, getting " 'volatile struct ' has no member named 'EquWrite' " on build. volatile GateArray3 *Gate3IC = GetGate3MemPtr(0); Gate3IC->Chan[2].EquWrite = 3; // Set EQU state to 1 // delay here Gate3IC->Chan[2].EquWrite = 1; // Set EQU state to 0 Can you tell me if this particular member is not accessible? The other members work fine.
  3. Just read it through, make sense. I'll test it this morning, though I'll be using this on Gate2, any issues with that?
  4. I’m working on an application to do EQU output firing along an XY path. I’m using the laser control white paper to do this, but in my variation I will need to continuously update the EQU on/off position since the spacing and width of the EQU signal will vary along the path (each spacing and width will likely be different). Will the best way to accomplish this be to have a background C program looking for the falling edge of the EQU signal, and re-run the EquSetup_DutyCycle routine at that event, updating the passed values to the routine with the next position? The on off positions could be stored in the PMAC, and be updated to the EQU subroutine with indirect addressing, or comp table storage potentially. Thanks!
×
×
  • Create New...