Board arrived ahead of estimated schedule, staff sent a link to the LabVIEW download. Installation extra smooth, recompile 100% seamless (not one squeak out of LabVIEW 2013)
Examples showed up in the “Find Examples” pane. A Very Nice Touch. A couple of “get familiar” VIs written and so far, It’s All Good.
A couple of questions…
Each of the VIs I’ve seen have two inputs for references to string indicators being used as buffers. In the examples, the same pair of references is passed to each VI in the “chain” of execution.
- Is there a dependency in the VIs as to the contents of the string buffers? That is, if one VI stores something in a buffer then does another VI rely on that data for its operation?
My LabVIEW program contains multiple while-loops with different loops controlling different relays (some relays are in one bank, some are in others). Looking at a couple of your driver VIs, I do not see re-entrant execution enabled.
2(a). It sounds like using a semaphore to “protect” access would be a good idea. But with what granularity? By default, LabVIEW serializes access to same-name VIs across the entire program. But this means its free to run a VI in one loop, then run the same VI in another loop. Semaphoring would “lock” the execution sequence, reducing granularity but guaranteeing that all of one chain runs without interference from another chain.
Defeating the serialization mechanism by allowing reentrancy sounds like a disaster with regards to the string indicators.
2(b). This takes me back to the use of the same string indicator buffers everywhere. It’s my “style” to enforce serial execution within a structure by connecting the error “wires”. But parallel execution with LabVIEW “flipping” execution between loops and using the same buffers? It almost sounds as if each loop should have its own set of Rx/Tx buffers. Yet if there is dependency on the contents left in a buffer by the previous execution of another VI…
Your time is appreciated.