Value signaling property does not work with Type Defs

[NickNZ]

The attached VI library (LV 7.0) demonstrates this issue.

What I was trying to do was to write an event driven serial port driver. For inputs it has a reference to a stop button, and a cluster containing VISA name, baud rate, enable button and running indicator.

The reference to the cluster is registered for a value change event. When a value change event occurs and enable is true then initialize the serial port and set running to true if the port initialized. Then in timeout event case read the serial port. If stop button changes to true then close the serial port and exit.

I was using the value signaling property as my program prompts the user for a serial port name to start with. Then I can use
a property node to check to see if running is set. So the value signaling property is being used occasionally so I am not worried about performance.

What I have found is that the cluster can be just a cluster, or a custom control and it works fine. If the cluster is a type def or strict type def the value signaling event is lost. This is what the attached example demonstrates. (It does not read a serial port rather it is a simple version I created to test the value signaling event to help me trace the problem back to my program).

Is this expected behavior?

I disconnected the clusters in my program from their type defs and it now works.

(Note I considered replacing the value signaling property with a generate user event, however I would still have to pass a reference to the running button to see if the initialization worked.)

[shoneill]

I had a similar problem with strict type defs with reading and writing values via references.

Strich type defs are very limited as to their reference functionality.


My Previous thread on strict type defs

Check this link to get to my previous thread. It`s got to do with LV 6.1, but maybe there`s some useful information there.

Shane

[NickNZ]

It just sort of seems to defeat the purpose of typedefs when you cannot use many of the property nodes.

To me the purpose of typedefs is to make it easier to add / remove controls without having to replace all the clusters.

On reading http://digital.ni.com/public.nsf/3efedde4322fef19862567740067f3cc/1b04fd6a11e6f17286256c6300588bfa?OpenDocument
carefully, the key point is
"The only properties available for a strict type definition control are those that affect the appearance of the control such as Visible, Disabled, Key Focus, Blinking, Position, and Bounds."

It is also annoying that the properties that are not available can still be used with no effect, without any compile error / warnings, runtime errors etc...

So I modified the set VI by wirin
g a property node to the strict type def reference. I used the control references propetry to get an array of references to the controls in the cluster. I then indexed the array to get to one of the boolean controls and set the value signaling property on the reference to the boolean button. This did generate an event.

Dispite what it says above the value signaling property did update the values on the type def controls on the front panel without generating an event. I also tried the value property and that updated the value of the type def control.

[shoneill]

I agree that the current implementation of a strictly typed control is (for my not-extensive knowledge of things) confusing.

I have written a VI to read/write to a cluster by accessing the sub-elements programatically (over References and parameters/methods). Contrary to what is stated in the document you have linked, I was able to write/read and so on everything in the cluster without problem. The problem came when trying to increment an array to read the different element data. THIS did not work, although I could write the array (within a cluster within a cluster) as a whole.

I have yet to hear a good reason as to why this is so. Until then, I avoid strict type-defs and stay with "normal" type-defs.

Shane.