Why does my sbRIO-9607 take 5 times longer for initializing a system configuration session?

[richtian]

Hi,

In my system, I want to get the SerialNumber of my sbRIO-9607 board, as well as the temperature values available. Hence, I install NI System Configuration module on my RT. However, I notice that, the session initialization takes about 33s when I upgrade to NI System Configuration 17.5. The value was less than 6s when I was using NI System Configuration 16.0. Hence, the response from the sbRIO is 5 times slower after the board is powered-up now. Should this be a bug, a known issue or an expected behavior? Could I do anything to get it improved? I find that all the input terminals of the Initialize Session VI don't help out. My test VI is attached below.

Thanks,

Richie

[Call.Me.Wilbur]

Hey Richie,

What you're seeing could be related to the last Known Issue (678951) listed here:

https://www.ni.com/en/support/documentation/bugs/18/max-17-5-and-ni-system-configuration-17-5-known-...

It's not the exact same behavior since the known issue mentions an error being thrown rather than hanging for several seconds. However, I think it's still worth looking into. Could you try the workaround listed in the document and verify that 17.5 is also installed to the sbRIO. This version mismatch could be the issue. If that doesn't work I think it's also worth trying an upgrade to 18.0 since this issue was fixed then. Even though the behavior isn't exactly identical there's still a chance that the root cause is related and these steps may work.

Will

National Instruments

[richtian]

Hey, Will

Thanks for the quick reference. I just want to double-check my understanding on 678951. According to the description, if my sbRIO is installed with System Configuration 17.5 while I'm deploying my VIs on a machine with System Configuration 16, for example, I will get an error 15. Am I right? In my case, I'm building a startup rtexe to run after powered-up. Is this affected by the issue? BTW, the environment to build the rtexe does have proper System Configuration installed.

I feel that the one I'm running into is not the same as that issue. It will take quite a while for me to download the 18.0 drivers. And I'm also worrying whether I will running into any other further issues after the upgrade. 

Thanks,

Richie

[richtian]

Hey, Will

Want to give you an update after several experiments. I've downloaded and tried the System Configuration 18.0. However, this software upgrade does not affect the time elapse used for initializing sessions. BUT, accidentally, I notice that the elapse difference actually might be because of something in HW. I played with three sbRIO 9067 at hands. Two of them take 32+ seconds for initializing session, while the other one takes only 4~5 seconds, no matter whether I install System Configuration 16.0/17.5/18.0 on the boards. Do you have any ideas on this?

Thanks,

Richie

[ATribo]

Hi,

Just to add to this. 

I've seen similar behavior on the NI SOM (sbRIO-9651). It appears to come and go. Sometimes I get a long startup, sometimes it throws -2147024809. Sometimes it's fine.

The error refers to this bug: https://www.ni.com/en/support/documentation/bugs/17/ni-max-and-ni-system-configuration-bug-fixes.htm...

However I'm using 17.5 with 2017 SP1. I wonder if it's because there in no LabVIEW Real-Time Module for 2017 SP1 (just 2017 has to be used).

Art

[GatorChomp]

Hey Richie, 

I have two questions to narrow down the issue a bit further.

1. How is the initialization time affected if you use the IP Address of the sbRIO as the Target for Initialize Session instead of the default localhost? I believe this avoids some extra IP Address translation.
2. Can you try bench marking subsequent calls of Initialize Session after the sbRIO is started? That is, if you close the session after the first attempt returns and benchmark the same code a second time, how long does that take? Note that you will have to close the session as SysConfig will reuse the existing session if you do not do so. 

EDIT: Can you also test the performance if you do not provide a user name input?

[richtian]

Hi, Charlie

For your suggestions, I've done some experiments.

1. No. IP address does not make any difference. Or, maybe I should put it like "There is no obvious difference.".

2. I create an RT exe which runs the initialization 5 times. For the first two iterations, I don't close the session reference, while, for the rest iterations, I do close the session reference. Here is a typical result: 33000ms, 2ms, 2ms, 380ms, 360ms. That's to say, the very first time is different from the rest, even if I close the session reference.

Besides, as Art mentioned above, I do notice that the time elapse for the first iteration could vary from 4000ms to 36000ms on a same board that I'm experimenting. But for the rest four iterations,  the numbers seem to be more stable, where almost 0 for the second/third iteration and 1/100 of first iteration for the fourth/fifth iterations.

3. A user name input does not affect the performance.

Thanks

Richie

[GatorChomp]

Hi Richie,

That sounds like a potential load order issue. I talked to someone more knowledgeable about Real-Time, and they suggested that waiting 20-30 seconds after the start of an RT application on Linux RT is a best practice to ensure that all dependencies are loaded into the LVRT process before running the application. I know that I've recommended similar steps for some issues in the past as well. 

With that being said, it should be possible to normalize the load time a bit more. I *think* that dependencies on RT will load in the order that they are installed from NI MAX. I'm not 100% sure of this for Linux Real-Time but know that this applied to the older PharLap OS. It might be worth reformatting one of the offending sbRIOs and installing SysConfig individually before installing the full software stack as a test. If my thought process is correct, then that should result in a faster load for the SysConfig libraries. 

[richtian]

Hey, Charlie

I tried to install the System Configuration as the first module or the last module but found no difference. Probably, the trick is N/A for Linux RT. Could you please confirm it with some Linux RT expert?

Besides, when you say "they suggested that waiting 20-30 seconds after the start of an RT application on Linux RT is a best practice", how should I implement it in my source code? Is that just to put a Wait function at the very beginning of the codes? It seems that this has no effect.

BTW, FYI, I'm building my codes into startup.rtexe so that I'm expecting it to be the first item to load, which will finally load all the dependencies at the same time.

Thanks,

Richie

[GatorChomp]

Hi Richie,

You should be able to put the wait in the first frame of a flat sequence structure and then the rest of your code in the second frame. That should accomplish what was described to me. 

If you need more on this, it might be best for you to open a service request to move the conversation there. I believe this specific forum is meant for sbRIO Hardware Development questions, and the problems you describe are more general sbRIO/LV Real-Time related.