How does VeriStand fit into the mix?

[joedowdle]

As a few posts before have certainly shown... I'm very new to VeriStand and RT/FPGA.  I am having some trouble grasping where VeriStand fits into the mix after taking the RT 1 and FPGA courses.  The set up I am using includes a Windows machine with VeriStand on it connected to a PXI chassis with an RT embedded controller, two FPGA cards, and several other I/O cards.  I'm primarily interested in getting the FPGA's working.

Without VeriStand my understand is the system looks something like the following:

__________          _______________

| Windows  | <--->  | RT  <--> FPGA |

And you have your host VI running on the Windows machine.

Now with VeriStand does it look the same and instead of having a host VI you have your .nivsscreen file in VeriStand to observe/control everything?

I may have asked this question in a confusing way so let me konw if I need to clarify anything.  Thanks.

[joshe]

Veristand is a Hardware In the Loop application.  VeriStand replaces the RT programming you would normally do for RT control.  It creates all the timing loops and checks the I/O, alarms and will run models for you.  I have used it with an FPGA card 7813R connected to the cRIO chassis using the cRIO modules.  What we had to do was create the FPGA code to talk to the cRIO modules, then create a XML file that translated the DMA channels to Veristand (there is examples of how to do this on the NI site and shipped with Veristand/labview).  In Veristand you create a project and add the FPGA card, then tell VeriStand where the FPGA Bit file is and XML file.  VeriStand will then see all your I/O channels.  Once you have your channels you can inport models to process the channels and do control (PID loops, etc.), and use the mapping tool to connect your channels to the models.  You can set up alarm conditions, and calculated channels.  Once your project is set up, you just need to deploy it to the RT system, and it will run.  You can the interface with the RT system using the Veristand Workspace, or write custom Labview screens using the VeriStand API's.  I hope this clears up how to use VeriStand. We have found it a very powerful tool for us.

[joedowdle]

So basically instead of coding/running a traditional VI on the host computer VeriStand basically acts as that interface and as a user you can customize in many ways.  So like I have these PWM Out's that needs to be controlled; I simply don't have a host VI that does that -- I skip that and do that in VeriStand?  That's how I understand it, is that correct?

[joshe]

There is two parts to VeriStand, the Host part and the RT part.  The Host part lets you communicate with the VeriStand Engine running on the RT system.  When you make a Veristand project you are making the RT code.  The VeriStand project gets compiled and run on the RT system.  For your PWM, you would configure your Veristand project with the PWM cards, and configure the channels how you want them to act (have input and output channels).  If you need a custom control for them, you design that in Labview and compile it as a DLL for VeriStand.  You can then add the DLL to VeriStand.  Once you deploy the Veristand Project to the RT system it will run as an open or closed loop system.  You can then use the VeriStand Workspace on the Host PC to send command to the Veristand Engine running on the RT (i.e. change your PWM output).

VeriStand is ment to simplify programming and RT system, to get it up and running quickly and have it very configurable.  You have to do some work, but most of the heavy lifting is done with VeriStand.

[Carl_Prevas]

Joshe already did a good job of describing what NI VeriStand does.

Using the layout you provided

__________            _____________________

| Windows    | <--->  | RT        <-->   FPGA     |

The NI VeriStand files rougly correspond as follows:

______________________________________                                                    

| <-                  .nivsproj                           ->  |

| .nivsscreen | <--->  | .nivssdf <--> .fpgaconfig |

That is the nivsproj file ties the other files together, the nivsscreen file defines your UI, the .nivssdf file defines the hardware and execution of the real-time engine and the .fpgaconfig file (along with its associated .lvbitx) gives you access to the FPGA.

/Carl

[joedowdle]

I appreciate the explanation from both of you.  It makes a lot more sense now.  Now I just have to use it to learn it more intimately.  Thanks.

[joedowdle]

It was mentioned earlier that you can write custom LabVIEW screens using the VeriStand API.  Is there a resource that talks more about doing that?  And is it worth while to develop screens with this method or would it be better to create a workspace in VeriStand and copy the .nivsscreen file to multiple systems? So far I find the editor for screens to be a pain to use.  It takes a lot longer to create all of the controls/indicators for 100+ channels than what I could do on a LabVIEW front panel.

[joshe]

I would say it depends on your end user for what you want to do.  If you just want to do quick testing and it is the engineers that are using it, I would say stick with the VS Workspace.  If you are giving this to an operator or less skilled person, I would develop the Labview GUI.  Either way you will have to deploy it to all the machines.  I have attached an example of using the VS API's with Labview to do a custom labview screen. There is also the NI VeriStand Example Program - Asynchronous Messaging User Interface   https://decibel.ni.com/content/docs/DOC-16947.  It is writen with LVOOP.  I found that it doesn't handler large amounts of channels well, but it is something to look at.  I am currently using a modified version of what is attached.  Good Luck!