CAE Integration has partnered with Etoolsmiths to provide services and support for the J-Tester Functional Test System. To read more about the benchtop production tester you've always wanted but never knew existed, click below!

How CAE Integration can come and fill in the gaps of testing. Below is a project CAE Integration worked on for a company that needed multiple testers at once. Leverage our in-house electrical and mechanical design, machining, 3D printing, and assembly capabilities to customize your enclosures or produce turnkey fixtures for you. What does CAE Integration do? CAE Integration is focused on assisting OEMs in bringing new products to market, ramping up production, and supporting the manufacturing line. We specialize in meeting the needs of manufacturing while cutting the burden on engineering. With our team designing and supporting tests that meet your manufacturing team’s process, your development team can focus their time and energy on developing the next product. Need Turn-Key Fixtures? We write the test plan, translate it into a fixture design, then write and debug the test programs execute tests on your products. We support the fixture during handoff to your internal team, your CM, and into production. Need Existing Fixtures Updated? Do you have legacy fixtures that require updates? Wear Component lifecycle issues OS/Network/Security requirements Here at CAE Integration we take any work that your company has performed and use it to fuel the design process. Depending on your needs we can completely redesign the test fixture or simply make updates to increase the longevity of the equipment. If wear and tear is a problem we can either source or manufacture the components you need to replace what needs fixing on your fixture. Finally: Surge Capacity Your in-house test team is busy on new products and just needs someone to revitalize legacy production tests. The company above needed to move legacy fixtures to a new CM but their staff was busy working on new products. The legacy testers were not permitted in the new facility due to an older versions of Windows. There were also various flaws in the test fixtures that needed to be addressed. CAE Integration migrated the test software, updated the test programs and mechanical fixturing to fit the latest boards, and came on-site to assist with set-up and validation tests. We completed the project in time for the company's transfer deadlines while keeping costs low using all in-house capabilities. Together, let's build a future where quality and innovation go hand in hand, ensuring success for your products and satisfaction for your customers.

In the ever-evolving landscape of manufacturing, low-volume Original Equipment Manufacturers (OEMs) play a crucial role in delivering specialized products tailored to niche markets. However, amidst the drive for innovation and speed to market, one critical aspect often overlooked is testing. Today, we'll delve into why testing is paramount for low-volume OEMs and the consequences of neglecting this crucial step. Why Test? Testing isn't just a checkbox on a manufacturing to-do list; it's the backbone of quality assurance. For low-volume OEMs, testing serves as a safeguard against potential defects, ensuring that each product meets or exceeds customer expectations. By subjecting products to rigorous testing protocols, OEMs can identify and rectify any issues before they reach the hands of end-users, thereby safeguarding brand reputation and fostering customer trust. Consequences of Not Testing Unsupervised Field Testing: When OEMs forego formal testing processes, they inadvertently subject their products to unsupervised testing in the field. This scenario arises when customers become unwitting testers, discovering flaws or malfunctions during real-world use. Such instances not only result in customer dissatisfaction but also incur additional costs associated with product recalls, replacements, and damage control. Unregulated Staff Testing: In the absence of structured testing procedures, some OEMs resort to ad-hoc testing conducted by internal staff. While this approach may seem cost-effective initially, it tends to bloat over time with redundant tests because it lacks the rigor and objectivity of formal testing protocols. As a result, critical issues may go undetected, leading to compromised product quality and increased liability for the OEM. The Cost of Cutting Corners The allure of cutting costs by bypassing testing procedures can be tempting for low-volume OEMs. However, the long-term ramifications of such decisions far outweigh any short-term gains. Consider the following costs associated with neglecting testing: Reputation Damage : Product failures due to inadequate testing can tarnish the reputation of the OEM, eroding customer trust and loyalty. Financial Loss : Product recalls, warranty claims, and legal liabilities stemming from untested products can result in substantial financial losses for the OEM. Missed Opportunities : By delivering subpar products, OEMs risk missing out on potential business opportunities and market growth. The Path Forward: Testing as a Strategic Imperative To navigate the complexities of today's manufacturing landscape, low-volume OEMs must prioritize testing as a strategic imperative. By investing in robust testing processes, OEMs can enhance product quality, mitigate risks, and differentiate themselves in competitive markets. At CAE Integration, we understand the unique challenges faced by low-volume OEMs, and we're committed to supporting your testing needs. Whether you require assistance in designing testing protocols, conducting tests, or analyzing results, our team of experts is here to help you every step of the way. Together, let's build a future where quality and innovation go hand in hand, ensuring success for your products and satisfaction for your customers.

Universal Functional Test (UFT): A Cost-Effective Manufacturing Test Development Software Platform. Compactness: When writing a functional test a common step is to look for the appearance of a specific phrase, then continue to the next step OR come to an error/default condition after a preset timeout. The following 8-line tcl/expect code snippet is built on to make a number of the basic procedure calls that make up UFT. : package require Expect catch {open "com1:" r+} s catch [exp_spawn -noecho -open $s] set timeout 10 expect { "Boot Menu" {set productType UbootMenu} default {set productType generic} } This small amount of code performs the following functions: Open a serial port and passes the port it to expect. Sets a variable “productType” to “UbootMenu” if the string “Boot Menu” appears anywhere in the text produced by the port within 10 seconds. Program execution continues immediately upon this condition being met. All other conditions including errors result in productType being set to “generic” execution to continue after 10 seconds. For comparison, the following table shows the lengths of similar sample code in several other languages. Since these are publicly posted samples they do not have the exact behavior as described in the above Tcl/Expect snippet. The deviations are noted in red and would take more code to achieve the desired result. Modularity: Reliable use of test software with different hardware is a basic building block of this system. Each UUT/Tester operation is abstracted to a generic procedure call. For each UUT type and each Tester component, there is a “personality” script file containing these procedure calls. Included in the same file are any parameters required to perform each necessary operation on the given device. Devices that are out-of-rev can be upgraded automatically to current-rev prior to test. This simplifies the burden on the test engineer by minimizing the number of test varieties that must be maintained. Custom content such as test machine configurations, test steps and limits are stored in configuration files. Auto-Recognition of UUT: The general-purpose UUT-thread is provided with specific strings output by the various product families early on in their boot processes. These are used in the “Waiting for UUT” state to determine which “personality” script to load for test. Further uniqueness broken down in the “personality” script defines the use of any combination of product characteristics such as model, HW revision, FW revision, SW revision. Each UUTs has a unique connection port, and is addressed from 1 to N by logical port number (whether local, terminal server, or chassis port number). Ports may be reserved for special functions such as firmware upgrades, so your operators don’t need to press any buttons on the computer to perform these steps. Disconnect Detection: Non-idle disconnect detection or “Crash” of the product’s CLI is always a possibility. This expectation is built into the low-level routines for interacting with the product as a “Timeout” error, generally a failure. Alternatively, there is an accepted issue in your product that occasionally causes negative results like a crash, UFT can employ fault-tolerance to recover and continue the test. Idle disconnects are disconnects detected during the idle state, when the Operator is expected to disconnect the product. UUT thread loops through simple commands such as LED diagnostics, receiving the appropriate command prompt back from the product. When a command prompt is not received within a UUT-appropriate timeout, the UUT is assumed to be disconnected. The UUT thread displays final results and prepares itself to detect the next new UUT. The results are cleared from the screen upon the detection of the next UUT. Logging: A unique logfile is generated for each UUT session. Taking advantage of the unique nature of physical interfaces, there can only be one UUT at a time per test station and port number. Adding a timestamp to those details makes a unique filename as follows: [TestName]_UUT_[StationName]_[PortNumber]_[Time_Datestamp].log At the end of each test, logs are immediately sent to the server via fault-tolerant mechanism so that production does not stop for network/server issues. This provides an indelible record of the test while permitting production to continue even while your network is down. If the same UUT returns to the tester several times, the logs are NOT appended nor overwritten – there is a unique log for each session. All communication with the UUT or test equipment is in the form of a command-response dialog, which at times results in multiple dialogs going on simultaneously. Fortunately, there is a standardized, plain English way to track a dialog involving multiple parties. Logfiles are in playbill script format as follows: [Timestamp][Speaker:Port]:[Message] This allows technicians to view the events chronologically, or find specific events with a search. UUT logs do NOT key in on the keywords in the “expect” statements, instead recording comprehensive records of everything said by all parties. Some tests produce graphical, directory structures, or other digital collateral. This is captured along with the log file and submitted to the central repository in zip format. For More Information If you have an questions or want to know more, click the button below to email us or schedule a meeting.

Universal Functional Test ( UFT ): A cost-effective manufacturing test development software platform. J-Testr : A hardware and software platform designed for straightforward and re-usable development. High-Cost Problem Functional test in the manufacturing process requires custom development due to the unique nature of each product. The manufacturing mindset is to minimize or eliminate custom work, as it is neither inexpensive nor easy to scale. There are three general approaches for development of manufacturing tests, each with its own pressure against reusability: 1.) In-house test engineers at the end of the New Product Introduction (NPI) cycle are often under pressure to win back delays that have accumulated all along the development process. 2.) Outside test resources are generally constrained by the project bid, which is optimized for the product in question rather than reusability. 3.) Quick-deploy off-the-shelf functional test solutions generally lack key features which much be added later by returning to approach 1 or 2. Solution: Reusable Test Technologies UFT is designed from the ground up to automate the functional test processes to the greatest reasonable extent in order to: 1.) Optimize test developer and operator’s time, increasing productivity and decreasing cost. 2.) Reduce operator error, increasing productivity and avoiding false-passes, which can result in Out-Of-Box Failure or OOBF. J-Testr takes a similar software approach but leverages its own hardware platform. 1.) Supports both open-frame or clamshell “pogo-pin” fixture approaches. What about clamshell fixtures? While it is possible through complicated fixturing to “fully” automate a test process, many automated steps diverge into corner-cases which become increasingly expensive to automate for decreasing benefit. While clamshell fixtures necessitate full automation due to their restriction of technician access, open-frame fixtures allow access to the product. This fixture design approach opens up choices for cost cutting that are supported by both UFT and J-Testr . The goal when developing an open-frame test is to pick all the low-hanging fruit and cover critical features, allowing the operator to make some judgment calls at higher levels of complexity to save time and money. These platforms achieve this by providing easily reconfigurable dialogs for interacting with the operator. What about intricate functions? Any step deemed too expensive to automate is offloaded to the operator with simple, well-written instructions and/or pictures. These value decisions occur at various points in the development process against a test plan and can be handled with a minimal amount of interaction between the test engineer and the product team. Since the manual steps are easy to set up, there is little effort wasted if the decision to automate comes later on in the product’s lifecycle. What sets these solutions apart from others in the industry? Built for scalability and reusability, both UFT’s and J-Testr’s libraries of test routines have been growing for well over a decade. While they already include subroutines to perform many tests needed, each overall test plan is customized and the library expanded to ensure a given product meets its specifications. When a product fails a test, the operator is presented with details from the test and optional diagnostics relating to specific components. These test solutions ensure each manufactured product is correctly… Moving itself Measuring Analyzing data Doing whatever the product does … and is ready to be included into the next assembly or shipped to a customer. If you have any questions please send us an email or talk directly by scheduling a Calendly meeting. Click below.

Universal Functional Test (UFT): A Cost-Effective Manufacturing Test Development Software Platform. Production is a continuous operation. Each unit must endure a series of tests, but it will also be followed by another unit. A state machine is used to usher a single product through test in a controlled manner, resetting for the next product. The Process The program initializes the designated port for communicating with the Unit Under Test (UUT), then waits to hear from it. As the UUT boots up, it announces various pieces of information which are used to identify the UUT and load the appropriate test program. When immediate start is not desired or for products that don’t identify themselves, the operator scans a barcode or selects from a drop-down to select the product. A an optional “start” button allows the operator to initiate the test. The test script is generally a list of steps with attributes like diagnostics and critical failures (end test without proceeding to the next step). Procedural or decision-tree code can be added for optimal performance. For instance a top-level test that confirms that many things are correct can be followed only on failure by sub-tests that provide further diagnosis. Upon completion of the script, UFT waits in an idle state until the UUT is removed, then resets for the next UUT. Questions? If you have an questions or want to know more, click the button below to email us or schedule a meeting.

Universal Functional Test (UFT): A Cost-Effective Manufacturing Test Development Software Platform. Reuse and Scalability Before the First Line of Code. CAE Integration uses Tcl/Tk for the versatility of the language. But the most important aspect of this software is its reuse and scalability even before the first line of code. After a survey of programming languages, Tcl/Tk was selected as the base language of UFT for the following reasons: Cross-Platform Tcl/Tk is a cross-platform language purpose-built to write middleware programs. The language’s author, John Ousterhout, named it Tool Command Language (Tcl) when he designed it to automate many CAD design operations in different applications. It has since become an integral part of Xilinx Vivado design suite and other FPGA tools. Interpretation Tcl is an interpreted language, allowing the developer LIVE DEBUG capabilities. There is no need to stop the test, recompile, or get the product back to a specific state to debug the test. The test engineer can interactively query, debug, alter, and rerun the code from the Tcl command shell while the program is running and the product in the required state. Extensions and Sourcing The Tk graphical extension to Tcl is a high-level language for generation of GUIs with minimal coding. Tk is open-source and extensible, providing simple methods for inclusion of tools developed by a community of open-source contributors. Expect Expect – the number one Tcl/Tk extension for manufacturing. Originally developed for taking scripted control of a command-line program to the next level with interaction (Don Libes 1990), this language is ideal for interacting with any hardware that presents a command line interface (CLI) whether it be over serial or network connection. UFT uses Expect to communicate with: Unit Under Test (UUT) supporting command-line interface Programmable test devices such as Standard GPIB test equipment Bulk call generators Network Switchgear Test equipment with non-standard interfaces In Summary Tcl/Tk is the language CAE Integration loves most. Not only is it versatile and cost-effective, but the LIVE DEBUG capabilities highly accelerate development of the interface with your product and test equipment. Click below to email or schedule a demo.

If we had a crystal ball, we would only test the bad boards. But we don't, so why do it? Often a company with a new product is so excited to introduce it that manufacturing test is overlooked.  Products roll off the assembly line and some staffers turn them on and use them before shipping them.  This can go well for a time but eventually one of the following problems occurs: A customer has a bad out-of-box experience with a product that fails in a way not covered at test. A “bad batch” of product is produced and many units can’t be shipped. Should We Go To The Design Engineer? From here it is natural to ask the product’s designer(s) what to do about it.  The designer is usually already assigned a new product to develop and is responsible for keeping the other project on schedule.  As a result the problems reported by the manufacturing team are generally interpreted as minor projects to be completed as quickly as possible.  Often the designer has jigs used personally during prototype to validate the design, and provides or adapts one or more Design Validation Tests (DVT) to production.   Design Validation Tests Effectiveness When DVT tests are used to diagnose individual problems that occur in production, they can initially be quite effective.  Each DVT test covers one feature in depth and can provide a lot of insight for a problem within its scope.  The in-depth, investigatory nature of DVT makes it time consuming to apply.  This frustrates the manufacturing team when products pass the test because of the time and money spent running the test on a board that did not “need” it.  What manufacturing needs is tests that cover a breadth of hardware quickly. W hy not go back to the design engineer and get the DVT test adapted for manufacturing?   Here are the Differences: Manufacturing tests are much different from product design and validation.  It takes time and practice to get good at developing manufacturing test.  You pay your design engineers to be good at designing products.  Why pay your product designers to stop designing and learn how to develop manufacturing tests?  And find a go between to get the needs of the manufacturing team implemented into the test solution. . . Ready to Take the Next Step? OEMs hire us to develop manufacturing tests so their design teams can focus on developing the next product. CAE Integration specializes in meeting the needs of manufacturing while cutting engineering burden. Hit the button below to set up a meeting.

Tcl-Expect Rumors Expect was originally intended to allow programmatical interaction among various programs on Linux and Unix operating systems.  UFT primarily uses Expect to interface with equipment rather than programs. For a better understanding of why this distinction matters, it is important to understand a few fundamental differences between Windows and Linux.  In Linux and Unix everything is a file.  Not just most things, not just normal things, everything everything is a file.  When opening a file the caller has control over whether and how the input and output pipes are connected – a requirement for interactive control of a command-line program.  Since Tcl/Tk is cross-platform it was also ported to Windows, which at the time permitted connection of input and output pipes to the calling program – if the target program was compiled with that in mind.  Microsoft uses Windows to sell various products and services, and occasionally introduces new and/or discourages old interfaces for inter-process communication (IPC) such as: DDE COM Shared Memory File Mapping Sockets RPC ALPC Compatability Backward-compatibility has been a historical feature of Windows, but certain features are left by the wayside each time the number of bits in the instruction set increases (16-bit, 32-bit, 64-bit).  Expect works with programs written for 16- or 32-bit Windows, such as Cygwin and all of its utilities.  Expect for Tcl/Tk also has a handy quirk echoing the entire dialog to the Tcl console – which is really handy in the manufacturing test environment. Modification Since UFT primarily uses Expect to interface with equipment rather than programs, Windows restrictions on inter-process communication generally don’t come into play.  For occasions where we need Expect to interact with something Windows actively blocks, we developed a Linux bridge.  Since Expect for Linux does not handily display the entire dialog in the Tcl console like the Windows version does, we added this functionality into the Linux bridge program. Please leave a comment, and share your own TCL - Expect experience. To learn more click the button below to contact us.

How we tackle Functional Test Why connectors are the way to go for functional test. While shorts on connector pins are a problem, these are easy to find.  Opens are the manufacturing defect on connectors that make OEMs lose sleep at night.  More technical diagnoses for opens include cold solder, no solder, lifted pin, etc. These can be caused by a variety of minor processing, handling, or supply-chain issues. But why not use flying probe or clamshell? Drawbacks to Flying Probe or clamshell Pogo-pins such as Flying Probe or clamshell fixtures can fully test connectors that are: Rugged. Pointed in one direction. Not subject to false pass under mechanical load. A Not subject to relocation due to design changes. Pogo-pins must press the connector pin against the board.  This is not a test feature with options but a law of physics affecting all pogo pins because they are spring-loaded. In the case of an open defect, the pogo pin can force the connector pin to conduct only during the moment it is tested – a false pass.  This test challenge affects all surface-mount connections.  While some through-hole connections can get excellent coverage using pogo-pins, these connectors are often presented to the user.  In this case a test-mate to check for bent pins and mechanical defects can avoid embarrassing Out-of Box Failures. Why we go with connectors The only way to guarantee the performance of the connector is to test through the connector. Also, when cables are selected for the UUT connection, it opens up cost savings opportunities regarding test coverage.  Connectorized test allows the fixture to be constructed in an open-frame fashion allowing your technicians to diagnose failing boards by probing with their oscilloscope or multimeter.  This means the functional test code can focus on a top-level PASS/FAIL result drastically reducing the amount of code required for the test. Clamshell fixtures just don’t offer access to human measurements. If you want to learn more about Functional Test, click the button here to read. Contact CAE Integration today for a test plan optimized for your specific product.