06-26-2009 10:25 AM
I’m going to write a program that will test up to ten controllers at once. The test involves a 48 hour burn-in, then power cycling then another 48 hour burn-in while controlled by CAN, so the total test time is about a week. I want to be able to run the tests independently of each other. That is, I want to be able to start and stop the testing of each controller independently and replace a controller while the other tests continue to run. Each controller has its own power supply built into the test fixture and I’m going to use an Agilent 34970 switch box. My question is in Labview is it possible and is it the best approach to run 10 procedures, i.e. while loops, independent of each other, starting and stopping any of the 10 loops when desired to check or replace a controller, or should I consider an alternative approach such as what would be a very complicated state machine?
Thanks!
06-26-2009 10:51 AM
You mention switch box, so you have some shared measurement equipment for all 10 devices?
If so, you could just use a for loop and a flag for each fixture if it is operational or not (replacing controller), and if not operational skip the testing code.
Felix
06-26-2009 10:52 AM
I have done a similar project. I tried the parallel loop method and round-robbin in a state machine. I found the parallel loops to be much more convienent, for hot swapping, and if one unit started to hiccup or "get behind", it didn't stop the others from trucking along. I know this can be done with queues in a good state machine, but parallel loops are just more intuative, IMO.
10 loops seems like a lot, but it depends on the complexity!
Be cautious, with that many loops, about building arrays, concatenating strings, etc.
06-26-2009 10:56 AM
06-26-2009 10:58 AM
06-27-2009 09:55 PM
06-27-2009 10:40 PM
06-27-2009 11:44 PM
ctardi wrote:
I can't say too much about how I've seen this done, as it wasn't my project, but one thing to consider is that you may want the ability to update the code on individual test 'lanes' without having to stop all testing. Sorry I can't go into more detail. 🙂
Multiple, parallel tasks are easier to do in LV (or as smerc. Suggests TS) than in any other programming language that I've heard about!!!!!
That being said, consider that the people posting have exceptional experience with developing these types of projects. This question is NOT about the "best method" is it? I feel the root question is ____"how should my corporation define a policy for code development?"____
There are good resources available if (as I suspect) your organization lacks Test Engineers with current practical expertise. A consult with an NI Alliance member will be your greatest form of information!
06-28-2009 12:18 AM - edited 06-28-2009 12:19 AM
Hey Jeff,
I don't want to go too far off topic here, but the jest of it is that I am not a Test Engineer, the company I work for has a very talented group of test engineers, which I have expressed some interested towards joining at some point in time. My employer was nice enough to buy me a licence for labview so that I can learn it, but I do the learning on my time, and can't really depend too much on our team of engineers to teach me at this point. 🙂 I don't want to drag things too off topic here...
To hint a bit towards what I was attempting to say...We have a similar setup, multiple sets of 24 hour 'burn in', but they do not start at all the same time. The expected production numbers VS the budget means 0 down time for the rig. Software updates still need to happen. By dynamically calling a vi template, you can update the template without stopping lanes that are running.
06-28-2009 12:58 PM
ctardi,
I see what you mean now. I have solved for this in the past by storing multiple versions of the test to launch (renamed.) Use a configuration file to control which test lane uses what test version and launch that VI from the test executive. Your test vi's will need to be reenterant so you can launch as many as needed. Also all resources that the test vi needs should be in the config file as well (VISA names, com ports settings, data files etc...)