Automatic testing of electronic products - Page 1
Forum section: electronics / projects

author: BertP
author_rank: Newbie
timestamp: June 19, 2020, 04:51:55 am
content: Hi All,New member here trying to get some information on what manufacturers would like to see in an automatic tester.For 25 years our company has been using a couple of old DOS computers with a ISA card board to test the instruments we manufacture. The ISA card has A2D's, D2A's, digital I/O, signal generators and programmable power supplies with the ability to measure current.The test programs are written in Microsoft QuickBasic and test data is captured to files with date/time, testers initials and product serial number. Most products test in less than 2 minutes with minimal operator intervention.The old DOS box is on its last legs and we designed our own auto tester which uses a small Arduino like board called the Duinomite which has built-in micro SD card for program/data storage. It requires only a keyboard and VGA display to run.We would like to commercialize this product and are requesting information on what other companies might want to see in this product.Currently the system has:8 x 16 bit A2D2 x 12 bit D2A (which control two 0-25VDC programmable power supplies with current measuring ability)4 x 0-5V logic inputs4 x 0-5V logic outputsCapabilities to generate square wave signals up to 10Khz using any/all of the digital outputs.Serial data input/outputA video link to the above system testing an electronic battery monitor is on YouTube here:https://youtu.be/VE-1X-YreNoA few photos are attached of the AutoTester PCB and the small Duinomite computer that runs it. The Duinomite computer has a standard PS2 keyboard input, VGA output and micro SD card for program/data storage.We are keen to re-design this system to what other people need. What features would you need to use this autotester to test your products (how many A2D's, D2A's, programmable power supplies, digital I/O, ammeters, frequency generators, etc.)?Regards,Bert van den BergNew Zealand

author: JPortici
author_rank: Super Contributor
timestamp: June 19, 2020, 05:42:30 am
content: Later i'll see if i can share the photo or ours, which i developed over the last year..5 Analog out, 2 SENT out, four GPIO out, three digital out that can output in frequency or pwm. Each output is copied x416 Analog in, 8 sent in, 12 digital in, some with special pullup circuitryswitched 12V and 5V with current measurementprovision for communication and gpio lines on a secondary connector, to be used to implement programming and data download/uploadleds and buzzers to indicate the state of most thingsECU connector (because we had some laying around and more than 100f pins were used)To test our products we have some hardware testers built by hand, some boards with a different firmware and some NI DAQs, we wanted to try and make a single more powerful tester (because all of the others lacked in some way, especially on the software side)I looked around to see what was available and in my opinion everything i found either sucked somehow or cost an arm and a leg and probably worse required you to deal with labview and the need to keep an outdated computer because you know, this year's daq won't work with labview four years from now.Also we had some "special" needs like SENT which required that we either build an interface board and give the data via analog/digital means, losing all the diagnostics in the protocol, or we needed devices with programmable bits. Some NI boards would have the capabiltiy, but again crazy prices, labview and not so open protocol. ugh.I am planning to make my device standalone at some point, otherwise the API i came up with is very simple, one usb edpoint handles the setup (IO, configuration, test script) and another endpoint spouts out 32ms worth of data, plenty of time for the master to acquire, put in buffers and update the display..But i digress.What i didn't like of the available offerings was:- IO connections. Having stripts, terminal blocks or ICD is fine until you have to deal with higher speed or more than a handful of signals. Another solution is needed or you have to make it easy for the user to design in an interface board. Terminal blocks are the worst. After a couple of years those in the NI DAQs became loose and should be substituted- Most seemed to rely on either external power or VUSB for the analog supply. Worse, some also used it for reference. In our boards we technically need to test for 12V but most of the time 5V only is fine. But we need to test for 5V, not for 4.5 and something. In my board i put a sepic converter after VUSB. so the power comes from either the SEPIC or the 5V LDO. the SEPIC is switched off if power from the DC IN block is detected- I couldn't find an API document or a way to write my own application around it- I didn't find a way to program custom protocolsWhat could be interesting:Hardware that solves the first two problems above, and hardware that i can freely program myself. So having a schematic , to see if my custom application is feasible with the board. Just not having to build and test the hardware is a HUGE cost saver.To give a metric, i'm almost running at full capacity with the 8 sent in / two out, the program cycle is executed at about 40 KHz with a dsPIC running at 140MHz/70 MIPS. Most things are DMA'd but a good software SENT implementation takes lots of processing time. With a simplistic one, skipping most of the diagnostic, i could probably run the thing at half the speed