Truth Table Node

[Darin.K]

What I like about the K-map style is that the whole map is always visible, I find an 8x8 array easier to deal with than a 64x1.  At any rate, 6 is basically a very hard upper bound.  If I were to tweak the UI it would be to allow regions of the table to be selected based on input values.  Selecting Input 1 true would select all columns with that value, which I could further subdivide based on other inputs.  With this region selected, I could then fill with a given value, much like I do the entire table.  This will wait for version 3 or 4.

I will have to stare at your suggestions a bit to see if inspiration strikes...

I submitted an idea for my current favorite implementation which is simply to allow multiple case selectors in the Case structure itself.

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Allow-Multiple-Case-Selectors/idi-p/1301780

Unfortunately this idea I can't implement myself to see if I like it...

[X.]

Agreed on the decreasing demand for N-uple operations, but, and this is my personal opinion only, I designed this dummy interface to mirror the way *I* approach this problem from a practical point of view. As I said, I had to really THINK to fill in the matrix in your Xnode, as if I had to solve a puzzle 🙂 Very painful and distracting. I don't deny that there are design issues in my own proposal...

Regarding your proposition for multiple inputs for a case structure (the thread you are linking to above), I get your point, but I think I'd prefer having a "General Boolean Operator" (GBO?) inserted between the inputs and the case structure since it seems to me that you would run in the same issues of how to define the outcome of different sets (n-uples) of inputs... Plus it would have the definite advantage of labeling the different cases with a user-defined label, which I find MOST useful.

My 2 cts,

X.

[X.]

Clearly the snapshot should have been:

where the selected inputs match the last row of values in the "Truth Table". The next step for the user is to select the corresponding result (which defaults to the "Idle" case).

X.

[El_Penguino]

Whoa ! That's impressive. Maybe one day I will have such strong LabView Foo as you Darin (unlikely though !). Until then, this Xnode saves awkward nested case structures when dealing with multiple booleans.

Thanks for sharing.

Chris

[murx]

If I draw the 'Truth Table.xnode' in a new VI, I can connect the inputs x and y, but not the output.

I get the message (in LabVIEW 2012) 'Polymorphic terminal cannot accept this data type.'

Details:

'Generally, polymorphic terminals accept any wire type connected to them. But sometimes these terminals only accept a limited subset based on other wire types connected to other terminals. The most common cause of this conflict is using the type cast node to cast between incompatible types, such as a 2D array and a string. Check the terminals connected by this wire and change that node to make this wire type acceptable.'

What can I do?

[Emily-C]

Hi murx,

It looks like this is an upgrade issue. The original xnode was created in LabVIEW 2010. When I open it in LabVIEW 2010, it works as shown in the original post. When I open it in LabVIEW 2012, I see the same behavior that you do. I'm not sure what has changed inside the xnode, but if you want to use the xnode in LabVIEW 2012, it looks like you'll need to try rebuilding it in that version. 

Regards,

[Darin.K]

I'll get to a LV12 machine a bit later, but I am almost certainly using some deprecated methods since it is all subject to change by version. I will try to post the fixed version

[Hooovahh]

---

@Darin.K wrote:
I'll get to a LV12 machine a bit later, but I am almost certainly using some deprecated methods since it is all subject to change by version. I will try to post the fixed version

---

XNode functions are changing between LabVIEW versions?  

...

Oh no this is every thing NI warned us about!

[Darin.K]

It looks like somewhere along the line the Adapt to Type ability stopped receiving type information from indicators.  This did allow for some interesting effects, but I do not think I really will miss it.  Now it returns NULL for the output type which I think is bad and break the wire.  I have modified the GetTerms3 ability (long ago deprecated but hey, it still works) to only break wires for inputs.

I have attached a LV12 version of GetTerms3.vi, simply replace the old one.

Edit:  Grrr.  Forums complaining about contents of the attachment.  Instead of breaking stuff I will describe the simple fix:

Open GetTerms3.vi (with no VIs containing the XNode open or it will be locked).

Unbundle the Input? parameter below the Name

Wire Input? AND >=0 to BreakWire?

[adhikari]

hi Darin,

  i tried to connect indicater to that Truth table node. but i have got an error and says "polymorphic connection does not work with this data type". how could i get rid of it??  i have tried it in LabView 2009, 2010 where works fine but in 2012, it gives me an error.  could you please give me some hint??

kind regards

Thakur