"Waiting for real-time target (RT PXI target) to respond" error when the program waits interrupts

[JPolo]

Hi there,

I have developed an application to detect interrupts generated by a electronic card and act in consequence. The program has been developed in labview but it calls a dll; that was created with labwindows. The dll is programmed to open the visa communication, enable events and install the interrupt handler and when an interrupt is detected, it reads the value of the different registers of the card and returns it to labview to visualize them. 

The problem is that when the program waits for an interrupt, a prompt appears with the message "Waiting for real-time target (RT PXI target) to respond" and the only option I have is to click on the button to disconnect from the pxi or just wait. If I wait and I generate an interrupt, the prompt disappears and the application visualize the data like it was expected. 

To wait for the interrupt the following code has been programmed in the function:

                while (flag == 0)

                {

                                Sleep (1000);

                }

When an interrupt occurs, the value of flag changes to 1 and the function continue without any problem. I am not really sure, but probably here is the problem and probably this is not the best way to wait for an interrupt because the sleep function suspends the thread for the configured time, but at least the computing load in the PXI is between 0% and 1%. I was wondering if somebody knows how to wait for an interrupt without "lost" the communication with the PXI and if there is a better way to do it. 

Any answer will be welcome and thanks for them,

Jaime

[Naity]

Hello JPolo,

I have a few questions concerning your application: 

First of all, in which thread runs the waiting process? Is it scheduled in another thread than the function setting the flag?

Secondly, I am not sure this method is the most elegant. You could for example register an event with the function and, insteand of setting a flag to 1, trigger the event and schedule it in another thread (if the function is thread safe). This could reduce your CPU Load even more and seem a bit cleaner to me.

Third point, which environment of development are you using?

Best regards

[JPolo]

Hello Naity,

First of all, in which thread runs the waiting process? Is it scheduled in another thread than the function setting the flag?

It scheduled in the same thread that I use to configure the communications and configure the card. Anyway, here is the pseudo code of the function interrupt that I programmed under labwindows,.

char* interrupt(void)

{

1. Open visa communications

2.Install handler interrupt --> status = viInstallHandler (instr, VI_EVENT_PXI_INTR, IntrHandler, VI_NULL);   // the function IntrHandler will be called when an interrupt occurs

3. Enable event PXI interrupt

4. Wait

while (flag == 0)

        {

              Sleep (1000);

        }

5. Visualize the data coming from the interrupt (registers and values measured with the card)

6. Uninstall handler interrupt

7. Close visa session

}

The interrupt handler function IntrHandler is called immediately when an interrupt occurs and the pseudo code is like this

ViStatus _VI_FUNCH IntrHandler(ViSession instr, ViEventType etype, ViEvent event, ViAddr userhandle)

{

1. Disable some functions of the card to avoid damages. 

2. Read registers and put them in a buffer

3. Change the value of flag ---> flag = 1;

}

In labview, I call the function interrupt with a call library function node (see the capture attached) and the program reads and saves the data from returned from the function.

Secondly, I am not sure this method is the most elegant. You could for example register an event with the function and, insteand of setting a flag to 1, trigger the event and schedule it in another thread (if the function is thread safe). This could reduce your CPU Load even more and seem a bit cleaner to me.

I've never used events before in labwindows but I will try to do it in this way. But anyway, I suppose that I should; somehow, wait the event to occurs in labview while the waiting for the event is programmed inside the dll...and probably the same prompt that i am trying to avoid is going to appear again, because I am not returning the "control" to labview (I mean, labview executes the dll and waits for the event to occur. Then the execution of the labview program is stopped in the call library function node executing the dll)

Third point, which environment of development are you using?

I am working with LV 2010 sp1 and Labwindows cv 10.0.1 and with the real time module.

I did also another test, I divided the program in different functions, one to initialize the communication, another to wait until a interrupt has been detected and the other to obtain the data from the interrupt and close communications. With labview I call first with the call library function node the function to initialize, later I call inside a while loop the wait function like this

int waitAseconds (double seconds, short stop_waiting)
{
	if(flag==1 || stop_waiting == 1)
	{
		flag = 1;	//to detect the stop_waiting button
		printf("flagAA =1    stop waiting = %d    time = %d\n", stop_waiting, clock());
		return flag;
	}
	else
	{
		SleepUS(seconds*1000000);
		//a++;
		printf("flag a= %d    stop waiting = %d   time = %d\n", flag, stop_waiting, clock());
		return flag;
	}
}

 and when the program detects an interrupt, the function returns to labview the flag and stops the loop. Finally, it reads the values and close communications. 

In this way, the prompt appears but after running the application for 10 or 20 minutes and also i checked that there is a time gap between the executions in the loop.

Thanks for your reply and your help,

Jaime

[Texas_Diaz · Accepted solution]

Hey there.

The reason you're seeing issues with connectivity is because the DEFAULT thread that CallLibrary Nodes run in is the User Interface (UI) thread - the UI thread also handles important things like, say, communications (most importantly all connections for the VI server) and some other things that you might want running all the time.  A CallLibraryNode is not, by default, intended to be used to run code that executes for a long period of time.  If you want to do that, you need to set the execution for the CallLibrary Node to run in the context of a LabVIEW Runtime Engine thread (by selecting for it to run "in any thread"), and not the UI thread.  This can be done via the properties of the CallLibraryNode.  By selecting "run in any thread" the DLL call will be made usually in the context of the currently running LabVIEW execution thread, which is usually what is intended anyway.  The CallLibraryNode VI color will change from Orange (UI) to Blue (LabVIEW Execution Thread) so you can quickly tell what context the call will be made in.  

The reason the UI thread is the default thread is because most often DLL calls need to be serialized (due to functions not being thread-safe) and so this protects the integrity of the system.  However, if you know your threads are thread-safe, or you're going to be using those threads for a while, it's best to schedule the CallLibraryNode to use a LabVIEW Execution Thread instead of the UI thread.

For more information on this check out these pages:

https://decibel.ni.com/content/docs/DOC-9069

http://zone.ni.com/reference/en-XX/help/371361J-01/lvexcodeconcepts/configuring_the_clf_node/

Happy DLL'ing.

-Danny

[JPolo]

Thank you very much Danny. I have to test it better, but it seems it's working!

[Sami88]

Hi,

I am getting the following error for NI 9505 module controlling a dc module with compactrio 9024 when trying to run the rt part of the code:

''Waiting for Real-Time target (NI-cRIO9024) to respond''. And surprisingly It was working perfectly for couple of runs. Any help is appreciated.

Regards,

Sami

[Raul2203]

Hello All,

Even I am facing some similar problem. I am getting the same error 'Waiting for real-time target (RT PXI Target) to respond'.

I dont get this error for lesser number of runs like 5-10 but getting this error for say 100+ runs.

I'm programming my RT PXI with Labview 14.1. Please help me in solving this issue.

Thanks in advance!

Rahul

Knorr- Bremse Sfs Gmbh

Munich, Germany.