05-13-2023 04:21 PM
I have two codes, with local variables and queues. It does not matter which one you want to look at. I just don't understand why my state machine won't move to the next state or some of the the logic inside the state is not being executed as shown below. What am I doing wrong? I just want to help someone from the community (https://forums.ni.com/t5/LabVIEW/Help-with-arduino-temperature-control-project/m-p/4304740#M1258094)
At the same time, I want to learn from my mistake.
Someone please help!
Solved! Go to Solution.
05-13-2023 08:04 PM
In both vis, if I remove the LINX code and change the Temp C indicator to a control, the state machines work.
(Some wait functions are needed to avoid CPU heating.)
05-13-2023 09:11 PM - edited 05-13-2023 09:13 PM
Hi Stevem,
But I need that Temp C in the consumer loop. if you change temp C to control then the temperature will be changed based on the user input, not the sensor.
The linx code is also needed. These are VIs that allow LabVIEW to interface with the microcontroller Arduino.
05-14-2023 11:52 AM - edited 05-14-2023 01:00 PM
There are many really questionable code constructs in either version, but if you want help, you should replace all your hardware IO with simple simulations so we can actually run and test.
There are millions of possible ways something "does not work", so you need to be much more specific! What are typical values received? What do you expect to happen? What happens instead?
Since there is no real UI and all responses directly depend on the measured values, I have no idea why you would complicated it with two loops. One loop is sufficient. No need for queues, channels and secondary state machines. You only dequeue a temperature element every 100ms, but we have no idea how often one gets enqueued in the upper loop. If that upper loop runs much faster, the queue grows forever and all you ever dequeue is ancient data. did you ever look at the dequeued temperature in either case?
Specific comments for your codes: The queue is OK for the temperature, but using a queue to substitute as simple state container is just plain silly. Get rid of that! Also if you would wire the result of the OR in the upper loop to the channel, you would no need that song and dance with the "stop all" local variables, right? Why do you read the Temp C inside the case structure if you need it in both cases? That belongs before the case! same with the dequeue/enqueue stuff. All that belongs outside the case! The case structure should only contain stuff that differs between cases. It is also very distracting if you place (misspelled!) scripture quotes outside the visible area of the front panel. That is just distracting.
05-14-2023 12:20 PM
05-14-2023 01:57 PM
Thanks Mr. Altenbach! I'm able to achieve it with one loop. As a matter of fact, I don't even need a state machine. Thanks for helping me see that.