Modifications Bitset Bug

[Jaegen]

(LV 7.1.1)

There appears to be a bug with the "VI Modifications Bitset" property:

1. In the attached llb, open "main.vi"
2. Open "Cluster" for editing (it's a type def)
3. Open "Sub1" for editing, and make a change to it (move a control slightly)
4. In the attached llb, open "ModsBitsetBug.vi", look at the block diagram, then run it
5. Notice that the "Mods.VI" property returns a different value for the type defs depending on whether it is above or below "Mods.Block Diagram"

Here is what I get:


Can someone confirm this?

Jaegen

Message Edited by Jaegen on 03-28-2007 12:08 PM

[jpeters]

I don't think this is a bug.

You get an error trying to read the block diagram mods on a control VI which has no diagram.  This makes the second property node not execute because you are propogating the error through.

Create an indicator on the error terminal for the property node and you will see what I mean.

Sorry for the inconvenience.

Jeff Peters

LabVIEW R & D

[Jaegen]

---

@jpeters wrote:

I don't think this is a bug.

You get an error trying to read the block diagram mods on a control VI which has no diagram.  This makes the second property node not execute because you are propogating the error through.

Create an indicator on the error terminal for the property node and you will see what I mean.

Sorry for the inconvenience.

Jeff Peters

LabVIEW R & D

---

Of course - I didn't think of this ...

However, if I right click on the property node and select "Ignore Errors inside Node", the behaviour is still the same.  Isn't this counter-intuitive?  This means that setting this true simply overwrites any error output from the node, but the node still stops executing if any property read/write causes an error.

Jaegen

[jpeters]

"However, if I right click on the property node and select "Ignore Errors inside Node", the behaviour is still the same.  Isn't this counter-intuitive?  This means that setting this true simply overwrites any error output from the node, but the node still stops executing if any property read/write causes an error."

I think that this is a bug and I see the same behavior here. 

I had to look in the docs to make sure.  According to them

"You can right-click the node and select Ignore Errors Inside Node from the shortcut menu to ignore any errors and continue executing further terminals. If an error occurs when Ignore Errors Inside Node is set, the property node still returns that error. The error out cluster reports which property caused the error."

Which is different than what we are seeing.  This has been reported as CAR 47RD7D00, if you didn't know that already.

[jpeters]

"You can right-click the node and select Ignore Errors Inside Node from the shortcut menu to ignore any errors and continue executing further terminals. If an error occurs when Ignore Errors Inside Node is set, the property node still returns that error. The error out cluster reports which property caused the error."

Hmm, taking a second look at it, I think that it is working correctly.  The first property node executes all of its properties and returns the error.  The second property node doesn't execute at all because of the error that comes in (from the first).

Sorry for the confusion. 

[Jaegen]

---

@jpeters wrote:
"You can right-click the node and select Ignore Errors Inside Node from the shortcut menu to ignore any errors and continue executing further terminals. If an error occurs when Ignore Errors Inside Node is set, the property node still returns that error. The error out cluster reports which property caused the error."

Hmm, taking a second look at it, I think that it is working correctly.  The first property node executes all of its properties and returns the error.  The second property node doesn't execute at all because of the error that comes in (from the first).

Sorry for the confusion. 

---

I don't think this quite explains it.  Look at this:




Even with the "Ignore Errors inside Node" activated for both nodes, I get errors and the result is the same.

Jaegen

Message Edited by Jaegen on 04-04-2007 08:45 AM

[jpeters]

Even with the "Ignore Errors inside Node" activated for both nodes, I get errors and the result is the same.

I think that this is because even if the error is ignored, it is still returned, so property nodes down stream will not execute.

[Jaegen]

Sorry, I'm confused.  What, then, is the purpose of "Ignore Errors inside Node"?

A) Don't output an error from the node, even if one occurs inside the node

B) Don't stop reading/writing lower properties if an error occurrs reading/writing a higher property in the list

C) Both of the above

D) Something completely different

For reference, here again is the text from the online help:

---

The node executes each terminal in order from top to bottom. If an error occurs on a terminal, the node stops at that terminal, returns an error, and does not execute any further terminals. You can right-click the node and select Ignore Errors Inside Node from the shortcut menu to ignore any errors and continue executing further terminals. The error out cluster reports which property caused the error.

---

I tried this (delete error wire into second property node):


But it still gave me the same results

Jaegen

Message Edited by Jaegen on 04-04-2007 09:30 AM

[jpeters]

B) Don't stop reading/writing lower properties if an error occurrs reading/writing a higher property in the list

Marking up the docs a bit for emphasis:

The node executes each terminal in order from top to bottom. If an error occurs on a terminal, the node stops at that terminal, returns an error, and does not execute any further terminals. You can right-click the node and select Ignore Errors Inside Node from the shortcut menu to ignore any errors and continue executing further terminals [in the node]. The error out cluster reports which property caused the error.

So basically this means that the property node will continue running on an error and then return the error that occured while running the node. 

[Jaegen]

OK, but then that means this is a bug, since my last test (deleting the error wire into the second node) did not work, right?

Jaegen