LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Producer/Consumer variables not displaying into front panel.

Solved!
Go to solution

@proland1121 wrote:

It's running all the time because your state is "init", Default.  any invalid state will execute the "init" state as a result.

Move the Default to an empty case.  you should also add some error handling.

 

Your "Variant to Data" is generating an error due to the data mismatch.  the dbl doesn't match a cluster

proland1121_0-1649777202816.png

 

Also, Init shouldn't have any data to dequeue so that variant to data vi is completely unecessary.

 


There's no hard and fast rule that you shouldn't have any data in your init enqueue.  Although I personally don't do it, there's no reason why you can't have all your init data - like instrument refs and initial values - in your data.  It's a kind of messy, but perfectly valid, way of handling the init state.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
Message 11 of 21
(947 Views)

I don't understand what you mean, my default state is "wait" 

 

Blancoys_0-1649778728156.png

 

 

If I change on the starting cluster to another case, then init is never invoked. 

 

Blancoys_1-1649778795927.png

Even if I change on my event case to send the queue to "init" it doesn't: 

Blancoys_2-1649778938523.png

 

0 Kudos
Message 12 of 21
(943 Views)

So you mean adding to the cluster all of my initial data? 

Blancoys_0-1649779436531.png

 

This cluster I mean. 

 

0 Kudos
Message 13 of 21
(899 Views)

so you mean that i should put all my init data into the cluster where the enum is? 

 

0 Kudos
Message 14 of 21
(901 Views)

@Blancoys wrote:

I don't understand what you mean, my default state is "wait" 

 

Blancoys_0-1649778728156.png


In the version that you uploaded "init" is the default state:

 

johntrich1971_0-1649781421255.png


@Blancoys wrote:

 

If I change on the starting cluster to another case, then init is never invoked. 

Blancoys_1-1649778795927.png

Even if I change on my event case to send the queue to "init" it doesn't: 

Blancoys_2-1649778938523.png

 


No, don't change the starting state. You either need to put data in the variant in the message cluster to match the expected data type (the cluster) like you do inside your event structure (why are you calling init inside the event structure?) or get rid of the variant to data in the init case.

 

Edited to add: It would be a good idea to upload an updated version of your code since changes have been made.

Message 15 of 21
(924 Views)

Hello, 

 

Okay, I leave "Init" on the cluster

Blancoys_0-1649782605795.png

I get rid of my variant to data on my event structure, 

 

Blancoys_1-1649782640823.png

 

I don't understand how to go from one state to the other. How do I invoke from the producer loop the states that are on my consumer? (I tried as it was : Unbundle and bundle with the enum and then queueing it, but it didn't work). 

 

And my other question is: how to stop the consumer from looping into the starting case? (Default is now: wait on the consumer).

 

Many Thanks 😀

0 Kudos
Message 16 of 21
(918 Views)

To go from one state to the other you have events set up in your event structure to trigger the next step. You then send a message to the Consumer from inside the selected event. 

Message 17 of 21
(900 Views)

Hello! I've succeded on adapting the code with the Producer/Consumer Loop, however I have one difficulty, my diagram is as follows: 

Blancoys_0-1649792508641.png

 

More specifically, I have problem with passing "OldVal" (from the event structure on the producer loop) to the consumer loop, since it's the value I need to take the data from my buttons. 

 

Blancoys_1-1649792576359.png

 

Blancoys_2-1649792600148.png

 

(Of course it doesn't work like this) and I can't create a local variable.

Blancoys_3-1649792626635.png

 

Any suggestions on how to approach this problem? 

 

Kind Regards😀

 

 

 

0 Kudos
Message 18 of 21
(891 Views)

When you need to send a message then you need to have your queue set up as a messenger service. You actually had that earlier. Return to having the queue set up to contain a cluster with your enum and a variant (the "data" or "payload" of the message). Put the data in the variant, and then use the correct data type with Variant to Data in the consumer loop to retrieve the data.  

Message 19 of 21
(816 Views)

As John said, your earlier version had a command and a variant as the queue data. This is a pretty common architecture and works great but you need to understand how to use variants. When you turn something into a variant you are responsible for converting it back into the correct data type. LabVIEW (and most languages) normally take care of the data type for you (int, float, etc) variants let you generalize the data to add some flexibility to your program. IE you will send something as the data to a queue, but what that something is can be dynamic.

 

https://zone.ni.com/reference/en-XX/help/371361R-01/lvhowto/variants/ 

 

You also have some errors in your code, and generally the architecture could be a lot better.

Race_condition.png

This is a perfect example of a race condition 

Will you read the value of "Geld Einwurf" before setting it to 0? Who knows. 

 

unthrottled_loop.png

This creates an unthrottled loop. Put an indicator on the iteration terminal (i) and watch it count up as fast as your computer can run that loop.

 

You are using both shift registers and local variables to do essentially the same thing. Personally I like having one big type defed cluster with all the information I will use in a loop wired on a shift register. Then operate on the data you need using bundle and unbundle. 

 

Local variables are generally frowned upon in LabVIEW because they are great at creating race conditions and making it harder to debug. Use wires when you can to keep up with NI's dataflow philosophy.

 



 

 

Message 20 of 21
(811 Views)