Example of Dependency Inversion Principle using LabVIEW Interfaces (requesting code review)

[wiebe@CARYA]

---

@LucianM wrote:

---

wiebe@CARYA wrote:

'Official' data accessors (as created by LabVIEW) however, need to have an error in\out.

---

 Not necessary, there is a check-box to include error handling terminals. Most of the time I have that unchecked.

---

---

Didn't know that. Still not going to use them 🤣.

[wiebe@CARYA]

---

@LucianM wrote:

---

---

wiebe@CARYA wrote:

---

---

I wouldn't use error in\out from a Format Into String, except

1) when it looks better when I do.

2) when you need to pass the CLD exam.

---

 I usually wire it for the simple reason to save some bits in memory:) It seems LabVIEW allocates memory for unwired error inputs but it can reuse it if error in is wired.

---

That might be valid (not sure), but only if this doesn't require you to branch the error wire.

If you need to branch from an existing error wire, it's probably more expensive as the error needs to be copied. So you'd get the memory allocation and the copy of the data.

[DoctorAutomatic]

---

@crossrulz wrote:

---

@LucianM wrote:

---

wiebe@CARYA wrote:

'Official' data accessors (as created by LabVIEW) however, need to have an error in\out.

---

 Not necessary, there is a check-box to include error handling terminals. Most of the time I have that unchecked.

---

---

If you want to use the accessor as a property node, it does require the Error In and Error Out.

---

@LucianM wrote:

---

wiebe@CARYA wrote:I wouldn't use error in\out from a Format Into String, except

1) when it looks better when I do.

2) when you need to pass the CLD exam.

---

 I usually wire it for the simple reason to save some bits in memory:) It seems LabVIEW allocates memory for unwired error inputs but it can reuse it if error in is wired.

---

Most nodes in LabVIEW have a "stomper" flag to keep unused output from allocating memory, which can often propagate up to the input.  Even then, you are likely saving extremely few bytes of memory at the cost of eliminating parallelization.  A good general rule of thumb I've been hearing a lot lately is "do not optimize until absolutely necessary".

---

Now you two are causing me to have more questions!

What's happening under the hood with errors for accessors when called via property nodes? Is accessor error out terminal essentially what comes out of the property node error out?

What about if you have multiple properties being set/get on a single property node "block" (is there even a semi-official term for a property node that's been expanded to read/write multiple properties)? Is there simply a hidden merge collecting all error outs to put them on the property node error terminal or do the errors propagate through the whole chain? I believe, please correct, that multi-property property nodes execute serially from top to bottom (no parallel or non-deterministic execution order), it would seem to make intuitive sense (and I'm guessing easy for NI to implement) that they actually propagate from the top to the bottom passing through each one but I can see arguments to be made for an under the hood merge with the merge terminals matching the order of the properties from top to bottom. 

[crossrulz]

---

@DoctorAutomatic wrote:
I believe, please correct, that multi-property property nodes execute serially from top to bottom (no parallel or non-deterministic execution order), it would seem to make intuitive sense (and I'm guessing easy for NI to implement) that they actually propagate from the top to the bottom passing through each one but I can see arguments to be made for an under the hood merge with the merge terminals matching the order of the properties from top to bottom. 

---

That is correct that the properties are executing serially, top to bottom.  The error is propagated though all of the properties, which is why the Error In and Error Out are required.

EDIT: Adding a visual to make the point more clear.

[wiebe@CARYA]

You can turn the propagation off.

Right click the property, and select "Ignore errors inside". You'll see a red mark in the node. Now an error of the first property won't stop the next properties to be executed.

However, if there's an error in (to the block of properties), non of the properties is executed.

I'm not sure how that is handled if "Ignore errors inside" is off. The VIs might be called with an error in, or skipped completely.