Parallel testing(programming)

[Bjarne Joergensen]

Hi

 

I have a challenge on a test system.

I have a PCB where there is an IC to be uploaded with the code.

It takes ~5 min. per. PCB.

To follow takt time it must be possible to program up to 5 at a time.

It should be done in the way that the operator can start a PCB independent of the other PCBs are startet!

 

Programming is startet and monitored as follows.

1. The operator sets an SD card in the PCB and press start.

2. The test opens a serial port to the board and turn on the power to the board

3. PCB runs the programming process itself and sends information via the serial port.

4. The test system monitors data from the PCB and act in relation to output.

5. When the test monitor that programming is complete, it switch off the power and serial port.

 

I have made some handling of startup etc. but are unsure of how parallelism must be inplemented.

I have thought that it must be with VI server so I start a VI for each UUT running process in the background, but is there also a possibility with LVOOP?

 

By the way. it has to be programmed in LV8.2.1

 

Thanks in advance

 

Bjarne

[hooovahh]

By the way. it has to be programmed in LV8.2.1

Wholly crap cakes.  Why not LabVIEW 3?  If this is a legacy program I understand.  Otherwise the time taken to implement this in 8.2 would be better spent upgrading.  Seriously in 2011 there was the addition of static VI references, and Start Asynchronous calls, along with the two reentrant options, which I'm not sure when the shared option was introduced.  Oh and in newer versions LabVIEW's for loop has parallelism built in, but I'm not sure that would fit this design.

 

That being said this type of thing has been done in 8.2 (and older).  Back then it was common to make a VI template (.VIT) then open new references to it, set control values, and invoke run using VI server.  There was added work to ensure that the VI was added to the built EXE, and that the path could be found, or at least the VI name but it could work.  As much as I hate using VITs (because they have been deprecated more or less today) I think they would work well for you.

[Bjarne Joergensen]

Wholly crap cakes.  Why not LabVIEW 3?  If this is a legacy program I understand.  Otherwise the time taken to implement this in 8.2 would be better spent upgrading.  Seriously in 2011 there was the addition of static VI references, and Start Asynchronous calls, along with the two reentrant options, which I'm not sure when the shared option was introduced.  Oh and in newer versions LabVIEW's for loop has parallelism built in, but I'm not sure that would fit this design.

 

That being said this type of thing has been done in 8.2 (and older).  Back then it was common to make a VI template (.VIT) then open new references to it, set control values, and invoke run using VI server.  There was added work to ensure that the VI was added to the built EXE, and that the path could be found, or at least the VI name but it could work.  As much as I hate using VITs (because they have been deprecated more or less today) I think they would work well for you.

 

Thanks hooovahh

 

I'v done it with Labview Server this way

 

I have to dive in the static VI references and Start Asynchronous calls because I also use LV2013

 

/Bjarne

 

PS: How does a "wholly crap cake" look like

Edited April 9, 2015 by Bjarne Joergensen

[hooovahh]

Yeah that's a little extra work, but more or less what I was suggesting.  If you have a VIT, and open a new reference to it, it will make a new instance that is in memory.  So you don't need to mess with copying files or generating new file names.  Just make a VIT (rename a .VI to .VIT) then pass that path to the Open VI Reference, and with the options left at 0 it should open a new reference.  If you wanted the reference to the VIT file, and not a new instance you'd use 0x02 as the option on the open.

[Bjarne Joergensen]

Yeah that's a little extra work, but more or less what I was suggesting.  If you have a VIT, and open a new reference to it, it will make a new instance that is in memory.  So you don't need to mess with copying files or generating new file names.  Just make a VIT (rename a .VI to .VIT) then pass that path to the Open VI Reference, and with the options left at 0 it should open a new reference.  If you wanted the reference to the VIT file, and not a new instance you'd use 0x02 as the option on the open.

 

Made the VIT and it works      

 

Thanks

Bjarne

[ShaunR]

You don't need to use VITs. A reentrant VI is perfectly fine. Just open it with 0x8 flag. Then you don;t need an external template file and it can be self contained in the executable.

 

If you look at the Dispatcher Demo. It has a VI launcher that is used to launch a number of Publishers and Subscribers dynamically. It also does some extra stuff like position  and show/hide the FP (useful for debugging).

Edited April 9, 2015 by ShaunR

[hooovahh]

You can still have it be self contained in the EXE, you just need to convince the application that it is a linked dependency, by adding a place that loads the VI into memory, but doesn't actually call it.  Then load the VI from name, or from the path in the EXE if you know a way to get that.  The 8.x era and newer had a flat EXE structure, so this was a common way until libraries and name spacing came about.  But yeah you're right, the Preallocated clone existed in 8.2, probably introduced in...8.0?

[jgcode]

Wholly crap cakes.  Why not LabVIEW 3?. 

 

lol. 8.2.1 is/was one of my fav LabVIEWs

[ShaunR]

lol. 8.2.1 is/was one of my fav LabVIEWs

Well bugger me!!!! Welcome back stranger .

[hooovahh]

lol. 8.2.1 is/was one of my fav LabVIEWs

For me it was 7.1 but that doesn't mean I would ever attempt to start a new real project using it.  Maybe its just the nostalgia.

 

EDIT: Stupid spelling mistake.

[Neil Pate]

 Maybe its just the nestalgia.

 

Is that like home-sickness for birds? 

[hooovahh]

Is that like home-sickness for birds? 

Obviously I was referring to the online role-playing indie video game for Windows.

http://silkgames.com/nestalgia/

 

...

[agilentvee]

sorry for my poor English at first

 

why not use USB-RS232 adapt? it can use more than 5 channel at parallel

[hooovahh]

why not use USB-RS232 adapt? it can use more than 5 channel at parallel

I think you are confused, this discussion hasn't been about the hardware used, but instead an effective way of doing the software architecture.

 

And for the record I hate having 5 USB to serial devices.  They might get re-enumerated to the wrong ports, power can be an issue with many of them.  The FTDI chipset can be slow especially if there is lots of data, etc.  The plus side is they are cheap, but I'd prefer a single USB device that has 5 (or more) COM ports, over 5 single port devices.  On the desktop and PXI there is also cards that add physical ports but these are usually more expensive than one USB device.

[Jordan Kuehn]

They might get re-enumerated to the wrong ports,

 

....

 

On the desktop and PXI there is also cards that add physical ports but these are usually more expensive than one USB device.

 

This.  It can be very frustrating when Windows decides to rename all of your ports.  Sure you can add additional code, but it's easily fixed with a better solution as mentioned by adding a physical interface card.

[hooovahh]

This.  It can be very frustrating when Windows decides to rename all of your ports.  Sure you can add additional code, but it's easily fixed with a better solution as mentioned by adding a physical interface card.

I've done it both ways.  Dedicated hardware, or software that finds the hardware usually using a known query like the serial number of the device.  When "Software is free" managers would rather not spend more money for hardware, when all it takes is a few hours of your time to design, develop, integrate, test, verify, and document...