Unmatching notifier vs. type declaration

[Kochise]

Hi, I have a permanent unmatching notifier with its type declaration, even though I tried and tried again to make them match.

All the other notifiers are OK, but not for Mux_CAN and Mux_VAN.

An idea, someone ?

David KOCH, Altran contractor

[Kochise]

Necessary files to try yourself.

David

[Hooovahh]

Wow....I've never seen that large of a cluster before.  And you choose to use silver controls, which makes it even larger.  I didn't know this until today but apparently the navigation window doesn't work on controls. 

I guess first I'll address your issue.  I opened it in LabVIEW 2013 and I couldn't make the data types happy.  But I opened it in LabVIEW 2014 and I was able to copy a constant of the correct type, and paste it into the cluster.  This means that there likely was a bug that was fixed between versions and someone at NI might have a work around for you in 2013.

I don't know what the rest of the application looks like, but I would highly suggest you try to compartmentalize parts of this data, so that it is easier to work with.  I know many developers would push for classes, so that the developer doesn't need to know about all the types of data buried inside and just deals with the methods, that would help too.

Another piece of concern is that there is just one type def cluster.  Did you disconnect type defs for the purpose of posting?  I would have choosen to have each cluster be its own type def.  That way you update it in one place and it updates every where.  This includes the data types that are used in the notifiers, so you can view the notifier as an icon, because you know the data type of it is typed.

[550nm]

Hi Kochise,

I repaired the Notifiers control in LV2013.

First modify the typedef to show icons (right-click on the Notifier symbol and choose "show-icon").  This will make it easier to associate a cluster with a specific notifier using drag/drop.

After that create a cluster of each type and drag/drop into the appropriate notifier icon of Notifiers type.

I'm attaching the working Notifiers typedef.

While the typedef is showing the (large) notifier-controls, it's difficult to drag/drop a new control without accidentally ending-up inside a nested cluster.

It happened to me, perhaps that's what was happening to you...

Hope this helps!

Cheers!

[Kochise]

@Hooovahh : thanks for the tip, but I'd like to avoid upgrading to 2014 because Labview will automatically "upgrade" all my VI libraries to 2014 and thus make them incompatible with our contractors that are still on 2013, without providing added  enhancement to the current code beside bug fixing that could have been provided as a new 2013 SP.

And I won't cut things into pieces, making them hard to follow in a complex nested hierarchy that requires you to open a trizillions VI and have your task bar stuffed with buttons like acnea. Here's the current main project's VI that uses several hierachised loops and event, but avoid as possible using sub-VI only when necessary (note Iplaced all the terminals on the far left and use only property nodes to access them).

I disconnected the types for testing purpose, just to see if that would help LabView to cross check the 'Reception' clusters for being exactly the same. Otherwise they are linked. The 'cluster de forat' allows external component to know the format of the cluster directly form the sub-VI without having to link the type definition from various places.

The silver controls were used because I copied them from the original sub-VIs to keep their format intact. I bet that the underlying data format is comon between silver and classic controls, just the widget presentation change. So I guess (hope) it's not an issue.

The CAN and VAN clusters are quite big because they are used to transmit a large load of informations. They were first directly linked to the command/indicators of the user interface, but I'm working on getting them out into an external and autonomous VI that could be called later from TestStand. Pretty tough work I can tell.

Please don't many too many comment about my coding style, I'm still quite a rookie in LabView. I know that I could 'factorize' a lot of code using command reference passing instead to duplicate the code, but since it is still a work in progress, that helps me to 'visualize' the inner construction and adapt/fine tune things precisely.

@550nm : you are my HERO ! That trick works like a charm. I don't quite understand what you did exactly, but you did it. Still, that's rather bothering to face these kind of issue when I copied exactly the 'Reception' cluster inside each corresponding notifier only to have CAN and VAN misbehaving. Just lost 2 days on this before requesting help.

[Hooovahh]

No where did I suggest you upgrade to 2014, I was stating that this appears to be a big fixed in 2014, and that NI may have a known work around in 2013.

There is nothing wrong with being new to LabVIEW.  But being new means that there is a wealth of knowledge from experts, that can help you become better.  That's why I was making suggestions like, compartmentalize code.  It helps make code that  scales well, and is easier for developers to understand.  Software architecture is an art form, and spending time up front to do it right is crucial for medium to large applications.

[Kochise]

Don't worry, I manage my Linux builds quite well. But working with text files is far more straighforward than VIs.

[Kochise]

OK, I've found out the main problem, Mux_CAN and Mux_VAN

were not pointing the right 'Reception' source cluster, while the

notifier definition type was corrersponding, hence the mismatch.

I looked too far for an error while it was, indeed, front of my eyes.

Sorry for the disturbance in the force.