AnsweredAssumed Answered

Missing 'fetch' syntax, and undocumented 'measure' feature?

Question asked by t_stinchcombe on Jun 23, 2009
Latest reply on Jun 24, 2009 by t_stinchcombe
This post is in two parts: I'll deal with the trivial first.

We are using Unix controllers (B180L), and I believe the documentation set we have to be the latest available, mostly dated 2001 (software is 5.30p). Whilst investigating the second part below I discovered that there is no syntax entry (!) for fetch (analog) - the entries under 'F' of the Syntax Reference go:

...
fdoff (BT-BASIC)
fetch (edit)
file (VCL)
fetch (VCL)
file (VCL)
find (edit)
...

In the hope that this was rectified in a later (possibly Windows) version, and betting that the gross characteristics are the same, if someone could please copy-and-paste the syntax entry here, I'd really appreciate it, thanks!


Now for the second, more involved part. I have been trying to understand a 'mixed' library test for an RS232 '1488 driver chip - we occasionally get a 'timeout' failure on the first time through, which on re-testing the board disappears. I'm not really any closer to finding the cause of this out, but in the process of looking at the test have noticed a few things that don't add up. The library test concerned is:

       hp3070/library/template/rs232/quad_driver/

(both 'analog' and 'digital' files of course).

Here is an extract of the first subtest/unit, ordered to (hopefully) make it more readable, with the digital bits on the right, and analog bits on the left:

                       execute  Driver_Disable
                       continue analog            ! setup detector
subtest "Out_A_high_In_0"
   connect i to pins  3
   connect l to pins  7
   detector dcv, expect 20.0, digital
   continue digital
                       execute  Input_A_0  trigger dcv
                       repeat 150 times           ! wait 1.5 ms
                          execute  Input_A_0
                       end repeat
                       execute  Driver_Disable
                       continue analog            ! fetch results
   measure 12.5, 10.0
   continue digital
                       continue analog            ! setup detector
end subtest
subtest "Out_A_low_In_1"
   connect i to pins  3
   connect l to pins  7
   detector dcv, expect -20.0, digital
   continue digital
                       execute  Input_A_1  trigger dcv
                       repeat 150 times           ! wait 1.5 ms
                          execute  Input_A_1
                       end repeat
                       execute  Driver_Disable
                       continue analog            ! fetch results
   measure -10.0, -12.5
   continue digital
  

   (The vector cycle time is 10us.) (And apologies for the clumsy 'code' block - it was the best I could do to stop phpBB stripping out my formatting...)
  
From what I have read in the documentation, this should not work, and yet it does! The 'continue analog' before the first 'measure' should hold the digital drivers in the states set by the previous vector, i.e. Driver_Disable, but these are the wrong states for the test to pass: the measure should 'initiate' the detector, i.e. cause the detector to take a reading (which should be wrong because the inputs are wrong!), fetch the reading and report the result. Thus it looks like the initiate inside the measure should 'throw away' the initiate caused by the 'trigger dcv' on the 'Input_A_0' vector: however it is clear the 'repeat loops' are preventing this from happening, so that the correct value is being 'held' by the detector, and that the measure does not do an initiate of its own, but instead picks up the correct value.
  
   If I remove the repeat loops, the test does indeed fail - the measure then does appear to override the initial 'trigger dcv', and so does see the wrong value caused by the 'Driver_Disable' vector.
  
   If I remove the repeat loops, replace the measure with a 'fetch...' plus 'report...', it passes, either with or without the 'exec  Driver_Disable', as is to be expected, as the trigger/initiate of 'trigger dcv' is taken when the correct input vector is set.
   (And various other combinations all behave as expected.)
  
   It thus looks like this is making use of some undocumented feature, whereby the delay between the initial 'trigger dcv' and the 'measure' causes the measure to read the held detector value, and not to take a 'fresh reading'!?

Any thoughts or insight appreciated!
  
   Tim  

Outcomes