Control and Simulation Loop / While Loop with TCP/IP Read / Write Syncronization

[tstratton2007]

Hello, I have problem concerning TCP/IP Reading and Writing within two loops. The problem is NOT in getting the two loops to read and write to and from each other. That has been accomplished. My problem comes when I run the Control and Simulation Loop on my laptop and the While Loop on a Remote RTOS on the LabVIEW Embedded Controller within a remote PXI Chassis, the while loop on the remote system runs four (4) times faster than the control and simulation loop on my laptop. That is, for every one iteration of the control and simulation loop on my laptop, there are four (4) iteration of the while loop on the remote system. I need to know how to get a one to one (1:1) relationship with these loop iterations. When I run longer simulation in real-time, say about 10 seconds, the Control and Simulation Loop begins to slow, i.e. the simulation time slows until it is no longer in real-time and the "Finish Late?" Parameter is true and the LED lights up and continues to stay lit. At this point the system destabilizes due to what I believe is the sampling rate being far too discrete and I have to halt the simulation. How can I get a one to one ratio between the loops and also avoid the slowing of the loops causing destabilization?

To give some insight into my application, I am implementing a Networked Control System seen in "image2.png". This is being achieved by using my laptop as subsystem 1. Reference signals are generated from within the laptop and the error signal is produced. Control action is taken and the control signals are sent via TCP/IP to the remote system. Position feedback is sent back and the process repeats. My system has Core I7 Procs w/ 3 GB of RAM, up to 1 GB/s networking speeds via ethernet, and LabVIEW 2011 installed with all necessary modules and toolkits. The Custom_Wireless_Controller VI attached runs on my laptop. The remote system I am working on has the NI 7830 R Series Card with FPGA. The RTOS runs on the PXI Chassis with an enbedded controller that has networking capabilities of up to 100 MB/s via ethernet. I use the FPGA for DAQ and to apply Control signals to my plant. The Plant is the ECP Torsional Plant connected to the FPGA via the ECP-RIO Cable from NI. Subsystem 2 constitutes this side of the NCS. The FPGA collects Position Feedback, sends it to the controller through the network, receives Control Signals from the network, and writes the signals to the plant power amplifier which actuates the plant. This process repeats and the VI is attached and titled Custom_Wireless_Plant.

I would truly appreciate the help and look forward to it and any questions!

[Mark_Yedinak]

You will need to profile the code that is running on the PC. I suspect that it takes 400 ms to execute a single iteration of the loop. Therefore you are seeing the 4:1 ratio. Also, the stacks on each end will buffer data and will allow dtaa to flow even though the application has not consumed it yet. It will be very difficult to get your code to run perfectly in lock step with each other. The TCP primatives only handle the transfer from the application to the stack. It will take a while before you get a timeout error. It will only occur after the stack's buffers have been filled.

[Barp · Accepted solution]

Well, the first step is to understand what you have setup right now. Your Control and Simulation Loop on the controller side is setup as "Runga Kutta 4" and you have a timed loop on the other side. Also, you have the TCP/IP primitives on the Control and Simulation Diagram and, this means that, it will execute (send a message) on every minor step size, which in your case is 4.

So, you have two option:

1. Change the solver to Controller side to be Runga Kutta 1 (this should synchronize the loops)

2. Keep RK 4, but create a subVI around the two TCP/IP primitives and configure the VI to execute only on Major (Continuous) Step-size. If you do that properly, you should see a "C" on the right top part of the VI you created.

Please let me know if anything I said is not clear...

[Ben]

and for something completely different... back in the dat of LV 6i NI used to teach that using VI server to execute an AE running on the target node was THE WAY to do internode communiations. The beauty of that approach was/is that you pick-up all of the power of the AE including its syncronization capacity and it's buil-in avoidence of race conditions. We have been using VI server for about 12 years with great success. Done with the "different". Ben

[tstratton2007]

Thank you for all of your help. Give me some time to implement these changes and I will get back with you. Thank you once again!

[tstratton2007]

@Barp, thank you so much for both of your solutions. I tried both and found that making the TCP/IP Primitives subVIs solution yielded better performance, based solely off of visual inspection. I still find that when I run a Sinusoid for long periods, say 60 seconds, the simulation clock speed slows from real time and the finish late icon lights up. This is by far not as drastic as before thanks to your solutions and I can manage to collect all my necessary data. I suppose there is queuing delay at the routers in between my end systems. Can anyone suggest a reason for this phenomena, i.e. the slowing of the simulation clock speed after running an experiment for a long time? As I stated before, Barp's second solution was chosen and the loops are now syncronized, i.e. 1:1 iterations. Before the syncronization of the loops, this slowing of the simulation clock speed was much more noticeable and would occur within a much shorter times than now. This leads me to believe that the network is congested. But I gladly welcome alternate explanations! Thank you in advance!

[tstratton2007]

@Ben, forgive me but I am unfamiliar with what you are referring to when you say "using VI server to execute an AE", and a quick search for it yield little information. I am quite new to LabVIEW so there was probably some oversight involved. I started working on it as a greenhorn in January. I would like to implement your solution also to compare performance but will need a little more coaching if you don't mind. Syncronization Capacity and Built-in aviodance of race conditions does sound intriguing!

[tstratton2007]

@Mark, I am unfamiliar with this jargon... What do you mean profile the code running on the PC...? I believe that when you refer to my code running lock step with each other you are referring to the syncronization of the loops. The architecture of the code should handle the syncronization. The read/write combination pairs should make it work. Only when my plant code writes will the controller code read and vice versa. Thus, what Ben says concerning the major and minor steps of the Control and Simulation Loop makes more sense that on each minor step, there being four minor steps when I utilize the Runge-Kutta 4 method, I read and write from my controller to my plant four times, i.e. on every minor step. But I only record on the controller side on the major time steps as opposed to every minor step on the plant side. Thus, my four to one (4:1) plant to controller iteration ratio. I look forward to your input and comments! Thank you in advance!

[Barp]

tstratton2007

The 'finish late' flag happens when the simulation loop was not able to run on the specified time. So, something 'inside' the execution is taking longer. The TCP/IP could be the reason if you are running into collisions on the network. But also, keep in mind that you are not only running this loop. On Windows, other processes happen in parallel and this could 'starve' your controller loop. So, the delay could be your virus scan starting to work on the background.

An interesting experiment would be to bump up the priority of the controller loop. On the second tab of the Simulation Loop, you can increase the priority number and see if that would make a difference.

Also, to avoid collisions, you could fisically connect directly to the controller. The new cRIOs allow you connecting directly without the crossover cable.

Hope this helps...