I need a more efficient method of transfering data from RT in a FP2010 to the host.

[cdreike]

I am currently using LV6.1.

My host program is currently using Datasocket to read and write data to and from a Field Point 2010 system. My controls and indicators are defined as datasockets. In FP I have an RT loop talking to a communication loop using RT-FIFO's. The communication loop is using Publish to send and receive via the Datasocket indicators and controls in the host program. I am running out of bandwidth in getting data to and from the host and there is not very much data. The RT program includes 2 PID's and 2 filters. There are 10 floats going to the Host and 10 floats coming back from the Host. The desired Time Critical Loop time is 20ms. The actual loop time is about 14ms. Data is moving back and forth between Host and FP several times a second without regularity(not a problem). If I add a couple more floats each direction, the communications goes to once every several seconds(too slow).

Is there a more efficient method of transfering data back and forth between the Host and the FP system?

Will LV8 provide faster communications between the host and the FP system? I may have the option of moving up.

Thanks,

Chris

[Xu]

TCP is a much faster method.

[Paul M.]

Chris, 

Sounds like you might be maxing out the CPU on the Fieldpoint.

Datasocket is considered a pretty slow method of moving data between hosts and targets as it has quite a bit of overhead assosciated with it.  There are several things you could do. One, instead of using a datasocket for each float you want to transfer (which I assume you are doing), try using an array of floats and use just one datasocket transfer for the whole array.  This is often quite a bit faster than calling a publish VI for many different variables.

Also, as Xu mentioned, using a raw TCP connection would be the fastest way to move data.  I would recommend taking a look at the TCP examples that ship with LabVIEW to see how to effectively use these. 

LabVIEW 8 introduced the shared variable, which when network enabled, makes data transfer very simple and is quite a bit faster than a comparable datasocket transfer.  While faster than datasocket, they are still slower than just flat out using a raw TCP connection, but they are much more flexible.  Also, the shared variables can fucntion in the RT fifo capacity and clean up your diagram quite a bit (while maintaining the RT fifo functionality).

Hope this helps.

[cdreike]

Paul,

Thanks for the info. I have solved my problem by realizing that I do not need to RT-FIFO all data from the Time Critical Loop to a comm loop where it is Published. Turns out that most of the data is being read from FP modules and that can be accessed directly via Datasocket from the host program. All I now have left in the TC loop are the data reads that are necessary for the PID control. The TC loop now will run in about 10ms leaving no time for anything much else. My target rate is 20ms leaving ample time for other functions.

Leaving me with one more problem, the indeterminate nature of the TC loop. It is always bobbling +/- 2ms. What's with that?  I was under the impression that a TC loop running in an FP module would be quite determinate in the 10's of microsecond range. Part of the TC loop is a timer that sends the results back to the host via an RT-FIFO to my comm loop with the data then being Published.

Thanks,

Chris

[Paul M.]

Chris,

That bobbling could be caused by anything in your loop really... What kind of timer are you using? If you're not already, It's generally considered good practice to use the Timed Loop feature on RT -- these tend to be pretty rock solid as far as determinism goes and actually hook into the RTOS better than a regular while loop with a wait.  Also, keep in mind if you're running a VI in Time Critical Priority, if you have a Wait in parallel, the whole VI goes to sleep and will not behave like you would expect (a normal priority VI doesn't do this). So, if you're running Time Critical priority, then put your waits in series with the rest of your code and use the Wait Until Next Ms function.

Hope this helps.