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?

Groups:

Comments

mjohnst1

The short answers to your

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.

1488999028

I see! So placing a TARGET

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!

mjohnst1

No problem! Yeah, this

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.

1376599284

Hold up slight error

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%
1488999028

I am not going to hold anyone

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. 

1376599284

Yeah I only found it as I

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.

mjohnst1

Whoops. I did one test run

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!

1376599284

Any reason why "-z" over

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

mjohnst1

In terms of normal coding

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.