Unable to use cluster of references in subVI (error 1055, invalid references)

[LabNEW90]

Hi there,

I am trying to pass a bunch of refences to through a cluster to a SubVI.

The idea here is to manipulate the Objects in the MainVI in the SubVI thorugh property nodes, which get the reference number from the cluster.

In the SubVI I use unbunling by name to acess the references I need. However, I get an error 1055 (invalid references) every time I try to access the object using the property node.

What am I doing wrong?

Attached you may find three files:

The mainVI: Main.vi

The subVI: Single_Cam_RefBased.vi

The type def. for the cluster: RefClusterTypeDefinition.ctl

Thanks in advance,

Marcel

[SteveChandler]

The constant you have wired to the bundle is not the same as the type defined cluster wired to your subVI. You can tell by the red coercion dot at the input. Right click on that input and create a constant and wire that to bundle by name. But you don't have anything wired to the uninitialized shft register in your while loop.

[altenbach · Accepted solution]

---

@SteveChandler wrote:

The constant you have wired to the bundle is not the same as the type defined cluster wired to your subVI.

---

I was going to say the same thing. This should be the first thing to try. (I have not studied the subVI but it looks buggy too...)

COMMENT: Still something is screwed up in the current VI that makes no sense. Hovering over the terminal should tell us information about the corecion, but in this case it says that the terminal is something like an error cluster. This might just be a cosmetic bug....

[SteveChandler · Accepted solution]

Also there are event structures in the subVI where the state date is not wired through in the timeout case.

EDIT: I've been away for a while. I see you have a new avitar Christian! Good to see you are still around 🙂

[LabNEW90]

Thanks a lot!

I don't know why but somehow the terminal type of the cluster was wrong when it was auto-updatig from the type def.

I have disconnected it from the type dev, and now this strang error cluster terminal has vanished.

Further the cluster pipe through the event structures has been finxed and now it is running smoothly!

However, I am still wondering what was wrong with the type def.?

[GregSands]

COMMENT: Still something is screwed up in the current VI that makes no sense. Hovering over the terminal should tell us information about the corecion, but in this case it says that the terminal is something like an error cluster. This might just be a cosmetic bug....

Because we shouldn't discuss bugs in the Bug Thread, let me note here that it is not just a problem with a typedef cluster of references, it appears to be that any typedef input that is coerced (wired with a non-typedef) is shown in the help window as requiring the type of one of the outputs.  For example, taking "Write JPEG File", creating then disconnecting a constant for the image data gives this:

I thought it was always picking up the top-right output, but doing the same with "Unflatten Pixmap" gives the U8 array opposite.

[altenbach]

Interesting. If I remove the subVI output terminals, suddenly the thing looks a little bit more sane. Definitely a bug.

[GregSands]

Just tried a few more things:

• it doesn't have to be a cluster input - any typedef gives this
• it also gets it wrong the other way (wiring a typedef into a non-typedef input)
• it also seems to get confused on wiring to a Bundle or Bundle By Name - the help window gives the data type of the whole input cluster:

I can't pick up a pattern for which output terminal it chooses to display though it's usually the upper-right (for VIs), and I've only looked in 2012 so I don't know if it exists elsewhere.

[NateBraska]

Hi All,

This issue with Context Help issue was reported in CAR 373416.

In my tests, this issue seems specific to Context Help. All the actual data coercion seems to function as expected, correct? Thanks!

Thanks,

Nathan

[NateBraska]

Edit: After further investigation, CAR 480726 is a more appropriate for this issue. Thanks!

Best Regards,

Nathan Burke

Product Support Engineer | LabVIEW R&D | National Instruments | Certified LabVIEW Architect