[Bug?] DSC - Clusters Different between 'Read Alarm.vi' and 'Alarm and Event Query.vi" but Contain 'Same' Data

[jgcode]

Howdy!

Why are the clusters different coming out of the Read Alarm.vi and the Alarm and Event Query.vi when they have the exact same data?

The only difference is the order of two last elements.

I am leaning towards bug on this one, unless these clusters need to be distinct for some reason?

[jgcode]

Should have added [LV 2009]

Cheers

-JG

[RavensFan]

I agree it is a bug.  It seems to be present in LV8.6 and also LV2010.  I don't know if there is any reason NI would have intentionally defined those two clusters to be identical except for those two elements (#13, #14) to be swapped.  I'd say it is a failure on their part to define that cluster with a typedef.  In one VI the cluster is named data, and in the other it is Alarm.

I think the workaround for you would be to make a subVI that takes the cluster from one of them, unbundles the nodes, and rebundles them into a cluster using bundle by name and using a constant of the other type of cluster as the definition.

Based on what I'm seeing with the other VI's, the Alarm & Event query from the database palette is wrong, and the correct cluster is the one where the refnum element is the last element in the cluster.

[Ben]

This is yet another example of hwo DSC is the red-headed step child. I reported a simliar issue with historical trends in LV 8.2.

Can someone send a e-mail to SIngapore and teach them about type defs?

Ben

Ex-BridgeVIEW developer

[Ben_S]

jgcode,

Good Find!

This was reported to R&D as CAR #245619 for further investigation.

I think Ravens Fan is on the right track with his workaround suggestion for the time being. I apologize for this bug and the trouble it may have caused!

[jgcode]

Thanks guys, and thanks for the CAR Ben

Sad thing is I started out using the other cluster first - so when I came across this bug I did all my conversions the other way!

But I will take Ravens Fan advice and refactor it to go the other way to be safe 🙂

[RavensFan]

I decided to create the subVI.  I backsaved it all the way to LV 8.0 in case any older versions have a problem.  I put the the database URL and the error wire into this one wired through untouched so you can still access them without crazy wire bends.

One other discrepancy I found in the clusters besides the swapped elements is that the refnum in the Historical palette uses a U32 long integer, while the functions in the Alarms and Events palette use a U64 quad integer for the refnum.

 

[jgcode]

Thanks for posting Ravens Fan

I re-jiggered my API to reverse my datatypes then applied changes to my application code.

It wasn't that painful to update. 

My current understanding is that this bug affects one VI, so I decided it was easier to wrap that VI with the bugfix.

Attached is my implementation if anyone wants it too.

Cheers

-JG

[LV 2009]