Jump to content

Parallel testing(programming)


Recommended Posts

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 :oops:
 
Thanks in advance
 
Bjarne

post-7489-0-02451900-1428571367_thumb.pn

post-7489-0-49854400-1428571363_thumb.pn

Link to post

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

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.

Link to post

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 :shifty:

post-7489-0-39583100-1428583195_thumb.pn

 

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 :rolleyes:

Edited by Bjarne Joergensen
Link to post

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.

Link to post

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 :worshippy:  :beer_mug:  :thumbup1:  :cool:

 

Thanks

Bjarne

Link to post

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 by ShaunR
Link to post

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?

Link to post

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.

Link to post
  • 3 weeks later...

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.

Link to post

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.

Link to post

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...

Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.