Motion Control Architecture - myRIO

[NapDynamite]

Hi All,

Long time since I have posted a question here. 

We have a motion control system under development, using 6 DC motors with power amps and optical encoders for position feedback. The system is partitioned among the FPGA and RT in the following manner.

FPGA:
1. Encoder pulses TO Position Count (six separate/parallel instances)

2. PWM Logic (six separate/parallel instances)

Custom logic here, not using myRIO's default personality. There are total 12 loops (or in the FPGA language 12 copies of hardware in the FPGA fabric)

RT:

1. PID controllers to make the entire motion system as a servo.

2. Some conversion functions (encoder count to angular displacement).

Implemented in Timed Loop. Communicating with FPGA using memory mapped registers (or front panel control and indicators. No DMA-FIFO)

We have successfully tested the above using a single actuator. Works like a charm with steady state, settling time as per our goals. Now in order to do the exact same thing for 6 actuators, what could be the possible architectures for RT? That is, create a separate RT loops (6 timed loops) for each actuator running concurrently. or a single Timed Loop with a FOR loop inside iterating for each actuator. For a better understanding, I am attaching architectural diagrams below. Note that I am not stuck anywhere yet but require a better insight from some champion(s).

architecture-1

archtecture-2

 

The former approach is very resource hungry and I am not sure of each loop's jitter, although the nature of this approach is concurrent. The later approach is very sequential. What would be a better approach? What are the caveats associated with each approach? Should I move everything to FPGA (along with PID)? Should I use handsome DMA-FIFO?


Regards. 

[RIObotics]

This is a great question, as I have encountered this problem too myself!  There are trade offs between architecture 1 and 2.  I personally like #1 better, as it keeps each RT PID loop separate.  If you are using your own custom PID algorithm, I would say go with this way.  Easier to debug, should any problems happen.  To save on CPU resources, if you don't need fast PID loops, you can decrease the loop rates to from 1Khz to maybe just 100Hz (10ms delay.)  In my experience with DC motors, if you're not looking for super fast PID responses, 100Hz should work fine.

The native PID VI in LabVIEW actually uses architecture #2.  There's a polymorphic instance for multi-channel PID, and if you open up the VI, it's based on for loops.  If you just want PID to work, perhaps just use this VI!  Probably would save you alot of time.

Try both out, see which works best.  Best of luck.  Oh and I wouldn't move PID into FPGA, too much work for too little gain.

[NapDynamite]

Thanks RIObotics for a thorough analysis. I did look into the stock PID function.

I will definitely post my test results here.