Shared Variables, Scan Engine & Multiple Targets

[BrandonGT]

I am seeking some general advice about the structure of my LabVIEW project.

The project consists of a laptop with LabVIEW, and a joystick connected, and a CompactRIO connected via ethernet. I had been running the cRIO in FPGA Interface mode, however a change in some things caused the project to have to be shifted to scan mode.

As of now, the code on the laptop updates shared variables on the cRIO, and reads from shared variables on the cRIO for monitoring. I want the shared variables hosted on the cRIO because it will also need to operate without the laptop connected. Before switching the cRIO to scan mode, I found that I had to first run the laptop code, and then run the cRIO code, or the shared variables would not communicate properly. Now that I have switched to scan mode, I have to run the cRIO code first, and even then the shared vars do not communicate properly for more than a few seconds, and are much laggier.

My ideal project solution is a system that can run with or without the laptop connected, and obviously not having all these shared variable issues. I would like to autostart the code on the cRIO, and have the user run the laptop code if necessary, but in the past this did not seem to work with the shared variables.

I am really confused about why this is happening. Hopefully I have explained my problem well enough. I don't really want to post the entire project on here, but I can email it to people if they are willing to take a look at it. Thank you for taking the time to read this.

I am running LabVIEW 2010 SP1 with the Real-time, FPGA, DSC, and Robotics modules. I have the Feb '11 driver set and NI-RIO 3.6.0 installed and all completed updated on my RT cRIO.

[viScience · Accepted solution]

I do this type of stuff all the time...

Move all your NSV libraries to the cRIO.  From the project you must deploy to the cRIO and from then on they are persistant until you reformat.

From your windows HMI app, you can place static NSV tags on the block diagram or use the dynamic SV API to R/W.  Also you can bind HMI controls and

indicators directly to cRIO NSV's (This is what I do)  Also I create a 'mirror' library in the PC HMI that is bound to the cRIO library.  This library has DSC Citadel

data logging enable and will automatically save historical traces of all my important data - very nice.  PC hosted libraries can be set to autodeploy in the app build. 

also the project has a autodeploy option for the Development Environment which I normally turn off.  If you have PC to cRIO binding setup then you need to be cautious

about any sort of autodeployment since it will potentially force the cRIO app to stop when you deploy.  To get around this, you can use PSP binding (IP address rather than project

process name) and use the DSC deploy library vi's in your HMI app.  Once you are using the scan engine you can use the DSM (Distributed System Manager) app to view, proble and

chart all of you IOV and NSV's on your network.

[BrandonGT]

Thanks for the advice. I am new to binding libraries, and I have a question.

I have variables that I write to from the PC to cRIO, and also variables that I just read from the cRIO. Do I need to bind and locate these libraries differently? Does binding just make a second readable copy, or does it allow writes to be propagated back to the original library as well?

I also don't want the cRIO to error out when the PC loses connection with the cRIO, so to me that makes me think having a library on the cRIO bound to a library on the PC would be a bad idea. The PSP library thing is all new to me, so I will have to mess with that and see what I come up with. Thanks for the help!

[viScience]

Binding can work in both directions.  NSV binding is event based so only changes will propogate.  I think you can also setup a binding to be read only.

Bindings between a cRIO and a PC will not error out if the PC shuts down.  As long as your cRIO app does not try to programmatically R/W a NSV that is being hosted on the PC

you should not have any worries about this.  One cool thing about cRIO to PC bindings is that they gracefully accept dissconnect and reconnection.  For example, if the PC goes down and then restarts all HMI controls and indicators that are bound to a cRIO NSV just come back up working again automatically.  If they were set to log then logging also resumes automatically.

[BrandonGT]

I did what you said, and the first time I ran it everything worked beautifully. Unfortunately, nothing has worked properly since that first run. I tried to make a startup application for my cRIO, however it wouldn't communicate with the host machine. I have been running the code and trying to figure out the issues, and LabVIEW has crashed on me probably at least 5 times, so there is something not quite right. I also keep getting errors on my cRIO saying it could not read/write the shared variables that are hosted on it. I get -1950679035 and -1950679023 error codes on VIs on my cRIO. I know the bound variables thing is the better way to go, but as of right now I am getting worse results. Any suggestions? I can email my code to someone if they are willing to take a look. Thanks!

[viScience]

Can you post your code as an attachment?

Please send the whole project and dependant files.

Also what version of LV are you using?

[BrandonGT]

See if this works:

https://sites.google.com/site/gtsrasv/GTSR.zip

I am using LV 2010 sp1. Please by all means, let me have it. If the code sucks let me know (preferably with advice/suggestions!)

[viScience]

Just a few quick suggestions:

1. Turn off Autodeploy in both your My Computer and the cRIO target.  Manually deploy your libraries from the project.

2. Use the Distributed System Manager to check your cpu and memory % to make sure you are not maxing out. 

R/W NSV's are cpu intensive and this has to be watched carefully. 

3. Put in a few second delay on the cRIO startup to give the SVE time to become transactional.

[BrandonGT]

Thanks for the advice! It was helpful, and it ultimately led me to finding the bug that was causing my cRIO CPU to run at 100%. Once I fixed that, everything worked perfectly.

[No Substitute]

I had a similar problem that caused me to abandon that approach.  What was the bug that you discovered?