| Electronics > Projects, Designs, and Technical Stuff |
| End-Of-Line test system |
| (1/2) > >> |
| css:
Hi all We are building a new End-Of-Line test system for an electronic unit and seek some advice. Attached is an illustration of the setup. The main purpose is to make the EOL test system easily scalable. In short, the system is designed as follows: 1. A PC is connected to several "test rigs" using Wifi 2. Each test rig consists of a raspberry pi zero w + a custom board (with relay, measurement point, connections to the PI, etc.). 3. A Device Under Test (DUT) is connected to each test rig. What we would like to do is to initiate the tests from the PC and get the results back on the PC. The execution of the test sequence is done by the RPI. The test sequences may differ depending on the configuration of the specific DUT. Currently, our solution is to use Jenkins on the PC and let Jenkins initiate test jobs on the RPIs. The test jobs will be written in Python and will report back to Jenkins if the test was successful or not. We seek advice on the following: - Any "control software" better suitable than Jenkins on the PC? - Any Python frameworks suitable for EOL testing? - Any Python reporting systems which integrate easily with Jenkins (or an alternative control software)? - Any alternative ways to accomplish above? - Any experiences with EOL-testing at scale? Looking forward to your replies Thanks Br Christian |
| gmankev:
Its a while since I worked on a python test framework, but we did a lot of hardware test with custom DUT and interface boards. Some of this may easily be covered in now in standard test frameworks. -) Eliminate all manual work of setting a file here, running a script there, there will be mistakes.. - ) try and appoint local masters of the framework who really care about its efficiency and running tests well 1) Use a stable configuration in git and check it out new every night to your rpis.. You dont know what local design went on that day desigining the test 2) have your test scripts 'require items_of_infra' then let your test runner query the environment, or stored state to define which rpi is best suitable for the test 3) Have standard reporting methods, that can be easily graphed 4) try and work hard to have standard test suites that run quickly for regression, and add on the new test suites at the end. 5) aim to batch your tests and prepare to reassert a stable config when tests start failing. 6) have standard calls to restart, gather crash data, and run them similarly in all test suites 7) methods it reserve test equipment, so that batches of tests will not overrun one another or interfere with someone elses late night debug 8) have simple ways of reading the hardware id of hte custom DUT or interface board. After months of work, you can easily have variations in test rigs that will be useful to know and record 9) make sure your batch method can quickly run short tests quickly so that engineers have the one environment for all tests |
| max_torque:
Personally, unless there is a very good reason to use it, i'd avoid wireless coms! Given the ease of implementing wired coms and the robustness of those coms, wi-fi seems an unnecessary extravagance to me! |
| css:
Hi, thanks for the feedback. gmankev, you have some really good points, thanks. max_torque, I agree that it would be nice to avoid wireless, however, I think the formfactor of the PI Zero is better suited for this application (compared to the regular PIs) - unfortunately, it does not have wired ethernet. Any suggestions on the python test framework? seems that most test frameworks are designed towards testing of python code ("unit-testing") not "system-testing" of devices. |
| coppercone2:
i recommend you use isolated connections to prevent ground loops and fortify those interface electronics with lots of protection if you are making home brew assembly line test equipment. the last thing you want is a batch of damaged products going out damaged by the testers. and probobly a verification procedure for the tester to be performed once in a while to make sure its right, being calibration, voltage level tests, jitter, glitches, etc. they did not design a raspberry pi for industrial manufacturers its a learning computer. and put everything in shielded boxes, give the PC a surge protector and use ESD precautions. and if its part of your ISO procedures and something breaks your line is going to go tits up until its fixed. a serious recommendation would be to have a duplicate PC system in case it breaks, then 5 years later it stops working because some hard to find incompatibility issue. Factories end up running windows 2000 machines in the year 2018 with software that depends on the old windows etc... but it can probably happen anywhere, last thing you want is a high priority weird software problem and keep in mind how much RASPI changes over the years. I have had issues with raspberry pi software working on the older models but not the newer ones. i thought linux would be magic but it just ended up pissing me off. |
| Navigation |
| Message Index |
| Next page |