LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Program structure. How to manage two test fixtures in a final test

Solved!
Go to solution

I going to make a LV program for the final test of a PCBA. The equipment deals with two test fixtures. To register a test the operator scan a unique QR-code on the PCB. Then he press the button on the fixture. Each fixture has its own button. The application starts measuring different testpoints on the PCB and saves the data in a file. Each fixture has its own set of channels and the sampling speed are low (I'm using PCIe-6343).
There is a risc that the operator start tests so the measurements overlap but the risc are low because the test are finished in a few seconds.

 

My question is, how should I build up the program? Should I have two Event-structures in parallell? Each event reacts on respective button and then i call an VI that are common for both events. Of course, it have an input telling what fixture it should connect to. That VI has a while-loop with a case-structure that build up a kind of state machine that doing the tests. (btw, what reentrancy mode should that VI have? Shared clone?)
Is there any other way? Can I have two separate applications? Is that a possibility? What happens if they later want to have three test fixtures?

 

The scanner can have its own event-structure. The LV-program reads the code thorugh the UART connected to the PCB (the QR-code are also stored in a memory) and then the application knows in which fixture the PCB are placed, left or right. That means that the operator can scan and press buttons in a mixed order.

 

I am grateful for any input.

 

 

0 Kudos
Message 1 of 8
(220 Views)
Solution
Accepted by topic author Haddock01

I would recommend to use Queued Message Handler, but it is always up to your programming style; With QMH you could manage each fixture as a loop, so you could maintain one event structure controlling both fixtures or loops. This applies to n quantity of fixtures, I've controlled over 16 test stations with this architecture and the performance was OK.

0 Kudos
Message 2 of 8
(206 Views)

Great. Thanx. I needed that kind of input. I haven't worked with QMH before but I will check some examples and see if I can implement it easy. 

It's a great opportunity for me to learn something new in LV. I have only written code for big but simple structures. 

0 Kudos
Message 3 of 8
(170 Views)

I need a confirmation. Let say I have two test fixtures and I sample 5+5 analogue channels. In my mind I have one Event handler loop and one while-loop per fixture. Why one per fixture? They need to process data in parallel. I don't know when the Operator press the start button on each fixture.

I have also process that sampling the analogue channels continuously and the event Structure pick out the data when it needs to.

 

("Loop, One per fixture?" perhaps not needed if I make a VI that have channels as parameter and can operate as a clone)

 

0 Kudos
Message 4 of 8
(161 Views)

Sorry to spam you but I have tested QMH now and also tried different message parameters (data). I started with and tamplate and modified it. I can use cluster as data! It is so powerful so I need to take a step back and think of what I can do with it. 🙂

0 Kudos
Message 5 of 8
(138 Views)

I would prefer to manage 1 loop per fixture, so it can operate in parallel, write files separately, acquire data separately, apply error handler separately; there are some advantages in that.

 

Also you can keep adding "loops" or tasks with different functionality, you could add one loop dedicated to Database management, another for data display or GUI, and it are all communicated via messages.

 

It is my favorite architecture since I started using it.

0 Kudos
Message 6 of 8
(125 Views)

Ok. That feels natural.  I make one loop per fixture and each loop has its own queue? Correct? 

When I tested QMH during day, I looked at the event structure as an state machine. One event called another one in the same loop. When I pressed a button I saw the counter show three loops, 1) LED on, 2) sample 100 points, 3) LED off. Just a silly test.

 

0 Kudos
Message 7 of 8
(118 Views)

Yes, each loop works as a consumer loop with its queue reference, but the advantage is that you have all the queue references in a cluster so you can "access" or "message" each loop from anywhere in your code. But indeed a good management is to have a Message Handler loop which manages every message and distributes them where it is supposed to arrive. I'll recommend to see the project template in LV it is well documented and you can use it as a start point.

0 Kudos
Message 8 of 8
(91 Views)