Waiting for the target to respond (NOT caused by high CPU)

[Oreki]

Hello,

I have recently run into this problem. After reading some threads I thought this is also caused by high CPU usage when in fact it is not.

Reasons: The total CPU% is usually around 10%.

Setup: This CompactRIO 9068 (Let's call it A) is configured with a router and 3G module as communication. It is located somewhere without direct Internet access. It is monitoring a three-phase hardware device.

My thoughts: I have another set of equipment (B) configured with static IP and connected through Ethernet port and running the exactly same LabVIEW VI as A. B has never run into such a problem. The only difference between the two equipment is the network, which makes me think that the problem is the low-speed 3G.  

However, my data reporting frequency is like 10s/sample and 3G should be more than enough to do the job. This kind of confuses me. I want like to hear your opinion on this. Thank you!

EDIT: This equipment was running smoothly for the first 10 days after implementation. There was no problem whatsoever. It just appeared like last Sunday.

[nanocyte]

Can you narrow down when you see the "waiting for target"? Is it when you first run your application? Does it happen the second time you reconnect and run your app? The message itself is not a huge issue but if it happens over and over I can see how it would be an annoyance.

Are you connecting through a VPN? If not, you might have issues with port forwarding.

Also, you might want to try adjusting one of the connection detection timeouts on the host:

http://digital.ni.com/public.nsf/allkb/B746EA10EA65BE894825733D006BEA8F

[Oreki]

It appears right after deployment and would just stay there forever (until I click stop waiting and disconnect). The thing is, data collection goes on despite this issue. I have all the data for the past couple of days. The only problem is that I cannot monitor anything directly.

Also interestingly, I added another data reporting function block today and it somehow got stuck and can no long report data. When I host it from another desktop, it starts working again (somehow it gives less "waiting to respond" sign and data get transmitted into the database). For data reporting, I am using HTTP post.

And I just add an edit to the original question. For the first 10 days of deployment, everything was fine. The message seemed to be popping up in the middle of nowhere.

I am not connecting through VPN. I believe you are correct. There is some problem with the port forwarding. I can connect to the target through LabVIEW but I cannot see it from NI MAX or anything else. I have not tried to reboot since any reboot command cannot go through.

[nanocyte]

You might also want to look into how you use indicators. Every indicator on your front panel is going to use network resources in development mode. 

[Oreki]

Hi nanocyte,

I have deleted all unnecessary indicators and the remainders are just communication feedbacks. Still, the problem persists. Well, I guess I will make do with it for now. I will post again if I see something. Thank you for your advice!

[nanocyte]

You might want to see if your cell router has VPN functionality. If it doesn't you might need to find a router or some other appliance to provide a VPN. That should get all the ports forwarded correctly. There's a few open source software based VPNs too. There's an outside chance that with enough work you could install one on your RIO. I would only try that after you try the first options to make sure that's the path forward and it's not something like bandwidth.

[Oreki]

Thanks! I will look into it. They're indeed some problems with the router and port forwarding and I am trying to figure out how to access CRIO from MAX with port forwarded.

[MrJackHamilton]

Oreki,

There is a slight chance it's a issue with non-static IP system timing out on the DNS server. I typically configure my cRIO systems with static IP. Additionally, Set the DNS address to: 127.0.0.1. This is the 'loop-back' DNS address, which essentially tells the device there is no 'internet' or DNS server and to use the IP address directly without attempting to resolve the address via DNS.

If there is no DNS server, the initial connection can take a long time the first time (waiting for host), because once the DNS address resolver times out, it will then connect using the IP address. The timeout is like 10 seconds.

Regards

Jack Hamiton

[Oreki]

Hi Jack,

Thanks for the clue!

Best,

Ethan

[petrus.prins]

Many years later...
My external fibre line went down and then my sbRIOs started to timeout for 10 seconds.... that DNS 127.0.0.1 entry is the payload right there.
Thanks!