Can I abstract a TCP connection in LV ?

[Bedevere]

hello all

I'm (totally) new to Labview and I'm looking for some knowledgable opinions about one or two things. The application I want to create is distributed between a PC (that will mainly be used as a user interface) and a PAC (linked directly to the PC by an Etherent wire). In addition to that, the PC will have another RJ45 network interface, which will be used to allow access to LV's web server from the local network, to read some state informations of the application.

I have therefore two main questions :

1/ Is it possible using Labview to abstract the network aspect and make the VIs present on the PC and the PAC run as if they were on the same machine ? If not possible, what tool would you recommend to use ? I saw that I can use network sockets (w/ read and write methods over TCP or UDP), but it looks very complicated and resource-consuming to set up, compared with LV's wires and connectors system to transmit data between VIs.

2/ In my mind, the application should use a bus to communicate between the interface part and the core part, and within the core part's modules itself, to exchange state informations, transmit orders, and so on. Labview doesn't recommand to use more than 16 wires/VI, and of course I will need a lot more than 16 I/O signals/program module. What is, according to you, the smartest way to implement this kind of data bus in LV (in my particular networking case) ? The bus should also being able to be splitted in several sub-buses (to redirect certain subsets of the wires to different VIs for testing)

[tst]

You may be a newbie, but at least your questions are intelligent.

Abstracting the network part - yes, this can be done, but you should keep in mind that the VI will still be running on the remote target, so you should not use this to plug directly into your RT code. In these cases, a communication module is very good because it decouples the undeterministic comm from the RT code. You can do this either using a protocol, as you mentioned, or by calling the VIs running on the cFP. For example, a VI could be used as a repository by having an uninitialized shift register which maintains its value between runs (this is known as a LV2-style global) - the cFP app will write values into it and the PC app will read values from it.

To do this, you open a reference to the application running on the cFP and then you call VIs dynamically by name. By using the Call by Reference Node you can call the VI and use its connectory pane. All the primitives you need are in the Application Control palette and you should be able to find some examples in the example finder (Help>>Find Examples) by searching for "dynamic" and other similar terms. Attached is a simpified example.

To transfer data in a real-time target, I believe your best bet would be RT FIFOs.

To learn more about LabVIEW, I suggest you try searching this site and google for LabVIEW tutorials. Here, here, here, here, here and here are a few you can start with and here are some tutorial videos. You can also contact your local NI office and join one of their courses.
In addition, I suggest you read the LabVIEW style guide and the LabVIEW user manual (Help>>Search the LabVIEW Bookshelf).

You should also follow the online communities (this one, the LAVA forums, Info LabVIEW).

[Bedevere]

Thanks a lot for everything, this will be very useful to me !

And about my bus problem, after some search a multilvevel cluster seems a good idea to me :

Bus = 1 cluster = 2 subclusters (Infos, Commands)

1 subcluster = n subsubclusters (One for each module of the system)

1 subsubcluster = etc ... (Some more levels could be useful or not, It will depend of the more precise conception of the system I'll do later)

...

1 sub[...]cluster = n boolean, integer or other base type variables (the actual data)

It gives a good logical representation of the information imo and a lot more easy to manipulate than a huge bunch of mixed wires.

The only drawback that I see in this case is that I'll have a little more work to access a simple element of the bus if I don't want to access the whole cluster via the network each time (which would be resource- and bandwith consuming). I've thought of passing something like an adress in the cluster from the calling PC-side VI to the remote cFP-side VI to retrieve only one base variable or one subcluster over the network (I don't know if it's clear enough). Something like the "read"/"write" parameter in your example, tst. Does it sounds good to you ? I ask you see, because I've often some ... slightly too complicated ideas, and this one is maybe one of them

[tst]

Clusters are great, but as you noted you could have a problem with which part of the cluster to read\write. To work around this, you can try creating a seperate global for each sub-cluster or a seperate subVI for each cluster which will access the central global. You should note that when writing this is more complicated because you need locking. Have a look here for some additional details.

Another option would be to use any of the OOP reference-based solutions, but you should note that these may hurt your determinism. One example would be dqGOOP. With that, you can simply set a VI to change each value.

In any case, you should note that the communication between your time critical code and your comm code should be done using RT FIFOs.

[Bedevere]

I've now recieved the full version of LabVIEW and it's RT module. I've had a look at the RT FIFO mechanism and finally it's look a lot more easy to use than the cluster system I planned to use : More flexible, less complicated (and I'm a specialist of complicated things that never work :D), no need to create references to VIs on another machine, no blocking read or write, all automatic, it looks definetely great !

Is it too simple ? Maybe there's a trap somewhere ? Using this kind of communication mean I'll have a lot of RT FIFO'ed network variables, but by grouping them cleanly in libraries and subfolders in the project manager it should can stay clear enough for other people that could read my code. Howether, I ask myself two new questions now :

1/ Is there a technical problem if I use many (some dozens of booleans and numeric values, less than 50 anyway I think) network variables w/ RT FIFOs ? The host PC and the Fieldpoint device are directly linked with a 2m (homemade crossed :p) RJ45 shielded cable, 100Mb/s transfert rate. The host PC has another network interface (10Mb/s) to communicate with the entreprise network and Internet.

2/ I saw an exemple in LabVIEW help similar to what I'm doing, but the solution used was to use RT FIFO'ed global variables for the local communication between VIs on the embedded system, and not FIFO'ed network variables to communicate with the host computer. One loop with high priority did the work on the embedded sytem, and another with lesser priority made the synchronization between local globals (not very clear that term ^^) on the embedded system, and network variables. I guess there must be a reason to this but I dont't see excatly what it is. If it can help, in my particular, all my variables will be written on one side (PC or cFP) and read by the other side, there should be no concurrent write.

Message Edité par Bedevere le 07-12-2007 04:01 AM

Message Edité par Bedevere le 07-12-2007 04:02 AM

[mrak1]

---

@Bedevere wrote:

1/ Is there a technical problem if I use many (some dozens of booleans and numeric values, less than 50 anyway I think) network variables w/ RT FIFOs ? The host PC and the Fieldpoint device are directly linked with a 2m (homemade crossed :p) RJ45 shielded cable, 100Mb/s transfert rate. The host PC has another network interface (10Mb/s) to communicate with the entreprise network and Internet.

==> I recently used several hundred and had no issues. This type of communication is great for getting the current status of the IO points.  If you do use the network buffering, then you will get nearly lossless data transfer and is great for getting the entire waveform.  You can also combine the booleans into 32 bit unsigned integers to save on the data transfer and convert them back on the host.

2/ I saw an exemple in LabVIEW help similar to what I'm doing, but the solution used was to use RT FIFO'ed global variables for the local communication between VIs on the embedded system, and not FIFO'ed network variables to communicate with the host computer. One loop with high priority did the work on the embedded sytem, and another with lesser priority made the synchronization between local globals (not very clear that term ^^) on the embedded system, and network variables. I guess there must be a reason to this but I dont't see excatly what it is. If it can help, in my particular, all my variables will be written on one side (PC or cFP) and read by the other side, there should be no concurrent write.

==> Yes, you are right.  The producer and the consumer can definately be on separate platforms or even on the same platform.  I used these recently to communicate between a high priority loop and a normal priority loop.  In addition, I used other shared variables to communicate from the RT to the Host

Good Luck!

Mike

[Bedevere]

Thanks for answering me . If I well understand you, it's a cleaner solution to seperate the communications between the subsystem's VIs / loops on one hand, and between the subsystem and the rest of the world on the other hand (so that the subsystem's behaviour cannot be altered by unauthorized/accidental writes from the outside), although it can technically be done ?

Message Edité par Bedevere le 07-13-2007 02:03 AM

[mrak1]

Yes, it can be done.  You can create shared variables that are read only, ones that are only local to RT ( no outside interaction allowed), and ones that can be read or written to from anywhere.  It all depends on the needs of the application and how the operator will interact with the program.

Mike

[Bedevere]

OK, I think this problem is solved, then. Thanks again to you and tst.