04-12-2022 10:31 AM - edited 04-12-2022 10:32 AM
@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
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.
04-12-2022 10:56 AM
I don't understand what you mean, my default state is "wait"
If I change on the starting cluster to another case, then init is never invoked.
Even if I change on my event case to send the queue to "init" it doesn't:
04-12-2022 11:04 AM
So you mean adding to the cluster all of my initial data?
This cluster I mean.
04-12-2022 11:31 AM
so you mean that i should put all my init data into the cluster where the enum is?
04-12-2022 11:43 AM - edited 04-12-2022 11:44 AM
@Blancoys wrote:
I don't understand what you mean, my default state is "wait"
In the version that you uploaded "init" is the default state:
@Blancoys wrote:
If I change on the starting cluster to another case, then init is never invoked.
Even if I change on my event case to send the queue to "init" it doesn't:
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.
04-12-2022 11:59 AM
Hello,
Okay, I leave "Init" on the cluster
I get rid of my variant to data on my event structure,
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 😀
04-12-2022 01:49 PM
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.
04-12-2022 02:45 PM
Hello! I've succeded on adapting the code with the Producer/Consumer Loop, however I have one difficulty, my diagram is as follows:
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.
(Of course it doesn't work like this) and I can't create a local variable.
Any suggestions on how to approach this problem?
Kind Regards😀
04-13-2022 09:18 AM
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.
04-13-2022 12:13 PM
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.
This is a perfect example of a race condition
Will you read the value of "Geld Einwurf" before setting it to 0? Who knows.
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.