LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Different application behaviour on different CRIO targets: compatibility issue?

Highlighted

Hi guys,

 

my RT application is for structural monitoring purposes and consists of a simple FPGA VI, a RT VI (these on RT target) and an Host VI (this on PC on the same network). FPGA put data in the FIFO, RT gets data from FIFO and stores data on memory in case of trigger event. Moreover, there is a network shared variable which I use to watch real-time data from Host VI on PC. Pc Host gets file on cRIo using ftp protocolol and send it to my remote server.

 

In my Pc for software development I have (in addition to Labview 2014 and toolkits):

- MAX 15.0 

- CRIO 14.5

- System Configuration 15.0

- NI RIO Drivers 14.5

 

I distributed applications (using installer for Host application and MAX for RT application) to 3 different targets:

 

CASE A

 

2x NI RIO 9075 

PC Host CRIO 14.0.1, MAX 14, NI System Configuratuin 14.5, NI-RIO 14.0.1

 

CASE B

NI RIO 9063

PC Host CRIO 15.0 MAX 15.0, NI System Configuration 15.0, NI-RIO 15.0

 

Software on RT targets was installed using the PC for developing, so the only difference between CASE A and CASE B is the software installed on Host PC. Obviously since targets are different (9075 & 9063) RT VI and FPGA are different too.

 

The application works fine with CASE A and not with CASE B (RT stops after 1 day)

 

Moreover, I don't know why I get this error at Host application startup (in both cases A & B) BUT when I press Run Anyway the software works...anyway. 

 

error.PNG

 

0 Kudos
Message 1 of 6
(1,175 Views)

Hi Dindex,

 

I found a document that explains the error and how to solve.

Speaking about the first point, so the VI that is stopped after one day of execution on the second target, does it give you any kind of error?

 

Thank you,

have a nice day.

 

FBM

0 Kudos
Message 2 of 6
(1,135 Views)

Hi Monchi,

I had already read that document but its not my case, it is obvious that Network variable engine is installed. 

I've found a workaround, anyway. Instead of using shared variables, now using shared variable nodes (programmatic access) it gives to me no errors. It's strange, isn't it?

Speaking about the other point, I have found that 9063 startup is slower than 9075 (also strange!) and that my control on number of elements in FIFO is too low: I have used the same number (25000) for an application with 12 sensors 250 Hz sampling rate (working) with the other with 24 sensors (not working properly). In my application I stop RT when the number of elements in FIFO is higher than that number (because I'm scared about cRIO crash/out of memory). The problem is that now that cRIO is actually crashed anyway (network adapter not working anymore) Smiley Happy and I have to get to there (70 miles from me) for rebooting. 

0 Kudos
Message 3 of 6
(1,123 Views)

The 9075 and 9063 run completely different operating systems (vxworks / linux RT) - so it's quite likely that they will have different bootup times. I believe there are some steps you can carry out to disable certain startup components to make them boot faster.

 

Network adapter not working anymore could be either that your application is maxing out the cRIOs CPU - this can make the cRIO unresponsive, even over the network. It's either that or the network changed and it couldn't assign a new IP address - it's usually better to configure the cRIO with a static IP address.

 

Are both of your targets in the same project? I wonder if the problem you ran into might be some weird issue around LabVIEW trying to compile/configure the various aspects of your project for the different targets.

 

I'd also suggest running the same software component versions on both cRIOs.

0 Kudos
Message 4 of 6
(1,115 Views)

Hi Sam, no, the projects are different, I created two different projects just to avoid this family of issues. 

The unresponsive cRIO has got a static IP. I think that its unresponsiveness has been caused by a manual restart from MAX when it was...restarting. The RT VI was indeed in "BAD" status and no other VIs were running, it is impossibile (I think) that CPU was overloaded. 

0 Kudos
Message 5 of 6
(1,108 Views)
Ah OK - then you are right, it's because one of the VIs on your target is bad which is why it isn't running. Are you building/deploying an RTEXE and setting it to 'run as startup'? Also, are you deploying your shared variable library automatically/as part of your build specification?
0 Kudos
Message 6 of 6
(1,085 Views)