44 replies to this topic

[Steen Schmidt]

Yes, that's on purpose. I'm usually quite anal about wiring the error terminals, so it's quite rare I choose not to.

In this case the error in will always be "no error" due to the error-case before, and no nodes in between to generate an error. I thought only wiring from error out on the lossy enqueue underlined the fact that any error out of this case was from that node.

And as I write this I realize that any warnings coming in through the error wire will be dropped. I don't know if any warnings can be generated by the nodes before, as there is no way to tell which errors and warnings each LabVIEW function can generate. This means I also don't know if I really want to propagate any warnings or not... Oh well...

And I like nit-picking, it's a great way to improvement .

Cheers,
Steen

Edited by Steen Schmidt, 21 July 2011 - 12:52 PM.

[Steen Schmidt]

Hi.

Version 1.3 of VIRegister is now ready for download:



Version changes from v1.2:

- Warning propagation through 'VIRegister - Read.vi' improved (in response to Götz Becker's post).

Cheers,
Steen

Edited by Steen Schmidt, 03 August 2011 - 08:57 PM.

[Aristos Queue]

Sorry for been a nitpicker... but is the non propagating errorcluster implemented on purpose?

Functionally irrelevant to propagate or not since it is guaranteed to be "no error" in that case. But connecting it through will sometimes give LV the opportunity to use a single allocation of the error cluster all the way through the app, which cuts down on the size of the VI in memory (by a few bytes), so I usually do wire it.

[dgordon380]

Hi Steen,
I'm doing something wrong with the Read - there is no output pin! What am I missing? I'm using V. 1.3.
Thanks,
Doug

[Steen Schmidt]

Hi Steen,
I'm doing something wrong with the Read - there is no output pin! What am I missing? I'm using V. 1.3.
Thanks,
Doug

There's a bug in v1.3 that expresses itself this way. Please get v1.4 from the LabVIEW Tools Network.

Cheers,
Steen