LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Subsequent calls of compare Express VI give different results

Hi All,
 

I am having trouble with a sub VI that I have written performing differently on subsequent calls and am hoping that someone can explain to me why.

 

The sub VI is called ‘DMM Measurements via two Switch (SubVI).vi’ and it routes one terminal of a DMM (set to resistance mode) via one of the switches (set to one of 128 multiplexer mode) to one of five lines that have resistors connected between them. One of these resistors is connected via a mechanical switch. The other DMM terminal is routed via the other switch (also configured as a one of 128 multiplexer) to the same five lines.

 

This sub VI is intended to measure the resistance of all combinations of the five lines without unnecessary duplication , compare the results with expected ‘Nominal values’ and produce a results file containing columns of test point descriptions, DMM readings, expected values and 1’s or 0’s to represent whether each line was a Pass or Fail (measurement = expected, =/- tolerance)

 

The code sits inside a For loop with the count terminal wired to the number of line combinations being tested (4 in my basic example). Consequently one multiplexer advances one position each time around this loop while the other multiplexer scans through the other lines during the loop.

Scan lists for the multiplexers are built up using the concatenate string functions and the iteration count for the loop is used to reduce the number of lines being scanned by the second switch each time the first switch is advanced.

The concatenate string functions are also used to build file names to direct the program to external files containing ‘Line ID’ (a brief description of which points are being measured between for each measurement) and ‘Nominal resistance’

For my five line example it may seem unnecessary to have four files of line ID’s, four files of nominal resistance with switch open, and four with switch closed, but the final solution will have 70 plus of each, so this approach should be more manageable for that solution.

 

The DMM measurements are passed to a For loop inside the main loop. This is needed because open circuit measurements are reported as NaN (not a number), and the subsequent functions will only accept data in number format, so this loop converts any NaN’s  to 10 Mohm. (Attempts to not have NaN reported in the first place by letting the DMM autorange resulted in loss of synchronisation between it and the switches. Selecting a high enough range resulted in insufficient accuracy for low resistance measurements).

 

These results and their expected values are then converted to dynamic data types and fed into a compare Express VI, configures to compare the two, plus or minus a specified tolerance. (This VI only accepts dynamic data types as inputs). The resulting output is an array of 1’s &/or 0’s where 1 represents a pass, 0 a failure for a particular measurement.

 

Another For loop inside the main loop combines these results with the test point descriptions, DMM readings and expected values and passes them out of this Sub VI.

 

Finally, some Boolean logic checks whether all 1’s (Passes) were produced by the compare function. If any 0’s are seen an overall False results. An array of these results are also passed out of the Sub VI.

 

This all appears to work fine when run with my mechanical switch open, but when I run it again with this switch closed the DMM measurements match the new set of expected values, +/- tolerance but one of the lines is shown as a fail (0). All other lines are pass.

 

Sorry this is so long, any suggestions gratefully received.

Download All
0 Kudos
Message 1 of 3
(2,194 Views)
Hello Lama,
 
I have two suggestions starting off:
  1. Near the end of the for loop, where you convert your numeric array to a boolean array, instead of comparing "is equal to 1", do the comparison as "is greater than 0.5".  Equality comparison with floating point numbers (which is what is in the array - your integer 1 is getting converted to floating point by the coercion dot) is usually a bad idea, due to possible innacuricies with the representation of that particular number on the floating point unit.  For a value of 1 I wouldn't necessarily expect to see problems, but I would still try this first.
  2. Try to split this up.  For example, right now, you've got your DMM measurements and your comparisons within the same for loop.  This is fine for the application, but for debugging, it will help us isolate the cause of the problem to split them up into two main for loops where you first take all your measurements, then pass them all to the second for loop where the comparison occurs.  Once you've done this, hopefully you can save off the measured data as default values in a control and completely eliminate the connection to DMM drivers and hardware.

Hope this helps!

0 Kudos
Message 2 of 3
(2,176 Views)

Jeff,

Thanks for your reply.

I finally got to the bottom of what my problem was. The text file that contains the expected results for the failing batch of results had an additional blank line at the end that was upsetting things. Now that I have descovered and removed it, all is behaving as expected.

I have done as you suggested and changed my 'equal to' to 'greater than'.

Thanks,

 

Lama

0 Kudos
Message 3 of 3
(2,158 Views)