0

Dumping the data recorded by an evaluation

While it seems I do a lot of scripting now, I am still a technician first and I write my procedures accordingly. So I have been playing with scripts that do error checking and even let technicians fix an "oops" that would normally crash a whole procedure, forcing it to be run all over again. In this instance, there is a calibration that uses shunts. The technician types in the value of the shunt when Met/Cal prompts them and uses that to Ohm's Law the rest of the measurements off a DMM. While it hasn't happened yet, I KNOW at some point I or another tech is going to mistype the value of a shunt. And if that happens, all readings are going to fail, there's no good way of going back, and even if I put a target before the step that prompts for the value of the shunt, the tech doesn't know if that was actually the issue. So here's my idea. While I was reading he manual, I found a MATH expression that checks to see if the previous evaluation step failed. This intrigues me. So, what if following the first evaluation step after the shunt value gets entered, if it fails, a dialog pops up showing the tech the value they entered for the shunt and asking of it is correct. If it's not correct, then have it jump back to the step before it's entry then run again. However, I can already see one potential issue. Back with I was still learning, I fell in love with DO/UNTIL until I discovered that evaluations that happen on the same step number start overwriting themselves. Somewhat. I would get what I believe is the first and last values, or perhaps the last two values. I am not sure exactly. Point is, data gets retained and not fully overwritten. Which brings me to the crux of my question: Can you dump the stored values of an evaluation that has already run? Also, another hairball question, this MATH function that checks to see if the last evaluation failed, is it possible to have one that checks all previous evaluations to see if one failed?

9 comments

Date Votes
0
Avatar
Michael J.

The short answers to your questions are no and no.

The only way to "trash" a result is to hit the Cancel button on the post-test screen. With that said, what you could do is implement an IF statement that checks if that particular test is being run for the second time. If it is, display the stored shunt value and make sure it's correct, allow the user to fix it if not. That would look something like this: 

 1.001 MEMI Input shunt value. 1.002 MATH Shunt = MEM 1.003 MATH Tested = 0 1.004 LABEL Start_of_Test 1.005 TARGET -p 1.006 IF Tested == 1 1.007 OPBR Is [V Shunt] the correct value? 1.008 IF MEM == -1 1.009 MEMI Input shunt value. 1.010 MATH Shunt = MEM 1.011 ENDIF 1.012 ENDIF 1.013 MATH Tested = 1 1.014 MEMI Enter voltage reading. 1.015 MATH MEM = MEM/Shunt 1.016 MEMC 1.00000A 1%

That way, you can still use the proper Cancel functionality and still error check. You'd only need this additional code for the first test point where you use the shunt.

0
Avatar
Dexter
I see! So placing a TARGET before an IF statement. That is a bit cleaner than I had been thinking. The pseudo-code I had in mind ran something like: 1.001 LABEL Start 1.002 ASK- A 1.003 MEMI Enter Value of Shunt 1.004 MATH Shunt = mem 1.005 5720 1A S 2W 1.006 3458 1V N 2W 1.007 MATH mem = mem/Shunt 1.008 MEME 1.009 IEEE [i] 1.010 MEMCX A 1% 1.011 MATH m[1] = FAIL() 1.012 IF m[1] == 1 1.013 OPBR Is [v Shunt] correct? 1.014 IF mem == -1 1.015 JMPL Start 1.016 ENDIF 1.017 EMDIF 1.018 ASK+ A But of course, it faced the dilemma of running the eval twice and keeping the bad data. Oh! Another advantage of yours, that dialog box would only come up once if 1.013 were rewritten Tested = Tested + 1 There would be no need to ask the tech over and over again if they are trying to troubleshoot the issue. Thanks! That accomplishes what I want!
0
Avatar
Michael J.

No problem! Yeah, this technique is used in some Gold Procedures that I've seen to allow connection messages to be displayed multiple times for a repeat or cancel.

0
Avatar
Nathan Ryder

Hold up slight error there.....Line 1.008 should be MEM1 not MEM

 

 1.001 MEMI Input shunt value. 1.002 MATH Shunt = MEM 1.003 MATH Tested = 0 1.004 LABEL Start_of_Test 1.005 TARGET -p 1.006 IF Tested == 1 1.007 OPBR Is [V Shunt] the correct value? 1.008 IF MEM1 == -1 1.009 MEMI Input shunt value. 1.010 MATH Shunt = MEM 1.011 ENDIF 1.012 ENDIF 1.013 MATH Tested = 1 1.014 MEMI Enter voltage reading. 1.015 MATH MEM = MEM/Shunt 1.016 MEMC 1.00000A 1%
0
Avatar
Dexter

I am not going to hold anyone to the exact code. This, for me at least, serves as a proof of concept I can adapt elsewhere. 

0
Avatar
Nathan Ryder

Yeah I only found it as I forced an error to see it work and it didnt ask for the shunt value again..Still a clever bit of code that you could use to implement all kinds of setup checks.

0
Avatar
Michael J.

Whoops. I did one test run and forced an error. It didn't work because I had 0 instead of -1 (I tend to use OPBR -z by default), so I changed that and posted without testing again. That'll teach me!

0
Avatar
Nathan Ryder

Any reason why "-z" over not?.......I notice a few of your collegues prefer it too.

0
Avatar
Michael J.

In terms of normal coding practices, having 0 as false is more in line with norms. In MET/TEAM for example, true is either 1 or -1, depending on the specific field, and false is 0. Since I was familiar with other coding languages before learning MET/CAL, using 0 as false just kind of carried over. It's a better differentiation between 1 and 0 compared to 1 and -1, as well.

Please sign in to leave a comment.