CompactRIO Temperature Controller Reference Application

[Daniel_E]

Hello Everyone!

I posted this on Developer Zone but also wanted to start a discussion here on NI Community.

CompactRIO Temperature Controller Reference Application

This an example of how to do a simple temperature controller application.  The application can be broken up into a CompactRIO application and a host interface application.  The CompactRIO application controls temperature, or any other process variable, at slow update rates (10 Hz or less) on 16 independent channels using PID or On/Off control.  Additional features include setpoint profiles, datalogging at 1 Hz, and communication to a host interface.  The host interface applicaiton allows for configuration and data viewing of the CompactRIO application.

Any feedback is greatly appreciated!

[Jeff_Long]

This looks like a great example and it's appears to be well documented.  It's perfect for an application that I have coming up soon.

One question; on which cRIO controllers can this run?

My application calls for up to 8 channels of ON/OFF temperature control with some extra functionality like cycling some digital I/O during test, monitoring an E-Stop loop, and implementing an over-temperature cutout.  I'm hoping to be able to implement this using a cRIO-9073 due to the cost sensitivity of my customer.  Do you know if it will work on the 9073?  Do you have any benchmarks for this application on various cRIO controllers?

[Daniel_E]

Thanks for the comments.

The program can run on any cRIO that supports the scan engine, which should include the cRIO-9073.  The benchmarking was done on a cRIO 9074 and cRIO 9014 so I can't really speak specifically on how the 9073 will do.  There are two things I would watch out for.  The first is CPU usage.  When I did my testing, I ran 16 channels at 10 Hz on a 400 MHz processor cRIO and was able to keep the CPU less than 85% (the limit I feel comfortable operating at but not above).  The 9073 is a 233 MHz processor.  Therefore 8 channels at 10 Hz might be ok.  If you can have a slower control rate than 10 Hz, then you will probably be fine.  The second thing to look out for is memory.  The 9073 only has 64 MBs.  This will disappear pretty quickly.  Installing as little as possible on the cRIO and not publishing the IO variables over the network should help some.

[TLE]

The example uses basic TCP communication as opposed to network shared variables.  What are the trade-offs?

Also, with the introduction of shared variables, why does this recent example make no use of them?

Is IO forcing available or does it have to be built into the CVT VI's?

[Daniel_E]

For me, shared variables are meant for the viewing of static, asynchronous, non-buffered, single point values over a network.  TCP is for event/command based or buffered communication over a network, which is why all commands/messages in the application are sent via this method.  We actually do transfer asynchronous, non buffered, single point values over a network but don't use the shared variables because local shared variables (aka global variables) can't be dynamically accessed, which we need to meet the requirements of this application.  I hope this helps.

[TLE]

It seems to me that network shared variables serve the same function as the CVT framework but also allow IO forcing, scaling, and network communication.  Is there a performance advantage in using the CVT frame work and TCP communication?

[Daniel_E]

You are correct that shared variables are more user friendly and have more features.  While IO forcing and scaling does work on scan engine variable through the CVT framework (CIE tags) they don't exist for any other types of tags.  Again, the reason we used the CVT framework is for dynamic access of global variables, which shared variables don't offer.  The CVT framework does have a performance advantage.

[TLE]

What do you mean by "dynamic access" to global variables?  I like the fact that there is a performance advantage in using the CVT approach.  This will be important in my next application, I need to squeeze every bit out of my cRIO controller that I can.  Great example, by the way.

[Daniel_E]

If you look at the control loops, there are 16 of them.  They are all instances of the same VI (reentrant).  This makes the program much easier to update.  Instead of changing 16 VIs to update the control algorithm, you change the single VI and all 16 instances update.  To make this possible, we need to be able to dynamically select which variables are being used in each instance.  Specifically, when we start the control programs, you will notice that a 0, 1, 2, etc is passed into the control algorithm.  This is used to create a variable name specific to that loop.  This newly created string is then used to reference a CVT variable.  In this way, it is dynamically accessing these variables, allowing the code to be the same for each control loop, but still functioning with different setpoints, PID values, loop rates, etc.  If we were using global variables, we would have to have a 16 state, case structure with a global variable relating to the control loop number in each state.  Also, the cvt allow us to dynamically create variables, so scaling the code from 16 to 8 or 32 is very quick and simple.  Using globals would take much more time because of their static nature.

I hope this helps!

Dan

[TLE]

Yes, that explains what you mean by "dynamic access" of global variables.  In my case, I will be controlling many different types of equipment (motors, analog valves, solenoid valves, power electronics) so my control algorithm VI's will not be reentrant.  However, I can see other advantages to dynamic access.

Thanks again!

[N3MRA]

I am trying to shrink the file size on the output files.  I don't need it to report the process variable, heater status, etc, but I do need a timestamp.  Where do I modify which channels will be written to file?

[Daniel_E]

The Current Value Table (CVT) Data Logger (http://zone.ni.com/devzone/cda/epd/p/id/6279) is the mechanism for logging.  This resides in the VI named Data Logging Engine.  You should be able to filter the list of tags that is recorded in that VI.  The list is a global variable named CDL CVT Tag List and it resides in two states (Start CDL Process & Create New TDMS File).

I hope that helps!

[N3MRA]

I'll play with the CVT Data Logger and see what I can come up with.  I am having one other problem with this program:

The cRIO time drifts (and is probably 1/2 hour ahead of the current time).  I wrote a real clever routine to set the time each time the Temperature Controller is run, but really all it does is set its own time = to itself.  How do I convince the cRIO time to equal the current time (as is displayed on my laptop?)

[Daniel_E]

Hey,

When you say drift do you mean offset?  An offset in time is very common between cRIO and Windows and can be solved in a few ways.  A drift is something that can also occur but it should happen over multiple days or really weeks/months to add up to 30 minutes.  From your comment above, I think you are asking how do I make my cRIO time equal to my Windows computer time.  The way I would update the time on the cRIO is by creating a new button on the Windows host.  This button would trigger a new event that sends a message containing the current Windows time over the network via STM (Simple TCP Messaging Reference Library) to the cRIO.  The cRIO would receive this message and updates its time (same routine as what you are doing but it is set its own time = Windows time).  Another option is if the cRIO has access to the internet, you can use something like this.  Just run it at start up or every hour.

http://decibel.ni.com/content/docs/DOC-4394

Or you can do this if you have internet access or your own SNTP server.

http://digital.ni.com/public.nsf/allkb/F2B057C72B537EA2862572D100646D43

I hope this helps.

[jsiegel]

Has anyone tried to use this application with LabVIEW 2010 or 2011?  One of the reference libraries that this application uses, NI Scan Engine Advanced I/O Access (http://zone.ni.com/devzone/cda/tut/p/id/8071), provides the ability to read and write I/O values to an entire C Series module as an array, a feature that was added as native functionality in LabVIEW 2010.

When I install the NI Scan Engine Advanced I/O Access library, code gets installed to my LabVIEW 2009 directory but not to my LabVIEW 2010 or 2011 directories.  Can/should I just copy the installed files from the LabVIEW 2009 dir to LabVIEW 2011?  Will this library and its DLL still work correctly in LabVIEW 2011 in spite of the fact that LabVIEW 2011 provides its own native support for the functionality the library is trying to provide?

[Daniel_E]

I don't believe copying the code over will work.  You have to replace that API with the Shared Variable API (which is the native functions you referenced).  Unfortumately, it isn't one to one replacement but it is possible.

I hope this helps!

[jsiegel]

So this reference application seems to be out of date--is there a newer more appropriate reference application I should be using instead?  I haven't found anything that has all the features of this one, which matches very well with the functionality I need for my requirements.  If not, I'll try to replace the outdated library. 

I can see how to read/write a module's channels all at once in native LV2011 code, but it's not obvious to me how programmatically get a list of module names and their channel directions without using other external libraries--can you point me in the right direction for this?  Thanks!

[jsiegel]

Has anyone been able to successfully run this application on a cRIO-9073?  I uninstalled as much NI software as possible (except for the component to publish the I/O variables) as recommended above, but I either run out of space during the deployment, or I have less than 1MB free and immediately get an error -1950678964 (failed to load scan engine software required for I/O variable access) when running.  Presumably removing the NI component to publish the I/O variables will get me more space, but I'm concerned that it still won't be enough.

[Daniel_E]

Hey,

I have only been able to get it working on cRIOs with 128 MB of DRAM.  The 9073 has 64 MB.  I don't remember if I have all of optimization options selected in the build spec for the RT application so you could try that.  Specifically, you can make sure all block diagrams and front panel diagrams are removed (under Source File Settings of the build).  This will definitely decrease the size of the executable on disc.  I am not sure if this changes the size of the executable in memory.

I hope this helps!

[NI-hilator]

jsiegel, have you been able to get this to run on LabVIEW 2011?

[jsiegel]

NI-hilator,

Yes, I was able to get this to run on LabVIEW 2011, but as mentioned above, it wouldn't run on the 9073 (not enough memory), and I had to replace calls to the NI Scan Engine Advanced I/O Access library with my own custom VIs.

[NI-hilator]

Thanks.  I only have 9073s. I am also missing TWS Server.vi, Keyed Array.ctl and several FTP vi that look like there part of older version of ftp0.llb, ftp1.llb and ftp2.llb. 

[jsiegel]

I don’t know about TWS Server.vi, but Keyed Array.ctl is a VI that is part of a package that is a dependency of the AMC library.