Jump to content
OMRON Forums

pCascadeCmd


steveneads

Recommended Posts

Hi

 

This problem is rather awkward to describe, but here goes...

 

I have what's probably an unusual application where I have 2 motion programs driving a single physical motor. One program sends its commands direct to the PID (#7) that actually drives the motor, the other sends its commands to another PID (#4) which cascades its output to PID#7 via a 0D compensation table, that writes to the CompDesPos input of #7. PID#4 has no feedback and only a proportional gain of 1, and the output that gets copied from it to #7 is scaled by the compensation table. The compensation table runs between PID#4 and PID#7 to minimise delays. This layout does what I need and works.

 

Since seeing that you have the new pCascadeCmd method, I've tried converting my code to use this. I've removed the compensation table, set #4 to cascade to the CompDesPos input of #7 and set the proportional gain of #4 to the scale factor that was previously in the compensation table. It "sort of" works - but not quite right! I can't figure out what's really going on, but my motion programs don't quite work in the way that they used to. Both programs are started together, and the motion program that drives #4 waits in a while loop doing zero moves whilst #7 attempts to move the motor to zero position. #4 is then allowed to exit its while loop and generate a required motion. The problem is that the move to zero now sometimes does not end up at the correct position. It seems like some sort of timing issue that is resulting in an offset somewhere being wrong.

 

Is there a subtle difference in the way the pCascade command executes in comparison with my 0D compensation table method? I've given up with it for now and reverted to my old method - but I'd like to understand what the problem really is!

Link to comment
Share on other sites

  • Replies 3
  • Created
  • Last Reply

Top Posters In This Topic

Does this relate to your earlier post regarding following another motors command at some ratio, I think perhaps 70%?

 

Regardless, in this case I think you might be comparing methods that are not quite the same thing. As you describe your current (successful) approach I think you are using the trajectory generator of #4 to write an offset value to #7 via a compensation table. This is not actually what is generally understood as a cascade control.

Cascade is when you have one PID loop output driving the input of a second loop that is in turn controlling the motor. This is commonly used in force control where the first loop is using a load cell for feedback and the second loop is looking at load (motor) position. It allows you to drive the motor position as a function of force. Your command/trajectory would be in units of force and the motors position would be irrelevant other than it must have enough range to achieve the required force in the system. Think of keeping a spring stretched to a commanded tension as the other end might (or might not) be allowed to move. The commanded tension in this case could be a time/tension profile. What it is NOT is a direct or scaled position function like a geared or following scenario.

The key here might be to recognize there is no feedback on the first loop.

Link to comment
Share on other sites

Actually it's not directly related to my last post - that was for a different device.

 

I am very well aware of the typical use of cascade control for force loops etc. I have been using this approach in our products for more than 15 years. However, it is also possible to use the PID structure to pass a scaled signal through from the command to the output by ensuring that the feedback is held at zero (so that the following error = the command) and that the only gain is the P term. The servo out is then simply a scaled version of the input. The only reason for doing this is to get around the standard DT system architecture for a weird application such as mine!

Link to comment
Share on other sites

Hi

 

This problem is rather awkward to describe, but here goes...

 

I have what's probably an unusual application where I have 2 motion programs driving a single physical motor. One program sends its commands direct to the PID (#7) that actually drives the motor, the other sends its commands to another PID (#4) which cascades its output to PID#7 via a 0D compensation table, that writes to the CompDesPos input of #7. PID#4 has no feedback and only a proportional gain of 1, and the output that gets copied from it to #7 is scaled by the compensation table. The compensation table runs between PID#4 and PID#7 to minimise delays. This layout does what I need and works.

 

Since seeing that you have the new pCascadeCmd method, I've tried converting my code to use this. I've removed the compensation table, set #4 to cascade to the CompDesPos input of #7 and set the proportional gain of #4 to the scale factor that was previously in the compensation table. It "sort of" works - but not quite right! I can't figure out what's really going on, but my motion programs don't quite work in the way that they used to. Both programs are started together, and the motion program that drives #4 waits in a while loop doing zero moves whilst #7 attempts to move the motor to zero position. #4 is then allowed to exit its while loop and generate a required motion. The problem is that the move to zero now sometimes does not end up at the correct position. It seems like some sort of timing issue that is resulting in an offset somewhere being wrong.

 

Is there a subtle difference in the way the pCascade command executes in comparison with my 0D compensation table method? I've given up with it for now and reverted to my old method - but I'd like to understand what the problem really is!

 

I can't find any reason nor can I reproduce this issue. I would probably need to see your project to research this better.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.

×
×
  • Create New...