← Back to Portfolio List
CLD Exams explained
Download my CLD certificate obtained early 2014.
click here.
The following is taken direct from National Instrumnet website
This link explain CLD exams by NI
The NI LabVIEW certification path includes three steps:
1. Certified LabVIEW Associate Developer - This certification indicates a broad working knowledge of the LabVIEW environment,
a basic understanding of coding and documentation best practices, and the ability to understand and interpret existing code.
2. Certified LabVIEW Developer - At this level, an engineer has shown the ability to design and develop functional programs
while minimizing development time and ensuring maintainability.
3. Certified LabVIEW Architect - Architects have demonstrated that they have reached the highest skill level and
can develop a framework for an application to be executed by a team of developers if given a set of high-level requirements.
The second step is the Certified LabVIEW Developer, which indicates the ability to design and develop functional programs
while minimizing development time and ensuring maintainability through proper documentation and style. You can use
this certification for assessment and validation of an individual’s LabVIEW development skills for the purpose of project
staffing or career advancement.
Net page Force Sensor Tester
Main Front panel of SAT-FST
Download the documentation for the project.
click here.
This link is a YouTube link to the pen in action
The purpose of the jig is to test the mechanical and electrical operation of the force sensor after
heat-staking to the pen chassis.
Note the jig can be fitted with an alternative nests to hold a fully assembled pen or just the force sensor
spring for a similar test. Although each type of nest is described in this document, only the process that
uses the chassis nest is covered by the operating instructions.
Some of the flow diagrams documented
The top level flow diagram.
Loop in here until the operator presses a button.
Wiring diagram of SAT-FST
Following is a simplified version of the th SAT-FST wiring
Block Diagram of SAT-FST
Following are some of the parts of the SAT-FST block diagram
A JKI state machine used to run an individual test.
After running a test of SAT-FST
Following is a screen shot of a force sensor results & the GUI
Debug screen of SAT-FST
Following is a screen shot of a the debug screen
Inside Atomflo 500
Description of required test
The following is taken from website.
www.premecha.com;
Download the documentation for the project.
click here.
Download the documentation to see what test report looks like.
click here.
Surfx Technologies Atomflo high-speed
atmospheric plasma systems introduced
solutions for many industries:
• Semiconductor manufacture
• MEMS
• Aerospace composites
• Pharmaceutical and biomedical
• Solar
• Metals and plastics
The new Atomflo 500 provides an enhanced
atmospheric plasma facility:
• Argon or helium as primary gas
• Tertiary gas capable
• 8” touch screen HMI with ease to use
interface for monitoring, configuration,
data logging and recipe management
• Improved tuning and matching system
This is what the Atomflo500 generates, a plasma strip
The plasma intensity and uniformity are checked automatically using a fire wire camera.
Different levels of power and gas combinations are applied, and then a number of images taken and checked against a template.
Testing with TestStand and LabVIEW
A TestStand sequence with some custom step types.
This makes it much easier to develop a sequence and use that instrument in the sequences, and in
any other sequences developed after that.
It's a for of OOP, allowing reuse of code.
Example of DMM custom step type being used.
Normally custom step types are set up for each instrument used by the system.
Here we can set u the DMM to measure 4-wire resistance.
Step Type actually developed in LabVIEW
Front panel of the VI that actually drives the DMM instrument. A bunch of clusters are passed to this VI from TestStand
Block diagram of wrapper
Here the subvis from the actual driver are called to control the instrument.
The Agilent 34401 is a very common instrument, so getting a driver for it is easy, sometimes drivers have to be developed from the ground up,
but generally there is something similar to use as a starting point.
Interfacing to the Instrument
Here we have a bunch of clusters that store the information about the setting of the instrument.
Main Tilt Chair GUI
The following is taken from website.
http://www.premecha.com/our-experience/case-studies/neural-diagnostics.aspx
Download the documentation for the project.
click here.
Requirements
This project was a developed for a customer,
The main objective was to develop a chair (similar to a dentist chair) that can be tilted at 45 degrees,
rotates 90 degrees, tilts back by 45 degrees. These motions all controlled from a computer.
There is a set of headphones on the subject, with electrodes in the ear, which record electrical noise created
from the inner ear. The PC software controls the stepper motors to move the chair and records and graphs
the data from the inner ear.
A doctor then analysis the data returned from the inner ear, and can profile the mental condition of the subject allegedly.
Hardware block diagram
Main Tilt Flow Diagram
LabVIEW Block Diagram samples
Again a producer/consumer loop was used, as it's much easier to do further development on.
A bunch of queues are initially set up, one for the stepper motor and another one for the controller board
Messages are sent this queue, and it handles the task,
giving time for the main GUI to be more responsive to the user, and to complete other tasks if need be, for example update the graph.
Our first 8 slot PXI chassis system built in Australia
This tester was developed & programmed up by myself in Adelaide Australia.
It's main objective was to perform a finished goods test on a number of different 240 volt dimmers or relay Clipsal C-Bus products.
So there were a number of different jigs designed for each produce, then the jig plugged into the back plain of the tester.
This gave us the ability to test multiple but similar products on the one tester, as quantities might not be that great of each product, a few thousand a year of each product.
But when a number of different products were put on the one tester, now the tester was up at 50% capacity.
We then developed another similar tester, but this time without the expensive AC source, as we were only testing low voltage products, and again a number (10+ the last time I looked)
different fixtures/jigs were built to hold each of the different DUTs.
Both testers were then sent to different parts of China, to two different manufacturing sites.
I also went to China to help train local staff, and help with the ramp up, because transfer was happening very fast.
An 18 slot PXI system, based on the previous 8 slot version
During my time in China I worked with a number of different contractors to build testers locally, thus making it easier to maintain the testers.
This tester was run 24/7 in our manufacturing site, if capacity went over,
we could get the local Chinese contractor to duplicate this one.
A closer look at the exchangeable fixture
The fixture at the front can be removed, and another one put on, thus allowing us to test multiple boards on the one set of hardware
A fixture removed, showing the connection panel
Simpler & cheaper testers
A simpler, low cost type tester built by local Chinese contractor (me stuck in the middle)
The disadvantage with this type of tester: it can only test one type of product.
A simple RCD Tester, again designed to test ONLY RCDs
A Typical New Product Development Plan
Most projects start off with a plan of what we are going to test in the product
(Design Engineers supply the product test requirements).
I would initially estimate how long it would take to design and develop the tester and how much it's going to cost.
This document is shared with all stakeholders involved for review/discussion and modification until an agreement it reached and the
plan is finalised.
Through the lifetime of the project this document is available to all stakeholders to view progress and status of the project.
Any issues are highlighted and assigned to the appropriate person/department to be addressed.
It is updated on a regular basis (usually weekly).
Upon agreement I would then approach 2 or 3 different contractors and set our requirements (costing - project timeline etc)
and request a quote from each one.
click here to view Test Requirements.
Once the contractor accepts the project and understands the requirements, I then manage it, this usually involves weekly on-site visits,
and provide any advice or guidance the contractor requires.
At this point I create additional documentation in relation to qualification of the tester. The next link is an example of this document.
This document will be supplied to the contractor, so they are aware of the tester qualification requirements.
This document will contain requirements such as : safety checks, licence and version numbers recorded, Gage R&R results,
CP & CPK values for each measurement, test times, expected first pass yield.
click here to view Qualification Plant.
After a few months of working closely with the contractor and completion of the tester, it is then qualified at the contractor's site based on the
qualification report. Once we are satisfied it has passed we then install the machine in the manufacturing site and re-run the qualification process.
The contractor is made very aware early on in the time that we won't accept the tester until it passes the qualification requirements.
click here to view Qualification Report.
Gage R&R (Repeatability & Reproducibility )
This is a tool often used to check/verify how stable the tester or product is.
Another method is CP & CPK Calculations to verify the repeatability of your measurement.
Here I generally develop a simple C# application to collect, analyse & graph data so this information can be put into a report and
reviewed by all stakeholders involved.
Here are two different test being analysed; 10 different products, tested 6 times, by 3 different operators, (gives us 60 measurements).
Without knowing too much about the system, you can clearly see that serial numbers AOONJ0, AOONJ8 on both measurements seem to be not as stable as the other 8 products.
The following explains Gage R&R pretty good..
http://www.qualitymag.com/articles/83529-quality-101-an-introduction-to-gage-r-r
A good measurement system has very low noise, preferably less than 1% of the total variability in your data,
indicated as a gage R&R of less than 10%.
A questionable system will have noise between 1% and 9% of the total variability,
or a gage R&R between 10% and 30%.
A poor system will have noise greater than 9% of the total variation, or a gage R&R greater than 30%.
Histogram the Data
Another way to look at exactly the same data.
Same as above we are looking at "Displacement_Last" measurement, we can see that 60 measurements of 10 different DUTs gives us a nice distribution
of the measurement.
The range is 107.25 to 124.4, so a good set of limits might be 100 to 130.
This time we are looking at "Spring_Constant" measurement, here there is a larger distribution, but using the Gage R&R graph we can see
that it's all due to one serial number, AOONJ8. So the question begs, is this DUT a good sample, would one of the design engineers accept this distribution?
The range is 5.19 to 6.4 (which is a wide range), so a good set of limits might be 5 to 6.6.
But I would also be looking to talk to someone about serial number AOONJ8.
This particular measurement is how much a mechanical spring moves, so the variation might be explained.
CP & CPK Calculation
Another way to look at data is something I borrowed from Six sigma training, cp & cpk.
This type of analysis is very useful if we actually have limits from the design group, if we don't have limits it can be useful
to attempt to recommend limits.
Again limits are usually supplied or at least okayed by design, not by test.
Cp And Cpk are the process capability indices.,Cp-Measures the variation., how close the measures readings.,Cpk - Measures the center tendency.,how close the measures readings to Nominal
The following is an example of a number of different measurements on a dimmer product for Clipsal.
According to Six Sigma a good Cp & Cpk value is about 1.5, anything below and your limits are a bit tight, anything above 1.5 and your limits are too loose.
Looking at the above table we can see that some of the measurements are less than 1, which is a real problem.
This actual product was put on hold, based on this analysis, until either design was fixed, or limits were widened by design.
Often the question is asked; "is it the product or is it the tester that is causing the variation??".
The tester can be easily ruled out by just running a similar test on the bench, and analyzing the results again.
Both methods are very good for taking a snapshot of what the tester can do at a point in time.
Ideally one would like to keep some of these products as "golden units", so the tester can be checked at any time.
Also very useful for generating reports and sharing with stakeholders
Review results
This section looks at viewing data being generated by a simulated tester.
Here I have TestStand simulating a test, and creating a .txt file for every board after test.
Also I have a sperate application written in C# that takes this .txt file, and pulls out all of the relevant information and put the data on a MySQL database on the cloud.
This app also moves the .txt file to another location for storage.
This app can also be used to analyse the FirstPassYield of the tester, and could be used to do Gage R&R or Cp & Cpk analysis on measurements.
What I like about this approach is:
1: The tester is not reliant on the network being alive, we can still test even if the network is down.
2: Once a database gets to a big size, it can often be slow to make SQL calls to it. This can increase test times, if it's the responsibility of the tester to put the data into the database.
3: LabVIEW or TestStand is often not the best tool to interact with databases, I'd prefer C#
4: The database would be on the cloud, so a simple HTML page could be done to view the data over the net.
So if you had a subcontractor building boards for you, you could almost see real time what they are at.
The following are some screen shots of what it might look like. (This is something I put together in the past week or so)
The app looks in a certain location c drive, (where Teststand puts results) every few seconds, is there .txt file there??
"yes" --> then push data up onto DB & update yields & tables, and move the file when done. If no file, do nothing only.
You can limit it just to today's results as opposed to all results.
If you are more interested in just one measurement, then you can also do that, shows FPY & values it got in the lower table.
With more work, one could do different searches, like on SerialNumber, Station_ID, User, etc... once you have the data on a DB you can do almost anything
Here we can do a Cp & Cpk on a measurement, the blue lines are the limits.
We can quickly see that there are 4 reads that are just at the wrong side of the limits, whch are the 4 fails.
To add cp & cpk valuse here are pretty easy task, or anyother method of anylsing data thet is required.
Above is an improvement I would be suggesting in future testers I develop over previous ones.
