LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Motion Control Architecture - myRIO

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

actuator_subsystem-Page-4.png

 

archtecture-2

actuator_subsystem-Page-4.png

 

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. 

 

 

 

 


0 Kudos
Message 1 of 3
(205 Views)

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.

RIObotics_0-1642765709818.png

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.

Message 2 of 3
(166 Views)

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

I will definitely post my test results here.

 

 


0 Kudos
Message 3 of 3
(158 Views)