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:
(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
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:
(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
Attachments
Many thanks for that, but if one relies on these notes, one may become even more confused!
On page 22-16 it says that 'measure' consists of three parts: 'arm', 'fetch' & 'report'. For 'fetch' it says 'Fetch (make the measurement)': everything I have recently witnessed (admittedly during mixed testing, rather than analog functional testing per se) suggests that fetch literally only fetches the measurement, which may have actually been taken at some time prior to executing the fetch command. Indeed, the 'more on this later' on page 22-21 does seem to acknowledge that the fetch does just literally fetch the measurement - this is why I am keen to see the actual syntax definition of fetch. Also on page 22-21 it says 'arm detector...get ready to make a measurement and to expect a trigger': the arm syntax entry and the main 'analog functional and mixed testing' chapter suggest that the arm command actually causes the detector to start taking its reading, i.e. the arm command is the trigger! This may seem like nit-picking, but when you are faced with a test that doesn't work and you are trying to understand why, so as to correct the problem, such distinctions can be important! I also noticed that nowhere is the 'initiate' command mentioned, which causes the detector to take readings when set for more analog-type things like dcv, acv etc., and which just adds to the complexity even more (but maybe it is covered elsewhere...?).
Also, in passing, I noticed several other errors (of the type that students really hate): page 22-19, two mentions of 'Negative Rail', whereas the actual subtest in the example is called 'Voltage-Rail'; similarly on the following page the subtest 'Voltage+Rail' is referenced as merely '+Rail'.
All-in-all a prime example of why I keep banging on about the importance of maintaining correct documentation, with errata/whatever (as necessary) issued from time-to-time: even if these little niggles have now been corrected, there are people out there with these errors in their copy of the training notes, and years after attending the course, if they have a problem and even if they think about referring to them, they may be misled, and then their next best course of action is to turn to the documentation set, which if it is not correct, leads to increased and unnecessary frustration...
Tim