LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

"Waiting for Real Time Target ( PXI) to respond" when running parallel VIs

Solved!
Go to solution

Hi all,

 

I am running into an issue in LabVIEW 15 where i am running two parallel VIs with timed loops on my PXI. One VI serves as a UDP write function, sending frequent strings of data to another device. The other VI serves as a UDP receive function, receiving data from the exact same device.

 

I am not sure if these details will help, but the target device is a windows PC running a VxWorks emulator. 

When I only run my UDP Write VI, i get no issues and i can see the data being updated and displayed in my target device (emulator). However, when i run both, i start to get this message:

"Waiting for Real Time Target ( [PXI model] ) to respond", and it gives the option of disconnecting my PXI.  

This message will appear for a few seconds, and then seem to reconnect.  It will continue to do this every few seconds.

 

I opened the 'System Manager' to view the PXI CPU and memory usage, but there is nothing abnormal about them. 

I was wondering if anyone could help me understand what is going on and how this can be corrected. I included my two VIs as well for reference (UDPMain.vi is the UDP Write, the other one is the UDP receive)

 

Thank you !!

Download All
0 Kudos
Message 1 of 8
(2,983 Views)

OK, so here are some questions:

  • Why are you using a Timed Loop at all?  What is "clocking" UDP_Main?  Is the loop the "timer"?  It isn't clear from your diagram.  But if the "clock" is somewhere else, then Data Flow will clock the transmission for you, and you can simply use a While loop.
  • Why use UDP?  Network Streams are way more robust and much easier (for me, at least) to understand and use.  And there is data integrity, which I find pretty important.
  • If you must diagram "in freehand" (I counted over 13 "corners" in the UDP reference wire, which should have no corners at all), at least learn to use the CleanUp (Broom) function before foisting your Block Diagrams on us.  It will help you, too ...

Bob Schor

0 Kudos
Message 2 of 8
(2,935 Views)

Hi Bob,

 

Thanks for the response. 

To answer your questions:
1) My understanding of what the Timed Loop is meant for was not very good. I think you are right, and that a while loop will be good enough for what i am doing (the clock is coming from somewhere else). I've switched to a while loop and the UDP_Main.VI still functions as intended.

 

2) I have to use UDP as the target device is a computer running real time software for a motion base, and UDP is apparently the standard interface for motion applications.

 

3) Apologies for the messy diagrams. I'm naturally a disorganized person, but I forgot about showing courtesy to those who i am asking for help from 😛 I will keep this in mind for the next time 

0 Kudos
Message 3 of 8
(2,928 Views)
Solution
Accepted by topic author bkcw95

How many computers are involved in this Project?  I've got a routine that uses a PXI (as I recall, an NI PXI-8106 in a PXI-1000B chassis), and I count two computers -- a PC running Windows 7 and LabVIEW 2016, with the LabVIEW Real-Time Module, and the PXI Controller running a Real-Time OS (I think PharLap) and running LabVIEW 2016 code deployed to it.  As both computers are running LabVIEW, I use LabVIEW Network Streams to handle communications between them.

 

When you describe a PXI system, is this running an NI PXI Controller?  What OS is running on the Controller (it could be Windows, but that doesn't make a lot of sense to me, as it throws away some of the Real-Time ability of the PXI hardware).  What is the "other" computer in this equation?  What software and/or programs is it running?

 

If you are connecting to a system that is running proprietary software that you cannot change, then you may have to "byte the bullet" and figure out how to make UDP work for you (with my sympathies -- lower-level protocols are always trickier and messier).

 

Bob Schor

0 Kudos
Message 4 of 8
(2,915 Views)

@bkcw95 wrote:

Hi Bob,

 

Thanks for the response. 

To answer your questions:
1) My understanding of what the Timed Loop is meant for was not very good. I think you are right, and that a while loop will be good enough for what i am doing (the clock is coming from somewhere else). I've switched to a while loop and the UDP_Main.VI still functions as intended.

 

2) I have to use UDP as the target device is a computer running real time software for a motion base, and UDP is apparently the standard interface for motion applications.

 

3) Apologies for the messy diagrams. I'm naturally a disorganized person, but I forgot about showing courtesy to those who i am asking for help from 😛 I will keep this in mind for the next time 


This is NOT just "common courtesy".  Disciplined block diagrams contribute to AND are the result of disciplined programming.  LabVIEW "best practices" were NOT developed for "common courtesy"; rather, they were developed to avoid lessons painfully learned.

 

I just got done troubleshooting a miswiring error that was not obvious because the block diagram was not documented and had wires running backwards and all over the place.  Now this miswiring should have been caught by just running PASSing and FAILing fake data through the calculations and noticing that the observed results did not match the expected results, but that didn't happen.  If wires were labeled and the block diagram reasonably organized, the miswiring would also have been immediately noticeable.  (A simple BD cleanup made it painfully obvious.)

 

The industry I work in is heavily regulated by the government; every change to the test software generates huge amounts of paperwork and consumes many engineering hours to complete.  After adjusting for the time to complete the required gov't paperwork, my time spent alone was worth a few thousand dollars to fix an issue that could have been easily avoided by spending five engineering minutes documenting code and keeping code readable.  Not to mention the technician hours spent reporting the issue and the staff hours spent reviewing the issue and approving the work order to fix it.

Plus, because it is a test escape, the gov't has the right to have all our units returned and having us re-test with the fixed software - on our dime.  I don't think that will happen because we can make a case that the issue would have been caught at the system level, and they will probably agree, but exposure didn't have to happen.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 5 of 8
(2,907 Views)

Hi Bob,

 

Good news, I found out what the source of my issue was. Turns out it was caused by having indicators for the port and IP out of the UDP Read block.

 

Just want to express my thanks for trying to help me troubleshoot this regardless 

0 Kudos
Message 6 of 8
(2,886 Views)

Understood Bill, thanks for the insight 

0 Kudos
Message 7 of 8
(2,884 Views)

@bkcw95 wrote:

Understood Bill, thanks for the insight 


Unfortunately my world isn't so different from Dilbert's.  😉

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 8 of 8
(2,859 Views)