Trouble using enums on variant

[Blancoys]

I've been learning to use LabVIEW and your help has been enlightening. 

Currently I'm trying to use a simple enum to select an option on a case and then display it on a dialog box. 

However, with my architecture, I get ERR 91. I've read it's because some things are not accepted inside the variant, which is why I want to transform it into something else to be able to use the case selector: I've tried making it a string with no success. 

I would be open to any suggestions. 

Also, after the "set button" is invoked, the program doesn't quit when you click stop. However, on both states of my producer/consumer on "stop" i have set it to true. 

Kind Regards!🎈

[altenbach]

In the "Set button" event, you are not enqueuing any variant data, and you'll try to get the enum from an empty variant.

Move the parameter control inside the Set Button event and bundle it into the data. Remove the event for "parameter" change. It is pointless. It just fires the wait case that does not even care about the variant.

[altenbach · Accepted solution]

try this.

Some general comments:

• The dialog VI belongs after the case structure. You don't need two instances.
• The Parameter control should also be a typedef, else you run into problems if you change the control, but forget to change the diagram constant accordingly..
• All you probably need here is one event for all important actions.
• Using "use default if unwired" output tunnels can eliminate all your five FALSE diagram constants.
• Not sure why you wire the queue wire to the case structure
• ...

[StevenD]

Here's a modified version of your VI with some comments and changes. Most (some?) of the changes are what Altenbach has already stated. I would add emphasis to the fact that you have your error wires on shift registers, but never deal with any errors. Most functions and VI's will not do anything if an error is wired to their input (this is why the "Stop" wasn't working after getting error 91, dequeue element had an error on the input).

[Blancoys]

Thank you very much altenbach and StevenD for your replies. 

My question is answered which is why I will mark it as solved, however it would be very useful for me if you answer some of my (last) questions to the model I'm working on.  

So far I've understood some of the mistakes I've made, which is why I won't mention them anymore (it's clear to me why they're wrong).

The things that are still unclear to me are related to error handling: 

1) So, the shift registers are wrong on this structure? My understanding was that they send the error through the loop, and I thought this information was needed. How do I pass then the error? On this remark I have no background, so it's hard for me to think of a solution. 

2) I don't understand what it's meant by this. 

Kind Regards! 😋

[StevenD]

---

@Blancoys wrote:

Thank you very much altenbach and StevenD for your replies. 

My question is answered which is why I will mark it as solved, however it would be very useful for me if you answer some of my (last) questions to the model I'm working on.  

So far I've understood some of the mistakes I've made, which is why I won't mention them anymore (it's clear to me why they're wrong).

The things that are still unclear to me are related to error handling: 

1) So, the shift registers are wrong on this structure? My understanding was that they send the error through the loop, and I thought this information was needed. How do I pass then the error? On this remark I have no background, so it's hard for me to think of a solution. 

Using a shift register to keep track of the error is fine, but you don't have any error handling. If you get one error like you were in your original uploaded VI, the error will persist forever and cause most functions to not work. For a program as simple as this, you could remove the error wires, make sure LabVIEW is set to automatically show an error handler for unwired errors (in the Options > Block diagram) and just make sure you deal with any that popup. For a more complicated program that may have to get data from another device, or read a file whose contents may be in the wrong format or corrupted, more robust error handling should be done with things like errors on shift registers.33

2) I don't understand what it's meant by this. 

Kind Regards! 😋

---

In your original upload, if you changed the "parameter" it would enqueue the a cluster of data: the command of "Wait" and the data of the parameter enum. But the consumer loop "Wait" case doesn't look at the variant data at all. I think you assumed that parameter data would stay until you hit the "Set" button (which only enqueues the "Set parameter" enum command and an empty variant). The "Set Parameter" case in the consumer loop expects the variant to contain the (non-type deffed) enum, but it receives an empty variant, hence the error. The data enqueued is the whole cluster, not just parts of it. You need to send ALL the cluster information when you enqueue it. Variants are good/bad in that you can send an empty one. It's perfectly fine, but when you try and convert nothing into an enum surprise, surprise, it throws and error.

[Blancoys]

Thank you very much for your time and patience on explaining my questions 🤗

Its clear to me now, 

Kind Regards!