Jump to content
Sign in to follow this  
patufet_99

sbRIO Shared Variables deployment very slow

Recommended Posts

We have an application where we communicate to a sbRIO target through Shared Variables. When the host/target are both on the local network all works fine (both are configured with a Static IP address). When both are connected directly with an ethernet cable, the deployement of the Shared Variables on the sbRIO target is extremely slow (5-10 seconds). This behaviour happens only if a DNS server address is defined. As the Shared Variables are deployed locally on the sbRIO, why the DNS server (if there is none) should have any effect on the deployment? Any hints?

Share this post


Link to post
Share on other sites
On 9/16/2018 at 9:40 PM, patufet_99 said:

As the Shared Variables are deployed locally on the sbRIO, why the DNS server (if there is none) should have any effect on the deployment? Any hints?

Here is my guess:

  1. Your PC tries to contact the DNS server at the defined address.
  2. The PC waits for a response from the DNS server. However, since the DNS server is not reachable, there is no response. So, the PC waits 5-10 s until the timeout is reached.
  3. After the DNS server connection times out, the PC proceeds to do its next task: Deploy shared variables.

When both devices are on the network, step #2 is very fast so you reach step #3 very quickly.

Share this post


Link to post
Share on other sites

Thank you for your comments. This seems to be as you mention and due to DNS timeouts as explained in the 2.2 of the upper link.

JKSH: This is on the RT side, not the PC: if a non valid DNS server is defined in the PC there is no problem.

As you say, section 2.2:

Quote

2. Check the DNS IP on the RT target.  If this IP is set to something that is not a valid DNS server, the shared variables will update slowly due to DNS timeouts that occur.  By changing this entry to 0.0.0.0, the shared variables should update at the appropriate rate.

So this is clearly the expected behaviour.

I just wondered of the reason: the call to shared variables on the RT side are all Target Relative to the local target. It's on the PC side that the PC are accessed through direct IP by programmatic Access.

 

Share this post


Link to post
Share on other sites
20 hours ago, patufet_99 said:

Thank you for your comments. This seems to be as you mention and due to DNS timeouts as explained in the 2.2 of the upper link.

JKSH: This is on the RT side, not the PC: if a non valid DNS server is defined in the PC there is no problem.

Here is my updated guess: ;)

  1. The sbRIO first tries to contact the DNS server at the defined address.
  2. The sbRIO waits for a response from the DNS server. However, since the DNS server is not reachable, there is no response. So, the sbRIO waits 5-10 s until the timeout is reached.
  3. After the DNS server connection times out, the sbRIO proceeds to do its next task: Accept a shared variable deployment from the PC.

In a nutshell, it looks like networking and the Shared Variable Engine are synchronous. While the sbRIO is waiting for a response from a remote device, it cannot process any other network requests related to Shared Variables.

I've seen similar symptoms in another case: My CompactRIO was trying to read a Shared Variable hosted on a PC. However, my PC's firewall was not configured properly so the cRIO was not allowed to read the SV. As a result, all other Target-Relative variables hosted on the cRIO froze for long periods of time

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.