LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Entered Text is Cleared When Selecting New Tex tBox

Hello - 

 

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. 

0 Kudos
Message 1 of 11
(2,357 Views)

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.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 2 of 11
(2,343 Views)

I agree with Tim that this needs to be redone almost from scratch. Once you clean up the code, everything will fall into place.

 

  • Your FALSE case should be empty, except for a small wait. (currently you loop continually spins millions of times per second doing absolutely nothing useful, just burning CPU).
  • All your controls belong in the true case, no local variables needed. Their value will be read when you press OK and that's the only time they need to be read. I don't think you understand local variables. They have nothing to do with "variables" in the classic text programming sense.
  • Your shift register in the big FOR loop can be replaced by simple autoindexing at the right border.
  • Your Index array can be replaced by autoindexing at the left border.
  • There is "AND array elements". No need to go to cluster and back for no reason.
  • You only need one dialog, switch the text according to the outcome.
  • Since you never use the history value, your error shift register is completely useless..
  • If you use the error wire to define execution order of the dialog and reinit node, you can remove the sequence.
  • Two of your path constants are the same. One instance is sufficient. Branch the wire!
  • You can make "00282102RC" the default value for the "UUT Part number" indicator.
  • Yes, all you need is an event structure with two events. (1) OK value changes (containing your TRUE code), (2) Stop value changed (ending the outer loop).

 

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.

Message 3 of 11
(2,329 Views)

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. 

 

Thanks. 

0 Kudos
Message 4 of 11
(2,295 Views)

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.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 5 of 11
(2,291 Views)

Hi BHopkins,

 

If you don't mind taking a look at what I have now and critiquing it, I'd appreciate it. 

  • Clean up the code (see the style guide!). Straight wires, left-to-right placing, … (As long as AutoCleanup improves your code you made something wrong! :D)
  • No sequence structure needed, it's all in the DATAFLOW!
  • OK button should be placed inside its event case.
  • There's an "AND array" function - and you already create an array from your boolean buttons. No need for a CompundArithmetic here…
  • Those buttons should be set to Latch mode so you don't need to ReInit them after reading them!Use a simple Select node for your two user messages (with a OneButtonDialog behind) instead of two ExpressVIs to display a message…
  • There's a FOR loop in the code - but their result isn't used at all…

 

Edit: Should refresh a webpage before posting. Tim was faster…

 

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
Message 6 of 11
(2,287 Views)

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. 

0 Kudos
Message 7 of 11
(2,278 Views)

Also, GerdW, thanks for the tip on the switch action! Do the switches automatically clear as a result of them being latched, then read? 

0 Kudos
Message 8 of 11
(2,276 Views)

Hi BHoskins,

 

Do the switches automatically clear as a result of them being latched, then read? 

Yes.

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
0 Kudos
Message 9 of 11
(2,269 Views)

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)

0 Kudos
Message 10 of 11
(2,255 Views)