LabVIEW
LEDs flashing on front panel in different modes
Hey there,
I'm relatively new to the world of LabVIEW and currently struggling to work out my homework task.
The task was the following:
- 5 LEDs on the front panel
- 3 modes of lighting the LEDs:
- 1. let the LEDs flash simultaneously
- 2. let the LEDs flash succesively (LED1 turns on; when LED1 turns off, LED2 turns on etc.)
- 3. let LED1 flash 5 times, then let LED2 flash 5 times etc.
- switch the mode only after pressing OK
- manipulate the flashing delay
I figured out how to implement mode 1 and 2 (I will add a link to the project) but I don't know how to mode 3.
Here's what I currently got:
I embedded the whole code in a producer/consumer structure.
Right now, LED1 is flashing 5 times before LED2 flashes one time, then it gets back to LED1 flashing. I know that this is because of the way I defined the inner case structure.
Is the approach with the inner case structure valid?
I will probably need another array but right now I'm pretty much stuck, so I'm thankful for any kind of help!
I am working on Labview 2021.
This is a very simple task and you have way too much code for such a simple problem. All you need is a simple state machine running at a constant rate that changes state as a function of elapsed time and mode.
- I would use an array or cluster of of LEDs.
- Your delay should not be orange! (there are many other orange wires that should be blue)
- Properly done, the code will probably fit on half a postcard.
I'll have a look....
See if this can give you some ideas....
Note that the loop spins at a constant 50ms and changes state as a function of accumulated time. This is especially useful for longer time delays that would interfere with responsiveness. You want to read the controls often, even if the delay is 30 seconds.
(of course your teacher reads this forum too, so make sure you fully understand the logic, then apply selected ideas to your code. Be creative!)
Yes, I did not read the description in detail, but your "5" mode would only requite some very minor changes to implement, It is just a longer cycle with otherwise very similar logic. (It is actually simpler than the current 5 flash cycle). Try it!
You could actually add many more flashing modes by just adding items to the enum and adding more cases. Scalability is always good!
Sorry, I only have LabVIEW 2020 at the moment so I cannot look at your VI, but here's one possibility:
Also note that if the patterns are relatively short, but complicated, a LUT (lookup table) would allow a solution with basically no fancy logic. (here the third pattern is some kind of zig-zag). It is now easy to add any other pattern graphically by adding elements to the diagram constant and items to the enum without any other changes in the code.
@jonask99 wrote:
If you still have some spare time, could you have a look at my solution now and see if you still have any tips for further improvement? (In LEDs_one_loop I got rid of the producer-consumer structure)
Anyways, thanks a dozen again!!
- It is sufficient to create the 5 element array once before the loop, not in each case of the case structure. If you want them all true, use what I did. It is crazy to initialize an array with every iteration of the loop, but the compiler will detect the redundancy and fix it behind the scenes. It is always better to keep the code clean and readable.
- Your wait should be U32, not I32 (notice the coercion dot?). It is typically a really bad idea to slow the loop. For example if you do a 10 second delay, the VI might take up to 10 seconds to react to the OK button. It is significantly better to keep track of elapsed state time as I did. Do you understand my code? (If you want to keep the current code, set the data entry to not allow more than 1000ms or less. Currently, the user can enter 2147483647ms and nothing will ever happen, even if you set it back to 500ms while the program is running.
- You should initialize your boolean shift register, else you might get unusual behavior if the program starts with "simultaneously" but was stopped while the shift register was not at the default.
- The remainder of a QR division by two is the same as "AND 1", but computationally simpler.
- Your lower shift register grows forever by one and the value is identical to the iteration terminal so just use that. You should not keep the label "state", because that's not what it is anymore. The problem compared to my solution is that the new pattern might start in the middle if you change mode at certain times. In my code, every new pattern starts at the beginning.
- Please avoid excessive number of wire bends and overlapping objects. Wires between shift registers should be all horizontal to avoid accidental miswiring.
- Please arrange the front panel logically. No need to scatter the controls and indicators randomly.
Here's just the tip of the iceberg:
