Program Design for Host-Displaying Data acquired by target

[Arne81]

Hello,

as I am quite new to LabVIEW / LabVIEW RT, I encounter a generel problem in my Program-Design.

The following task is to be done with the following hardware:

Hardware:
Host-PC (will be suited to fit the requirements, Prof. Dev. System with MathScript, LabVIEW 8.2)
PXI System: PXI-8196 (RT-OS), PXI-6220 connecting the SCXI 1314, 1303
PXI 8461 to connect to CAN Network
PXI 8421 to connect a few devices via COM ports

Software: LabVIEW 8.2, LabVIEW RT

Task:
I want to acquire, process and display/store(stream) many data-inputs (including from pressure-sensors
and temp. sensors). The acquired data is multiplexed from the SCXI System to my Real-Time target(PXI).
In order to time/trigger my Acquisition, all 36 PresureInputs and 21 TempInputs are joined to one
task (this is mandatory I guess).
I want a Frontpanel/Display that will show a maximum of 6 selections in a chosable TimeFrame (e.g. 24hours,
1 hour..).
Bottom line: a lot of data must be processed and streamed and in order to be able to show the history of
any 6 of the channels, I will have to store all data in different buffers for each TimeInterval as the rates
differ (24h history at a rate of 1/(5min), 1h history at 0.1Hz, ..  (or can i read from stream-files
while continuing streaming?).

I completed configuring hardware with MAX and the Aquisition of data that is stored in buffers which are to
hand them to DataProcessing (in non-reentrant VIs for each channel including a loop executing once with
shift-registers to store an array of clusters (data+timestamp) and in the loop a case-structure to
handle different task like write, empty, read-all...)

The big design-problem, that I am encountering is:

Do I have to pass all the data to the Host via TCP/IP? (I dislike that idea)

Can I implement all the Acquireing, Processing, Streaming, Storing AND Displaying on the PXI RT Target and
display the Frontpanel of a Target-VI on the host PC (thus I dont have to pass all the data that is currently
not to be viewed to Host - only the currently viewd history and live-data) ?

If I cannot access Target-Frontpanels from Host-PC, would I leave all History-Buffers on RT-Target and just
hand the selected 6 Histories (which may change to other 6s at any time) via DMA-FIFO to my host PC?

Please excuse my Writing-Flash, I guess a lot of information is not neccessary for the 3 final questions above.
Perhaps I am not using the right search terms, but I haven't found help in either the documentation or the forums.

Thanks for your assistance,
Arne81

[TobiD]

Arne,

if you want to display "all" acq. data you have to transmit them to another (Windows)PC via Ethernet. But, you're able to process the "raw" data on your PXI System. You also can save your data in a file (tdms or ascii) and then transmit the file via FTP.

For easy transfer you can use the shared variables (network published) or datasocket.

regards,

Tobias

[Ben]

Why is RT being used?

Avoiding the RT machine could simplify this game.

Ben

[Arne81]

Thank your for your replies.

Can you give me a link to a tutorial about how to access files on a RT.Target (with RT OS) from my host PC via FTP?

I found similar post concerning host-fpga stuff.. a third party (freeware) tool is needed?

RT is used, cause the PXI Controller (PXI 8196) is using RT-OS. The project outline was done by a former college with an NI-Representative. I guess, that determinism was mandatory.

Being able to view and controll the Frontpanel of the main VI on the RT Target would simplify my task. Is that possible?

[Arne81]

Continuous Communicaton Architecture is the way to go?

State machine architecture seems not suitable, as I want to be able to configure pressure sensors during runtime....

Am I on the right track?

Thanks again 🙂

[Ben]

I'll let that Q about of "Is RT required" go for now. 

"VI Server" is waht I would use.

VI Server allows you to programatically determine what VI is executed where.

I did a Jet Aircaft Engine simulator back on LV 6 RT that presented an engine environment to a fuel pump for testing. The GUI running a Windows machine allowed specifying the engine throttle settings etc. These new value had to be realized on the RT target so that it could include the settings when it updated its model.

So...

On the RT Side I used an Action Engine configured as sub-VI priority to hold all of the setting that could be manipulated from the Windows GUI. The RT loop would query the AE for the current settings durring each iteration of the time critical loop. THe setting where also copied out to a local Sr in the TC loop to be used when the GUI was updating the value at the same time the TC loop was checking for new values. If the AE call was skipped (See Skip If Busy) the TC loop would use the values from the previous iteration. This ensured my TC loop stayed determistic and in a worse case condition the new value was applied in the next iteration of the TC loop.

THe AE holding the settings was configured as served to the Windows mahcine.

On the Windows side, a reference opened to the LV instance running on the RT node and that was used to get a ref to the AE. When the user changed a setting on the Windows GUI, an Invoke node call by reference was used to execute the "Update" action of the AE that was running ON THE RT node.

You may have trouble find articles on this approach but back in the day of LV 6 RT this was THE suggested method of controlling the TC loop from a Windows machine.

I hope that helps,

Ben

[Arne81]

Hi Ben,

thank you for your reply. I understood most of it and i am sure, that this is still THE way to do it in 8.2. My main worry is not configuring the RT Target but to display the RT-Target data on the host. As I am at home now, I will review your suggestions instantly tomorrow.

As far as my search on concepts was, VI server was described to be a slow way to get things done. I have no experience whatsoever in how heavy the usage of my cpu/time is and I hope my fears regarding this will be proven unnecessary.

If any other options come up, I am happy to deal with them.

Thx,

Arne