What Data Structure Would You Use?

[Testy]

The problem:

I have a digital channel that can be configured as an input or an output. If it is an input, I only car about seeing its state. If it's an output, I want to be able to configure it as either a simple digital output (on/off) or a PWM output (frequency and duty cycle). I want to be able to request the state of this channel, and I want my views to receive an update when its state changes. How would you express the state of this channel in a LabVIEW data type?

 

This idea was shot down: https://forums.ni.com/t5/LabVIEW-Idea-Exchange/New-Enum-Class-Primitive-quot-The-Defined-Enum-quot-with/idi-p/1904525

 

However, if this idea was a LabVIEW feature, it would allow this concise definition of the state of my channel:

 

Using this data type to update a view would be simple:

 

This is just an implementation of statically typed sum types http://en.wikipedia.org/wiki/Tagged_union in LabVIEW. We already have statically typed product types (clusters), so why shouldn't we have their counterpart?

 

I chose to use a cluster to represent my channel. It contains the direction, state, output mode, frequency, and duty cycle of my channel, and I just ignore the fields if they are meaningless (ex. output mode if the channel's direction is input). What data type(s) would you use? Classes? Enums and Variants? Something Else?

[hooovahh]

If you want to over complicate things sure you can use Classes or Variants.  But seriously what is wrong with just ignoring the data that isn't needed for that type of DIO?  It is quite easy from a developer perspective to see that you are just ignoring control values if the DIO is an input.  Dynamic Dispatch can do this work for you, but with no extra VIs, and a single type def you can have the same functionality.  Variants could be used with a convert from one type to the other if it is an input, or output, or PWM output too but there we possible type conversion errors to worry about which might not be that big of a deal depending on how it is written.

 

I'd KISS in this case.  If we are talking about any larger of a design, where a channel could also be a counter, with PWM in or out, or an analog with in or out, or output wave etc.  Then yeah classes would probably be what I suggest.

[ShaunR]

The problem:

I have a digital channel that can be configured as an input or an output. If it is an input, I only car about seeing its state. If it's an output, I want to be able to configure it as either a simple digital output (on/off) or a PWM output (frequency and duty cycle). I want to be able to request the state of this channel, and I want my views to receive an update when its state changes. How would you express the state of this channel in a LabVIEW data type?

 

This idea was shot down: https://forums.ni.com/t5/LabVIEW-Idea-Exchange/New-Enum-Class-Primitive-quot-The-Defined-Enum-quot-with/idi-p/1904525

 

However, if this idea was a LabVIEW feature, it would allow this concise definition of the state of my channel:

Typedef.png

 

Using this data type to update a view would be simple:

Case Structure.png

 

This is just an implementation of statically typed sum types http://en.wikipedia.org/wiki/Tagged_union in LabVIEW. We already have statically typed product types (clusters), so why shouldn't we have their counterpart?

 

I chose to use a cluster to represent my channel. It contains the direction, state, output mode, frequency, and duty cycle of my channel, and I just ignore the fields if they are meaningless (ex. output mode if the channel's direction is input). What data type(s) would you use? Classes? Enums and Variants? Something Else?

 

Something else.

Edited October 9, 2014 by ShaunR

[Testy]

If you want to over complicate things sure you can use Classes or Variants.  But seriously what is wrong with just ignoring the data that isn't needed for that type of DIO?

I don't think there's anything wrong with it, as it's what I chose to do. But as you said if the channel state gets more complex, it would probably be cleaner to switch to classes. However the Exchange Idea I linked to would be just as good (I think better) than either of these solutions regardless of the complexity of the channel state.

 

 

Something else.

I was more curious about choice of data structure to represent the state channel than I was about handling displaying the data. What would you put inside the XControl's Data.ctl?

[ShaunR]

What would you put inside the XControl's Data.ctl?

Whatever was needed to achieve the required functionality. Probably a boolean, two numerics and an enum plus other stuff like refnums,events etc..

Edited October 9, 2014 by ShaunR

[infinitenothing]

Maybe you'd like a type structure (especially the last image)?

 

https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Type-Structure/idi-p/3017975