Force Variable VI is very sloooow

[Greg G.]

It's not so much just that it's going through the network stack.  It is that it has to establish a connection everytime that VI is called, which takes awhile with the network protocol we're using.  Then the data has to be flattened into the network format, then unflattened, then processed, then the connection has to be closed. 

I agree that it takes a lot longer than one would expect though. 

greg

[viScience]

Hello again,

In my distributed cRIO system (9 cRIO's and 4 PC's) I have decided to use the scan engine coupled with an intermediate layer at the RT level to provide

additional features such as programmable channel scaling, filtering, dead banding, CVT binding, and Forced I/O which would be very handy for providing HMI's with 

a transparent means to go into 'manual' mode and override RT control of I/O resources.  I suppose I could live with a 900mS delay between when you push a button on the HMI

and an effect is produced in the cRIO hardware but I am afraid it would make my HMI feel very unresponsive and would be an embarrasing aspect to an otherwise well constructed design.

I would like to see if it might be possible to obtain some beta code that would allow me to temporarily get around this problem until LV 8.6.1, is that possible in the short term or should

I abandon the use of forced I/O for my application?

Thanks.

[sadiam]

If you are using remote HMI to force, then latency for forcing should be the same as it is from the System Monitor.  Any optimizations we'll make in the future will be for the embedded case (i.e. when the forcing VI is running on the target itself).  Host behavior is not that slow and should be responsive enough.  Have you benchmarked the host write (in my tests it was definitely <0.5 sec).

[viScience]

Thanks for your reply.  I am running my test case on a local cRIO-9074.  My test case forces an analog input channel on a 9237 module.  I am seeing ~900ms transaction times.  Could you please send me your example for comparison.  I have not tested it yet, but am thinking about using an asynchronous wrapper around the force variable vi so that at least it would not stall my HMI.

[sadiam]

If you are on RT then that delay seems right. If you are controlling the manual switch on the host, is there a reason why you are not including forcing call on the host VI as well? The force VI was really designed for the host usage, so you may want to benchmark it running from the host and see how it performs.

[viScience]

Yes you are correct, on the host it is around 200-300ms.  My dilemma is that I need to provide programmable I/O scaling and thus have had to funnel all my data through a scan engine data processor.  This decision has rippled through to such things as HMI data publishing where HMI I/O units do not match scan engine I/O units directly and thus I cannot directly force IO at the HMI level.  I guess I could add prescaling to all my AO and DO channel at the HMI.  The real god send would be NI providing a programmable I/O scaling API within the scan engine. 

[Greg G.]

---

sachsm wrote:
The real god send would be NI providing a programmable I/O scaling API within the scan engine. 

---

Can you describe in more detail what you mean by this?  Do you mean the ability to programmatically change the scaling currently provided on I/O variables?  Or something else?

thanks for your feedback,

greg

[viScience]

Yes, that is exactly what I need.  It is a requirement of the system I am designing to have an external spreadsheet containing mx+b scaling, filtering cutoff, zero offset, Deadband%, etc.  This informaion gets compiled and ftp'd to the targets.  If I could do the scaling directly in the scan engine then it would significantly simply my design.  Even if I knew it was forthcoming in LV8.6.1 then I might be able to defer and just manually enter all of the 100's of scaling coefficients directly in the project.  When the feature become available my configuration management tools would take over that responsibilty.

[Greg G.]

---

sachsm wrote:
Yes, that is exactly what I need.  It is a requirement of the system I am designing to have an external spreadsheet containing mx+b scaling, filtering cutoff, zero offset, Deadband%, etc.  This informaion gets compiled and ftp'd to the targets.  If I could do the scaling directly in the scan engine then it would significantly simply my design.  Even if I knew it was forthcoming in LV8.6.1 then I might be able to defer and just manually enter all of the 100's of scaling coefficients directly in the project.  When the feature become available my configuration management tools would take over that responsibilty.

---

Is the current scaling (mx+b) provided by IO variables plus a programmatic configuration API sufficient for your use case, or would you also need filtering cutoff, zero offset, Deadband%, etc?

thanks,

greg

[viScience]

Surely you are teasing me 🙂  Of course I would like all of the above since it will never be as efficient for me to have to intercept the scan engine data and process it myself.  Especially in regard to filtering since it would be

much better to do at the higher sample rates available in the scan engine.  My LPF currently runs at a sample rate of 50Hz.   But I think for now the greatest simplification would come from being able to externally manage the mx+b scaling.  Also a additional zero offset for on the fly calibration would be nice.  I understand you guys are trying to prioritize the most requested features and that managed mx+b scaling is high on the list.  Will there be any intermediate pioneer releases?  Can you state that it will be in the LV8.6.1 release?