check if real-time controller is connected to a PC

[Shinton]

I have some applications that run on a PC that call (deploy and run) a VI on a PXI target from the .lvproj.  However, I share the PXI with others (who use the same method).  If they are using it or if they forget to disconnect my application tries to deploy and run the VI but crashes because the real-time controller is already being used by another PC.  I would like to create a VI that would check to see if the PXI is busy (somebody else is already connected to it) so that I can run this test before trying to deploy my applications and thus fail gracefully.

I don't think any of the VIs on the Real-Time palette are what I'm looking for, so I tried opening an application reference and looking at what info I could get via property nodes.  It appears that there is some promise here, I might be able to make do with the "Remote Panel:Connections To Clients" or "NI Security:Nobody Logged In?", but neither of these can be accessed remotely.  I glanced at the invoke node, but nothing popped out at me, and I'm not really trying to invoke anything anyway so that seems like the wrong path.  I'm thinking that my only option is to create a standalone app that I can pre-deploy and that my PC applications will have to call that asynchronously via remote app ref?  I've never done that before, but I would imagine it is possible.  It just seems so complicated for such a simple operation...why isn't this built in to LV?  Am I missing something?

I apologize if this is a duplicate thread; I tried searching for the topic but didn't feel like I found the right keywords.

[christian_w]

use Measurement I/O --> System Configuration --> RT Software --> System Node --> ...  to get the information you need

You can also force a restart...

Hope it helps

Christian

[Shinton]

Thanks for the response, but that was actually the first thing I tried and couldn't find anything useful.  Which of the system node properties could I use?  The only option I found was "Real-Time:System Status", which seems to always return the string "Connected - Running" whether anybody was connected to it or not--even immediately after a reboot.  So I dismissed the option.  Were there other options that I overlooked?  Am I using this one incorrectly?

And resetting is often the fix for the problem, but I'm not looking for a fix, I'm looking for detection 🙂

[Shinton]

I forgot to mention that I'm using LV2012.  If this is already implemented in a newer version then I apologize for my ignorance.

Anybody else dare to confront the task?

[SkyWalka]

With your PXI target in the project explorer, you can always manually connect.  Right click the target and select connect.  This won't start the code deployment process, but it will let you know what is currently on the target.  You could also use the system config VIs to determine the CPU/memery useage.  This of course would require that you know what resources your colleague's code utilizes.

[Shinton]

SkyWalka,

Thanks for the reply.  I'm aware of the manual methods of checking, I'm hoping to find a programmatic method.  That is a good idea to use the System Config VIs, it might be a solution, but I wonder if the PXI retains the code in memory even after a user disconnects?  Maybe not, I'll have to check.

Anybody else dare to confront the problem?  I've tried everything I can think of short of creating a RT startup VI, I'm pretty much whipped.  I'm working on a new project now but I'll have to give the above suggestion a chance when I get back to that project.

[JÞB]

have you considered slapping those other developers that don't play nice with others?

While it will not get you a "Beloved developer of the year" award... It can be effective:)

In other words.  chat with yoiur development team and find a solution.

[Bob_Schor]

There is a Find.vi on the System Configuration palette that will do exactly what you want.  I use it myself to find the PXI so that I don't have to worry about coding in its IP address (what if it changes?).  

Bob Schor

[Shinton]

Bob,

Thanks for the reply, but I think one of us isn't understanding the other.  I'm not concerned about finding which PXIs are on the network and running, I want to check whether a PXI is currently connected to a PC (busy). 

I looked at the Find.vi, but if it *does* do what I'm looking for, it wasn't readily apparent.  The NI Help says that it finds systems that are in the "Connected - Running" state, and RT Controllers report that state whether somebody is connected to them or not.  Hence the Find.vi doesn't perform that distinction that I am seeking.

[Bob_Schor]

You are correct -- I do not understand what you want to do.  However, now that I have this out of the way, I'm going to "take a guess" and then say "I don't think you can do that".

I'm dealing with a 1 PC/1 PXI system, where the PC and PXI share a private network (so there's never a "worry" about multiple PXIs).  However, I want to be able to "control" what code the PXI is running, as I have multiple PC codes that are paired with multiple PXI counterparts.  This turns out to be a somewhat difficult task (that I haven't fully figured out), one "piece" of which is that I haven't figured out how to "know" what the PXI is running at any given time.

The solution that I'm drifting towards is to "force" the PXI to be in one of two known states (and to force the user to go and reboot the PXI if this proves to be false).  One state is running a Startup routine that "listens" for a command from the PC to load and transfer control to a particular "Real-Time Target" routine, which when it exits reboots the PXI (hence returning it to the Startup state).  The other "state" is executing the appropriate Real-Time Target routine.  Under this assumption, I never need to ask if the PXI is running, because I've programmed it to always be running. 

I do use Network Streams to communicate with the PXI, so one thing my Host routine could (and probably will)) do is to attempt to connect to the Network Stream Engine running on the PXI.  If it times out, then it is safe to assume that the PXI is not in a proper state, so I can get the PC to reboot the PXI, forcing it into a known state.

Hope this is helpful.  I'd be interested in your ideas and experiences.

Bob Schor