Force Variable VI is very sloooow

[sachsm]

I am seeing execution times of around 500ms for a single I32 forced variable vi call.
Is this normal?

[altenbach]

What is a "forced variable vi call"?

[sachsm]

Sorry, I should have stated that it is used in conjunction with the I/O Variable Scan Engine to force a cRIO/FPGA resource to a fixed value for testing or simulation purposes. This post belongs in the RT section. BTW, how do you route a LV/RT question directly to the correct forum?

[TonP]

There is not a special RT forum, the link on the main forum page is mere a search routine. Ton

[altenbach]

Try <a href="http://forums.ni.com/ni/board?board.id=280" target="_blank">Real-Time Measurement and Control </a>
&nbsp;
When composing the message, there is a ring control above the subject field (:select Board")&nbsp;that lets you change the target forum. By default it is set to the forum you're currently in.

[sadiam]

As Greg mentioned, the forcing VIs are a bit slow on the RT target as we expected the main use case for them to be from HMI app going over the network and did not get a chance to optimize the local access case for this release.&nbsp; The performance for forcing VIs does not reflect the I/O Variable performance (which should run in the order of 10-15 us).&nbsp; In addition, the forcing&nbsp;VIs&nbsp;use some internal threads that run at normal priority, so make sure your system has enough idle time for these normal priority threads to get some execution time.
Also, we didn't expect forcing to be used for simulation (it was mostly for remote debugging from system monitoring).&nbsp; Can you share your use case a bit and tell us how fast of an access will work for you.&nbsp; For example, how fast of data sampling would you be simulating for your tests?
Thanks
-sadia

[Greg G.]

Unfortunately, yes, this is expected. May I ask how you are using this VI/functionality?thanks,greg

[sachsm]

Currently I am using the Force function just for simple testing. I am build a large scale system and am taking a chance on the new scan engine
and am concerned in general about the efficiency, performance and craftsmanship of this new technology. I was really surprised at the lag time
I was seeing and wanted to understand where it was coming from.

[Greg G.]

The lag time of that VI is because it allows forcing of something local or remote.&nbsp; In both the local and remote case, it goes through the networking stack.&nbsp; We could in theory optimize the local case to not go through the networking stack to improve performance in that case.&nbsp; Are you forcing variables locally or remotely?&nbsp; If you using the remote case, would it be helpful to have a "batch" version (ie, specify the forcing of a bunch of variables, then at the end say "go!")?&nbsp; Thanks for your feedback,greg

[sachsm]

Network Stack? How would that generate a 500ms delay? I think something is definitely wrong here. Perhaps
there is some sort of timeout or your software is trying to route via a DNS service in Timbuktu.

[Greg G.]

It's not so much just that it's going through the network stack.&nbsp; It is that it has to establish a connection everytime that VI is called, which takes awhile with the network protocol we're using.&nbsp; Then the data has to be flattened into the network format, then unflattened, then processed, then the connection has to be closed.&nbsp; I agree that it takes a lot longer than one would expect though.&nbsp; greg