From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

crio pxi shared varialbe

I have a project that contains a PXI and a cRIO.  The users getting data from the cRIO also need the time from a shared variable in a library hosted on the PXI.  I need to build a startup.rtexe for the cRIO and stand-alone apps for the user computers. 

 

1)  is the best way for the users to see the time from their apps using indicators data bound to the shared variable on the PXI?

2)  I need to write the time to a TDMS file on a user computer.  Should I use the shared variable for the same purpose?

3)  how does this affect deployment for the startup.rtexe for both the PXI and the cRIO?

4)  is it correct to assume when I build the stand-alone apps for the users I will need to include the shared variable library from the PXI?

0 Kudos
Message 1 of 20
(3,061 Views)

You have three connected devices, a Host PC, a Remote PXI, and a Remote cRIO.  All have clocks, and all have Time-of-Day.  Which one do you want to use as the "real" TimeStamp for your data?

 

I faced this problem with a two-device LabVIEW-RT system (PC and PXI).  I decided that the PC, connected to the Network and running Windows, which could (in principle) time-sync to a Standard, would be the Time-of-Day "master".  Within the Host and Remote software, I keep "time-of-execution" clocks, namely the number of milliseconds since the respective Programs started.  For timing within a system (for example, at what time did Line 3 go high?) I use the respective System Elapsed Time clock.  I've done some checks, and corresponding events on the two systems largely agree on the time differences beween corresponding Events, though the clocks are offset from each other.  [I've thought about whether or how to set the clocks to a common base, but that would involve figuring out the speed of TCP/IP traffic between them, and I'm not sure what real utility this would bring ...].

 

Bob Schor

0 Kudos
Message 2 of 20
(3,044 Views)

You can use network shared variables and enable the RT FIFO, however as he said the systems have different clocks and making the configuration is going to be tricky. Please check this document on the RT FIFOS section.

http://www.ni.com/pdf/products/us/fullcriodevguide.pdf

 

I really not know how using both systems at the same time will work.

Randy @Rscd27@
0 Kudos
Message 3 of 20
(3,016 Views)

Currently I'm getting an IRIG timestamp from a 6682 card on the PXI and sending it via Shared Variable nodes to the cRIO.  Two  Shared Variables are involved; one [Timestamp1] in a library hosted on the PXI and one [Timestamp2] in a library hosted on the cRIO.  When I build the startup.rtexe for the cRIO do I need to include the library from the PXI?  If so, how do I do that?

 

The multiple PCs use Shared Variable Node and data binding of indicators to a Shared Variable [Timestamp2] in the library hosted by the cRIO.   If the PCs need to be stand-alone applications, do I need to include the library from the PXI?  If so, how do I do that?

0 Kudos
Message 4 of 20
(3,005 Views)

Hello Faustina can please tell what library of the PXI?

Randy @Rscd27@
0 Kudos
Message 5 of 20
(2,978 Views)

PXI Library contains Shared Variable Timestamp1.  cRIO Library contains Shared Variable Timestamp2. Main VI on cRIO Timestamp1 = Timestamp2.  How do I build and deploy startup.rtexe on cRIO?

 

VI on PC reads Timestamp2.  How do I build and deploy stand-alone app?

0 Kudos
Message 6 of 20
(2,974 Views)

clarification

 

Main VI on cRIO reads Timestamp1 and writes value to Timestamp2.

0 Kudos
Message 7 of 20
(2,971 Views)

I believe you should create another shared variable on the cRIO that periodically reads the value of the PXI shared variable.

Randy @Rscd27@
0 Kudos
Message 8 of 20
(2,961 Views)

But when I try to deploy the startup.rtexe for the cRIO it gives me the following warning for the VI (part or PXI's startup.rtexe) running on the PXI

 

The VI is part of a Real-Time Startup Application.  All VIs on the target will be closed if you choose to apply and continue with deployment.

 

I don't want to change ANYTHING on the PXI.

0 Kudos
Message 9 of 20
(2,954 Views)

With libraries on multiple machines, you really need to give serious thought to how you get the various applications to start up, particularly if there are "start-up dependencies".  You don't want to get into an "argument" where the cRIO starts, is waiting on a resource from the PXI, then the PXI starts, but needs a resource (not yet available) from the cRIO, and the PC needs resources from both.

 

It would seem to me simpler to have the resources "hosted" on the system that is most likely to be turned on first, and remain on "most of the time".  For my LabVIEW RT Project, PC and PXI, I use Network Streams instead of Network Shared Variables (in my experience, Streams were much more reliable and faster).  The PXI is basically "always on" (it reboots when I exit the program, re-running its Startup, which is the RT part of my Project, and basically goes into a "Listening loop" waiting for the PC to run and request the creation of the (four) Network Streams.  Needless to say, the first thing the PC routine does is reach out to the PXI and ask for the Streams.  Once this is done, both routines start their business.  If I were to add, say, a cRIO into this mix as another co-processor, I would do something similar, again with the "always-on" PXI hosting the cRIO-PXI Streams.

 

Bob Schor

0 Kudos
Message 10 of 20
(2,950 Views)