case structure executes wrong case

[sgallardo]

I have a subvi that has two case structures.  The inner case structure seems to be executing the wrong case.  I have attached the highlighted execution of the subvi.  You can see that the the selector terminal has TRUE being feed into it, but the case that is executing is the FALSE case.  Does anyone know what is wrong with the code?

Appreciate your help

Sarah

[altenbach]

Please attach your actual VI. We cannot debug a picture. Also state your LabVIEW version (which we would know if you attach a VI).

Does the outcome indicate that the wrong case has executed or are you relying on what case you seen during execution highlighting?

[altenbach · Accepted solution]

Also, your entire VI seems to be based on diagram constants (I cannot see any controls!). There might be a lot of folding going on. You might want to turn your input string into a control for a more realistic experience. 😄

[sgallardo]

Well I changed the input string constant into a control, and that seemed to have corrected the problem.  I just don't understand why it makes a difference.  This vi was only created to test out the code and make sure it would produce the correct results, but the actual vi will be taking a string from an access database.  I just wonder if I will get other results from that.  I have attached the code for that as well (Test Lot Generator.vi).  By the way, I am using LV8.2.1.

Sarah

[altenbach]

In LabVIEW 2010, the correct case shows during execution highlighting. Are you really saying the VI produces the wrong result in your case when a constant is used?

I have the gut feeling that you code is way too complicated anyway. What is it supposed to do? Do you just want to cycle throught T(1..F..)(A..Z)(00000...99999)?

[sgallardo]

Yes when I used a constant the vi produced the wrong result, because it executes the wrong case in the inner case structure (you can see that from the screenshot I provided on the first thread).  The program is supposed to get the last test code used from a database and increment it by 1.  The code would be T(A...Z)(A...Z)(00000....99999). 

[altenbach]

Well, your second character does not work outside 0..F, right?

[sgallardo]

Yes that is correct, the Test Lot Generator.vi is not correct. The plan was to make all the changes to the Untitled 3.vi, and once that is working correctly I would copy that code to the Test Lot Generator.vi.  I have updated the Test Lot Generator.vi.

[Darin.K]

These hexavigesimal problems seem to crop up regularly.  I would usually do something like this, I'll leave error and range checking to you.

[sgallardo]

Thank you.