How to handle VIs without treating them as files?

[CoastalMaineBird]

What types of calculations are these?

--- They're creating pseudo-channels.  The example I gave is simple, but real: Power = Speed * Torque / 9550.  Others are way more complicated, such as Dilution Humidity Ratio, where they measure the Dew Point in degC, run it through a 10th-order equation, throw in the Barometric pressure  and a few conversion factors:

Any chance they could be saved as string formulas and parsed/evaluated using the Formula Node VIs? 

--- On my to-do list is a look at alternatives.  While this scheme works, it is subject to a few foibles: The version problem I have now, and the fact that my GLOBALS vi is fragile: Some of the plugins may use a global constant, such as MolecularWeightOfOxygen for example.  If I delete something that is BEFORE the MolecularWeightOfOxygen constant, then the compiled pre-existing VIs do not know about the change, and go looking for the value at offset 0x62A, just like they always did.  Only that's now some other number, or maybe something else entirely.

What I need is speed: In the PXI box, I have a 100-Hz main loop that is running TWO PID loops (controlling throttle and dyno on an engine), receiving ASCII data via TCP from FOUR gas analyzers at 10 Hz, receiving binary data from 12-16 cDAQ channels at 10 Hz (via TCP from the host), 30-40 ENET channels at 10 Hz (via TCP from the host) another couple of TCP instruments, 200 or so SCXI channels at 600 Hz (averaged down to 10 Hz), 3-4 COUNTER channels sampled at 10 Hz, about 10 Digital Output channels at 10 Hz,  and if they're feeling frisky, any number of DIGITAL INPUTS and DIGITAL OUTPUTS, not to mention a CAN data stream from the engine.

  So all that gets sampled at 10 Hz, and THEN I run the plugins, check alarms on everybody, assemble all the data and ship it off to the host at 10 Hz.  My CPU load is averaging 5%, but I don't want to put a huge dent in that, because we're not done adding stuff yet 🙂

  If the formula node could be compiled, then it might be good, but I dread the thought of interpreting the string every time.  I haven't looked at it so I don't know.

[CoastalMaineBird]

It's called Save:To Buffer, but since you got it working with the hash method, I suggest you continue with that, as private methods like this are not the sort of thing you want to use in a customer's app.

Yes, I agree.  I don't know how to access a "private" method, but it strikes me that Save:To Buffer might be slower since it's going to recompile the VI every time.  The hash idea brings to mind the old rule: You cannot make the computer faster - you CAN make it do less work. By caching the results of the recompile, I'm only recompiling each VI once, and the rest is just data movement.

Thanks for the idea though.

[Jarrod_S.]

---

@CoastalMaineBird wrote:

  If the formula node could be compiled, then it might be good, but I dread the thought of interpreting the string every time.  I haven't looked at it so I don't know.

---

The Formula Node functions can be precompiled. They don't have to interpret the string every time, and they get decent performance when precompiled. I certainly think raw LV code will give you the best performance by far in any case.

Also, there are some things that the formula VIs don't handle to my knowledge, like look-up tables. They are mainly built for handling basic composable arithmetic, exponential and trigonometric statements consisting of scalar values.