11-01-2018 09:51 AM
I have a program that I am currently using as a test reporting software. Meaning a user will grab a PCBA and perform a few functionality tests, put in some information regarding the board (Serial Number/MO Number), and their initials. When they are done, they press enter and the info is sent to our report database.
A problem arises when users are entering their initials,the serial number, and MO Number. At random it seems, after the user enters text in one of the boxes, and they click away to enter more data, what they entered disappears. This problem occurs in all three fields that the user can input their data.
I have uploaded the current VI I am using. Please excuse the lackluster programming, I only have a few weeks experience with LV and plan to revise this code for future use. I just threw this together with limited LV programming knowledge.
With how my VI is now, are there any obvious reasons as to why this happens?
Also, this was written in LabVIEW 2016 32-bit with the LabView 2017 Runtime Engine SP1 f3.
11-01-2018 10:35 AM
Your FALSE case makes no sense at all. You are setting your control values to the value they already hold. That is likely what is causing your values to "reset". This is a form of race condition.
I very highly recommend you go through some of the online tutorials and especially learn to use the Event Structure. You can clean up A LOT of this code that way.
11-01-2018 11:29 AM - edited 11-01-2018 11:32 AM
I agree with Tim that this needs to be redone almost from scratch. Once you clean up the code, everything will fall into place.
Also note that you should attach everything to get more detailed advice (typedefs, subVIs, etc.) Also try to remove breakpoints before attaching code). Also please don't maximize the diagram and front panel to the screen. That's annoying! It is impossible to have the help window visible if the diagram is maximized (... and you probably need it!). 😄
This is a good task to learn and your program will run flawlessly soon after. 😄 Good luck.
11-06-2018 07:18 AM
Thank you for all the pointers on improving the code! It really helped cut down on the size of the block diagram. I have attached the new program, along with typedefs and SubVI's that I am using as well. If you don't mind taking a look at what I have now and critiquing it, I'd appreciate it.
11-06-2018 07:51 AM - edited 11-06-2018 07:51 AM
1. Still no need for the Sequence Structure. Everything will be sequenced based on data flow.
2. Your OK Button should really be inside of it's value change event case.
3. Your larger FOR loop should be autoindexing the Boolean array. This eliminates the need for the Index Array in there.
4. Your output for the larger FOR loop should also be autoindexing to create the array. This eliminates a lot of code and is much for efficient.
5. Your smaller FOR loop that has no output could be replaced by the And Array Elements (assuming nothing else is supposed to happen in that loop).
6. I would get rid of the Display Message To User Express VIs and use a 1 Button Dialog function and a Select to choose which message to display.
7. Spend some time just generally cleaning up your block diagram. Line up the functions (there are tools in the toolbar for that). Avoid wires going right to left. Limit wire bends.
Here is a quick clean up of your diagram. See if it helps some.
11-06-2018 08:04 AM - edited 11-06-2018 08:05 AM
If you don't mind taking a look at what I have now and critiquing it, I'd appreciate it.
Edit: Should refresh a webpage before posting. Tim was faster…
11-06-2018 08:41 AM
yes that small FOR loop was needed for for the database reported for each functional test. I have kept it in and made the changes you and altenbach have made. I appreciate the help of both of you!
As much as i have despised LabVIEW during my time in academia, I can see how you can get a simple functional test program thrown together in just a few minutes.
11-06-2018 08:55 AM
Also, GerdW, thanks for the tip on the switch action! Do the switches automatically clear as a result of them being latched, then read?
11-06-2018 09:03 AM
11-06-2018 12:00 PM - edited 11-06-2018 12:07 PM
Personally, I would not use latch action booleans here to give the user more freedom. With switch action, the user can check/uncheck at will before the OK button is pressed. With latch action, once the button is switched, I cannot be undone until the OK event fires. Not a good user experience. I would reset them using local variables.
( also would place these four booleans into a cluster and convert it into an array in the code right away. 4x fewer terminals for the same functionality. :D)