Display files/directories of a remote system (RIO) on a host machine (PC)

Question

Hello,
Please assume that we are discussing software built on the standard "Labview FPGA Control on Compact RIO" sample project. The host is a standard PC running LV14 Fall edition, the remote system is an sbRIO-9636 having an SD card and a USB HDD attached. The objective is process control. The process being controlled is not relevant to the question.
This question is about implementing the following functionality: the user operates a host machine running a Labview user interface vi (UI Main.vi) locally on the host machine. Part of this vi must offer the user a built in dialogue (some express vi or another) or custom dialogue (a bespoke vi displayed on demand). The dialogue must display the directories and files of the remote system which runs RT Main.vi and it must allow the user to select a single XML file on the remote system (which contains some generic configuration information). The name of the file will then be passed to the remote system and the remote system will act to open it and populate some configuration variables.
I am sure that a widely used solution exists for this problem but I've not found the right words to type into my favourite search engine yet to produce the result. I propose the following:
1) User clicks a "select config file" button on UI Main.vi
2) The UI Main.vi event loop enqueues a message on the UI Main message queue based on the value change event caused by the button press
3) The UI Main.vi message loop enqueues a separate message on to the "UI Command Stream" network stream
4) The RT Main.vi, RT Loop - UI Commands.vi subvi receives the message from the stream and enqueues it on the RT Main.vi message queue
5) The RT Main.vi message loop performs some functions to read the disk structures, directories and file names from the RT system
6) The file and directory name data in (5) is converted to a variant and is passed along with a suitable message into the RT Writer network stream
7) The UI Main.vi periodically reads the RT Writer network stream (it's in the "monitoring loop") and enqueues the received message (from 6) into the UI message queue
8) The UI Main message queue populated the UI Main front panel with the data
9) The user selects the directory and file they desire and clicks an "ok" button
10) The ok button click causes the event loop of UI main to enqueue a message in UI Main.vi's message queue due to the value change on the ok button
11) The UI Message loop enqueues a message on to the "UI Command Stream" network stream with the selected fully qualified file name of the selected file as the data (stored as variant)
12) The RT Main.vi, RT Loop - UI Commands.vi subvi receives the message from the stream and enqueues it on the RT Main.vi message queue
13) The RT Main.vi message loop opens the XML file and populated the appropriate variables with the configuration options therein.
The user should be able to cancel the dialogue and avoid using a configuration file but I have not delt with that here.
Now for the questions:
1) Is this a logical approach?
2) Are there any suggestions for a better way?
3) Any links to some pre-written code that will allow me to impliment all or part of this with minimum effort (I'm thinking here of the dialogue box bit rather than the network streams and events bit as those structures are extant and have lots of bespoke code already in them)?
Thanks,
James
Solved!
Go to Solution.

Answer 1

Hi Bob,
Thanks for your input. You're right I have used network streams. 
I implimented more or less what I said in my original post. It works. My main objective was to keep all the config stuff, and data for the particular target on the target's SDCard. On reflection that did make my life much harder than keeping stuff on the host. 
It is more (quite a lot more) involved to keep the config files on the target and send directory info etc. back to the host on demand. If I was to do this again I would probably keep the config files on the host machine and keep them in Dropbox or a Google drive so that if I had more than one host to work from (Work PC, Home PC and Laptop...) I would have all my files with little effort. Still I didn't konw that when I started.
Thanks,
James