Jump to content

What Data Structure Would You Use?


Recommended Posts

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:

post-30070-0-45316700-1412861291_thumb.p

 

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

post-30070-0-39573800-1412861353_thumb.p

 

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?

Link to comment

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.

  • Like 1
Link to comment

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:

attachicon.gifTypedef.png

 

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

attachicon.gifCase 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 by ShaunR
Link to comment

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.

 

 

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?

Link to comment
  • 4 weeks later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.