UDP server on remote target with Veristand and Labview

[GSinMN]

Hello All,

  I am working on a project that will deploy a model to a real-time target, and I will need to communicate with the model through UDP (to both send commands, and receive data).  I know that Veristand has some UDP functionality built in, but it is a little to generic for our needs.  My intention is to create a simple "server" VI in Labview, convert it to a Labview model, and deploy it with Veristand alongside the main model on the target.  Then I would pass the model communications through the UDP server.  The project will eventually include several targets, in a distributed processing system.

  My question is this:  How do I prepare the UDP server VI so that I can pass data through it?  All of the UDP related examples I have seen generate the messages within the VI, or require a front-panel interface to send the commands.  This server will need to operate without user interaction.

 I am working with Veristand 2011, Labview 2011, and my target is the PXIe-8133 controller.  I also have the entire 2012 Developer Suite available. 

Thanks for your time. 

GSinMN       

[Sev_K]

Hi GSinMN,

Have a look at the UDP Communications.lvproj in the Example finder. This example transfers a waveform from a real-time target through UDP to the host. In your case this setup will be switched around. The "host" would be your main real-time model and then you'll have your other VI running on you PC communicating data to that model through UDP.

I mention this example because the Real-time code in this project does not have anything on the front panel, meaning that all the UDP communication is done programmatically, which I think is what you are looking for.

[GSinMN]

Good Afternoon Sev_K,

  Thank you for the response.  I was indeed aware of this example, but was unable to view it do to a lack of the required add-on (until recently).  After some investigating, I found I was able to view it in Labview 2012.  I'm sure you know that Veristand hasn't been keeping up with Labview for versions.  We've had to deal with some compatibility issues.  Because of this, I generally work in Labview 2011.  But, my computer problems are for another time...

  The example does indeed appear to include the functionality required for Real-Time UDP communication.  I think the "meat" of the code is actually in the subVI "UDP Send Receive".  Almost everything else is just there to generate and prepare example data, for the purposes of demonstration.

  I do have one additional question:  Is it the best option to convert this to a Labview model, and deploy it alongside my regular real-time model as I originally intended, or are there better suggestions, such as creating a custom device in Veristand, or something like that?

Thanks for your time,

GSinMN     

[Sev_K]

Hi GSinMN,

There are pros and cons to both models and custom devices. Models are easier to create and deploy, since Custom Devices require more knowledge of how to program in LabVIEW and knowledge of how VeriStand works internally. An advantage to CDs is that they can be written to dynamically create more channels from the System Explorer, whereas a model is set in stone. You'd have to recompile a model to add more channels.

Asynchronous custom device runs in a separate loop from the primary control loop. Therefore it won't potentially block the primary loop or slow it down, and it can run at same or different rates. The penalty you pay for this is a minimum of one cycle delay as data is passed to/from the RT FIFOs. This same 1 cycle delay applies to a model being executed by NI VeriStand when it is set to parallel model.

Compared to NI VeriStand models, custom devices give you more freedom regarding the execution architecture and give you the ability to customize the edit-time experience in the System Explorer. NI VeriStand custom devices are created with LabVIEW using a template library. The template library requires both an edit-time component that is embedded in the System Explorer and a run-time component that executes with the NI VeriStand Real-Time Engine and has access to the engine’s timing and data resources.

For more details on custom devices have a look at Building Custom Devices for NI VeriStand and Easy Custom Device Tool.

[GSinMN]

Good Afternoon Sev K,

  I've been studying the UDP Communications example provided with Labview, and I think I understand the functionality of each of the VIs, but there is one thing I can't seem to figure out.  What part of the project is the part that actually deploys the VI to the target?  I attempted to run the VI, but it didn't seem to work.  In fact, it disabled the Veristand Engine on the target, and I had to reload it to get it to operate again.  This should have worked without Veristand, correct?  Thanks. 

GSinMN 

[Sev_K]

Yes, you don't need Veristand to run the UDP Communications example project. That example project has you computer and an RT target in the Project explorer. Once you configure the IP settings of your cRIO (or any other RT target ) you should open the UDP Communication - RT.vi and run it. When you click the Run button LabVIEW will start executing the RT VI on your Real-Time target. 

Once the RT VI is running you can run the UDP Communication - Host.vi under "My Computer". Click on the "Activate" switch on the front panel of that VI and you should be able to see the data tramsmitted from the RT target to the PC. (see attached screenshot)

[StephenB]

Sev, I believe he is talking about sending and receiving UDP commands to his model that is run inside NI VeriStand (his original post) so therefore running code from the LabVIEW project to deploy a UDP server to an RT target is inappropriate.

GSinM, yes, NIVS has built in UDP functionality but it is only for streaming channel data. So I would not look at the UDP examples that have to do with NI VeriStand because your use case is different. You are correct, you can make a simple server VI with LabVIEW and convert it to a model and run that model in NI VeriStand... but I don't recommend this approach. NI VeriStand models are simply called over and over again by the NI VeriStand loop, therefore they don't have discrete execution states like "open", "start" "execute" "close". They just have a single state "execute" so you would have to open and close your UDP session every iteration... which wouldn't work for a server.

Instead I recommend creating a custom device. Custom devices do have discrete execution states and lend themselves very well to this kind of use. If it is your first custom device, I recommend using the Easy Custom Device tool.

You can find a great flow chart about making decisions like this here: http://www.ni.com/white-paper/12640/en

as well as links to the easy custom device tool

[GSinMN]

Spoiler

Hello StephenB,

  Welcome to the conversation, and thanks for chiming in.  You are correct about my ultimate intentions related to the project.  In the end, it will be about the most reliable and/or efficient way to send commands to, and receive data from, my main model.  The examples have been very useful in teaching UDP functionality, but I too have come to realize that a Labview Model may not be the best solution, both for the reasons you mentioned, and for stability.  I see you already noticed and replied to my other post about the "Undeploy Sequence".  The reason for that post was because I've been crashing Veristand pretty regularly, and I'm pretty sure it is because I am interrupting the Labview models.  I'll try for a custom device. 

  One additional note for anyone reading this, that is struggling to get basic UDP functionality working:  Check your Windows Firewall settings! 

Thanks again,

GSinMN

[JackCaster]

Hello,

I'm using this thread because I'm facing the same problems of the user GSinMN.

I am Master Student and I'm working on my Thesis which is about a Driving Simulator.

The Vehicle Dynamics is developed in Simulink/Matlab and is deployed to a National Instrument PXI Real Time Machine, controlled by NI Veristand 2011. In particular my project is related to the HMI (Human Machine Interface) evaluation: I would like to interface a Touch Panel (e.g. a Windows 8 Pro tablet, with a UI developed in LabVIEW 2011) with the Simulator workstation, and change, for example, some simulation's parameters directly from the interface on the Touch Panel (enable/disable driving assistance, change steering response...). I'm wondering about a TCP/UDP communication between the Host computer and the touch device.

The first idea to test the platform is to interface a simple Boolean button (on the touch device) with a simple Boolean indicator (on the Veristand's Workspace), sharing the variable's value via TCP. I modified the two example about TCP sender and receiver provided with LabVIEW, I ran the sender VI on the touch device and I compiled and imported the receiver VI in Veristand. The model on Veristand has the same port number of the sender. I tried to test the communication but it didn't work; therefore I thought it was necessary to create a Custom Device and create a simple server device (as suggested in the previous posts) in order to open a TCP stream and connect the Sender VI's channel to the Boolean indicator's channel on the Veristand's workspace.

Do you think is still the right way to proceed? I'm familiar with Simulink but I have a basic knowledge of LabVIEW, and I really don't know how to create this kind of Custom Device. Do you know if there are examples already available?

Thank you (very much) in advance,

Alb

[GSinMN]

Good Morning Alb,

  I think I understand what you are trying to do, but I would like to clarify one thing:  If you are deploying the Veristand project to the PXI controller, do you want the touch panel to interface with the controller, or the with host workstation?  Your post indicates "communication between the Host computer and the touch device".  If you want to interface your touch panel with the host workstation, then you don't need to create a custom device.  You should be able to create a simple Labview model (or use one of the examples) that can establish communications, particularly if the application on the touch panel was created in Labview.  Do you have control over that application, or did someone else create it?

  Before you get too deep into the custom device route, I would recommend that you double check the setup of your TCP functions.  It took me a long time to understand how the functions work together, and it is very easy to derail the whole process with simple setup errors.  For example, the IP addresses are setup differently for UDP and TCP, and the order of which you start the applications is important.  

  If you do actually want the touch panel to interface directly with the controller, then you probably do need to create a custom device and deploy it to the controller.  Simply deploying a Labview model is not a good choice, because you have no way to split the functions you want to loop, from the functions you don't want to loop.  I would recommend that you read the latest help files for Veristand.  They are greatly improved over what was available in previous versions.  Even if you are using Veristand 2011, read the online help files for Veristand 2013 and Labview 2013, related to Custom Devices.  The process has not changed, but it is explained a little better.  And, as explained in previous posts, use the Easy Custom Device Tool.  Follow through the example, and it should show you everything about how to split up your functions across the various configuration files.  

GSinMN