When we use Test Consultant to create a new version of an existing board it creates version entries in the Board file and Test Order file for parts that are the same in the base version. Could anyone please tell me why this would be?
I too have seen this behaviour, and it took me ages to figure out what was happening. In my case, whilst at first glance it appeared that since a base test existed and that this was what was required to be run for the new version, IPG was actually spotting that the existing test didn't match with what it thought it needed to test the component with for the new version, and so it goes ahead and generates a new test for the new version, along with all the stuff to call it etc. in the testorder.
I had a number of transistors that were incorrectly specified as the wrong type in the board file (NPN for PNP): following the initial development (not done by me!), this had been spotted, and the solution clearly adopted was simply to change the 's' and 'i' bus connections in the actual test. When I came along to introduce a new version, I marked all the tests known to be good as 'permanent' in the testorder, including these transistors, and was baffled as to why IPG then wanted to generate new tests for these transistors in the new version, even though they were not different in the new version. When I spotted and corrected the incorrect type set in the board file, the problem went away, but it shows that IPG is not merely checking to see if a test file exists for a device, it is clearly looking at what is in the file in some detail in order to determine if that test is good for what it believes it wants (in the transistor case the type is given in the 'beta' test part of the test file, but whether it is using this for its judgement or is actually checking the connection set I couldn't say...). What level of detail it is checking to I couldn't say, nor whether this might affect other 'simpler' components like resistors, capacitors etc.
Getting this kind of detail out of Agilent on how their software operates is nigh on impossible, as the lack of response to your post from any of the Agilent reps on this forum tends to indicate. I feel obliged to say though that at the time I had the problem, I don't think I checked the 'knowledge base' in any detail - however my guess would be that it is quite likely that no such info on this area exists there either...
If your circumstances are similar, then it would be nice to know what else IPG might be checking for in the test file!
Hi jayargent - this doesn't sound like normal behaviour because really all you should see is a entries in board file for parts that are in fact different.
you make the new versions entries into board file either manually or using board consultant and that eventually is reflected in testorder - which is reviewed during IPG test generation. So what should be generated as a version should follow the definition inside the board file. If this is not the case then you should call Agilent support team with software details.
details of what IPG does are explained clearly in the user fundamentals training classes that i assume most users have been on.
I should add that this is a open forum platform for ICt discussion and not an Agilent support forum - we do have a dedicated support channel.
I have found that if you have selected any version other than *base* in Board Consultant and press the 'replace device' button, for whatever reason, that version now has a dedicated test for that device. This can be handy when a board has devices that are identical between different versions but perform and test differently between the versions.
Considering my last response: The fact that I raised is an important one in that if you have an identical component in different versions, opto relay OP01 as an example, that has an input drive that is configured by zero ohm resistors that vary between versions, OP01 will require different tests between versions.
The smoothest way I know of the get multiple OP01 tests for each version is to load a board in board consultant, then open the device window for OP01 and click 'replace device'. This will do all the proper housekeeping of creating the testorder entries and OP01 tests for each version.
I had a number of transistors that were incorrectly specified as the wrong type in the board file (NPN for PNP): following the initial development (not done by me!), this had been spotted, and the solution clearly adopted was simply to change the 's' and 'i' bus connections in the actual test. When I came along to introduce a new version, I marked all the tests known to be good as 'permanent' in the testorder, including these transistors, and was baffled as to why IPG then wanted to generate new tests for these transistors in the new version, even though they were not different in the new version. When I spotted and corrected the incorrect type set in the board file, the problem went away, but it shows that IPG is not merely checking to see if a test file exists for a device, it is clearly looking at what is in the file in some detail in order to determine if that test is good for what it believes it wants (in the transistor case the type is given in the 'beta' test part of the test file, but whether it is using this for its judgement or is actually checking the connection set I couldn't say...). What level of detail it is checking to I couldn't say, nor whether this might affect other 'simpler' components like resistors, capacitors etc.
Getting this kind of detail out of Agilent on how their software operates is nigh on impossible, as the lack of response to your post from any of the Agilent reps on this forum tends to indicate. I feel obliged to say though that at the time I had the problem, I don't think I checked the 'knowledge base' in any detail - however my guess would be that it is quite likely that no such info on this area exists there either...
If your circumstances are similar, then it would be nice to know what else IPG might be checking for in the test file!
Tim