The ScpiStudio Impetus
The Impetus
An Introduction and the impetus into a unique approach to writing test engineering automatic test engineering and/or automation programs for the electronic and software hobbyist, Engineering Student, and seasoned ATE/Automation test engineer.
Dedication
ScpiStudio is dedicated to my wonderful wife Sally, who has allowed me to take up space in her household and spend more money than she signed up for. This allowed me to pursue my dream for more years than both of us assumed it would take.
Also, I would like to give a shout out to my daughter Carrie, who allowed me to take up space in her household, when Sally and I would visit her for months on end.
And Alas, I would like to give a shout out to my son Matt, who finally moved out of my house in Arizona and moved to Denver to take on a “great job!” and took his demon cat with him.
Preface
I have been working for many years in the semiconductor, electronic, vision and automation industries, as an Application, Software Engineer, Test Engineer, and Automation Engineer. In 2002, I was begin conjuring a concept of writing a script language to control test instrumentation and eventually automation systems (i.e. those systems which contained data acquisition, motion control, and vision systems).
Over time, while working in the automation and test engineering industry full time, I tinkered with this ideal. Some of my colleagues, who knew about my idea, said “Are you nuts! How are you going to go up against the players?[1]”. I replied, “Pith balls off a battleship! You simply design and build a better product”. That product is ScpiStudio.
An Introduction: What is SCPI?
The Standard Commands for Programmable Instruments (SCPI; often pronounced "skippy") defines a standard for syntax and commands to use in controlling programmable test and measurement devices, such as automatic test equipment and electronic test equipment.
Thus, this document is intended to introduce ScpiStudio to the Hobbyist, Academics and ATE and Process Control industries, as I expect it will soon go “Viral at a Hobbyist, Student, or ATE Test/Design Engineer near you!".
These are the main themes of ScpiStudio:
1. Create an ATE Automation platform that would allow for the ability to be utilized by users of varied backgrounds and capabilities (for the non-programmer and programmer alike) for total industrial equipment automation.
2. Usable by the astute hobbyist, Electrical/Electronic Designer or Electronic Technician on the Bench.
3. Flexible data acquisition activity, and to be able to utilize simple and straightforward software commands to perform this activity.
4. Design allows for seamlessly taking advantage of existing intellectual property.
5. Scalable across small to medium to large data collection projects.
6. ScpiStudio performs the data acquisition, comparison to limits, and data logs the result into the SQLite data log database. This data base can be post processed for data analysis.
ScpiStudio meets all the above objectives!
What is ScpiStudio?
ScpiStudio in the aggregate consists of a Windows PC controller (desktop workstation or laptop), a SCPI Like test language, and the underlying NI’s Measurement Studio™ and Microsoft’s Visual Studio™ software to put it all together.
The ScpiStudio C# software application was developed by using Microsoft Visual Studio™ incorporation with NI’s Measurement Studio™ application, which is used to perform automatic test and/or process control in the semiconductor, electronic, bio tech and automation industries. Additionally, it will be modified in future revisions by adding motion and vision systems peripherals and processes. Also, it may one day include other support for other technical industries which have a need to perform data acquisition and control processes (such as automation and control of conveyors, material handling, and associated vision, labeling stations, and, of course, industrial internet of things).
ScpiStudio (ATE) is an extremely easy to use script (text) driven test engineering software development suite. The test program contains simple to understand test engineering and software commands that reside in database tables. How one writes the script controls the sequence of commands sent to the peripherals (test equipment, etc.).
The ScpiStudio concept was the outcrop of noticing, much to my dismay, that most Automatic Test Engineering Programs (here after known as ATE applications) and automation applications, especially those projects produced by medium to large software engineering teams, were very constrained and non-flexible in scope. It is exceedingly difficult to take advantage of existing intellectual property at the highest levels of these designs. This is generally because the designs were too customized for the problem at hand. Not much thought was given for follow on similar projects, as “time to market” was the main objective, rather than designing a platform that would suffice for years to come and make “time to market” scheduling less onerous.
This piqued my interest on how this might be accomplished. My ideas begin to form around the development of a platform which would allow engineering and software teams and users to be able to alter the behavior of an ATE or an automation system, without the need for additional complex programming development, outside of what is part and partial of the ScpiStudio test script platform interpretive program development.
Another issue, I noticed, were the various roadblocks that naturally occur in large organizations regarding the completion of hardware designs, both mechanical and electrical, as compared to the integration of the associated software. The software, invariably, was not completed by the time the other two disciplines were. This is somewhat understandable, as the hardware is typically completed long before the software is completed, due to multiple changes made to the hardware during the various design phases. There are also communication issues between the various engineering groups, which can only be address through proper system and project management (or pizza parties with lots of beer!)
Other than for bench testing, performed by each specific engineer, which only checks out their part of the overall system design, there are very few ways to system test the designs, during the design phase. One such method, for example, would be writing simulation software, which can be very costly, both in monetary and personnel resource. Simulation projects must also obtain additional software engineering resources (good luck on this one!).
I gave all these issue considerable thought and thought the best way to accomplish this task was to develop a platform, which allows for interrogation of system and/or components by utilizing a high-level text (script) language to alter the behavior of the system and produce the robust automated test engineering required to complete their project(s). Thus, the ScpiStudio script utilizes powerful commands that direct the underlying ATE test engine to interrogate, compare, and data log the test sequence activities.
Finally, I decided to give up a great job in February of 2014 and bring this project to life. Much to the chagrin of my wife! I told her, “Guess what honey, you are now the bread winner”. Thank goodness, she had a great job and was well paid by her employer.
The following is an article I posted on LinkedIn:
What the ATE industry needs is an inexpensive and comprehensive "Rapid Prototyping Tool" (RPT)
This ATE tool should be aimed squarely at the Test Engineer, as opposed to a supporting Software Engineer, as acquiring the services of the Software Engineer may be one of the "road blocks" to the Hardware/Test Engineering group in creating automatic test programs to interrogate a component, product, or system test application, hereby known as the DUT (device under test).
Generally, an automatic test program performs a sequence of measurements upon the DUT, and compares the measurements against high and lower limits guard banding around the optimum reading. The specifics of the guard banding values maybe related to what the company can tolerate economically and still be in compliance with their specifications.
All data logging of test results shall reside in a data log table in the associated database and not in files on a hard disk. Conversions of the logged data to csv, Excel™, and other formats, shall be a post-test process.
What are the requirements of the Test Engineer?
Besides all of the following requirements as defined by Wikipedia (<https://en.wikipedia.org/wiki/Test_engineer> ):
1. Early project involvement from design phase
2. Working with cross platform teams (hardware and software)
3. Yield maintenance
4. Test automation
5. Defining standard test documents
The Test Engineer needs to understand his test equipment, and this also includes the ability to take a measurement using the front panels of the instrument. Additionally, it is useful if the Test Engineer, has the ability to understand the specific commands to setup, configure, and take a measurement under remote control of the instrument via the aforementioned RPT development suite. These commands are, among others, sequential SCPI (Standard Commands for Programmable Instruments) or others, such as TSB commands. These commands, or the Test Program Scripts, shall reside in a database.
What are the requirements of the RPT development suite?
The development tool should have the ability to perform simple sequence interrogation of the test equipment as well as the ability to perform more complex activities as determined by the commands and instructions used in the test program, as this tool can be utilized by the non-programmer and programmer alike. It could be used to provide “proof of concept” or could be utilized to build a robust production worthy ATE. The RPT should have, as a minimum, the following attributes:
Test programs, which exist as ASCII text (i.e. a script), and are located in a Database Table (such as SQLite, for example) with each table name being equated with a test program name. The RPT executable simply sequences through the test program table in the database and performs the actions and measurements accordingly. The RPT has all the essential ability to utilize the interface buses (GPIB, RS232C, USB, TPC/IP) to communicate with the test equipment. These test instructions would, as a minimum, consist of the following:
1) Test Number and Test Step definitions.
2) SCPI or TSB instrument instructions.
3) Sequence through the programmed sequence on the display.
4) Data logging of test results, and other commands listed on the display. Variety for data logging control from QUIET through VERBOSE.
5) Ability to run Python scripts and capture the standard output, display the standard output to the User Interface (UI) and data log to the database accordingly.
6) Loop control counters that increment, decrement and branch (A, B, C, X,Y,Z) when at zero or other extremes when defined.
7) SHMOOH of an instrument parameter such as DVM voltage from a one limit to another, either decrementing or incrementing by a defined delta value.
8) Branching instructions such as branch to a test number (i.e. label) on Pass/Fail or branch to test number found in an accumulator defined for branching.
9) Binning commands, used either for material handlers or the display UI, to facilitate sorting the tested product.
10) Timers utilized to control programmatic delays or branching when the timer has expired.
11) Call (subroutine calls designated by a test number) with an associated return instruction.
12) Call Table (call another table (i.e. test program) and return to the original table with a RETURNTBL instruction).
13) Simple Math instructions and value retrieval using accumulator instructions (ACCADD, ACCSUM, ACCSET, ACCGET, ACCMULT, ACCDIV, ACCCMP).
14) Interface OPEN, WRITE, READ, FETCH, and others more complex bus commands for the IEEE-488 (GPIB), RS-232C, USB, and TCP/IP interfaces. An example for the GPIB bus would be GPIBOPN, GPIBWRT, GPIBREAD, GPIBFETCH among others with ability to control up to 32 peripherals inclusive).
15) Comparison instructions (comparing a measurement or measurements to a High Limits or Low Limits for each interface bus as well as comparing strings (exact or subset (i.e. like or similar)), typically used for the “*IDN?” SCPI instruction.
16) NOHW ON,OFF for simulation when hardware is not present. Measurement limits and sample counts are defined in the test program script and used during simulation.
17) Plotting commands for graphical waveform display.
18) Ability to use a copy program (such as RoboCopy) to back up the data logging database on the occurrence of a new day or on command.
19) Definition of a SHUTDOWN table which will run and reset test instrument programmed values or other parameters upon premature end of the test program due to system failure.
SNGLSTEP ON,OFF command to allow for debugging of test program sequence.
20) The RPT could also be cross platformed. One instance of the app could run as a Microsoft windows application and another could be available on the Linux or Raspberry PI platform with each conforming to the same test programming language and same database (SQLite). Obviously, the Raspberry solution, would be very inexpensive and might only be used in low performance data acquisition applications.
1. Ability to be cloned on the same test platform, or across the network on another identical platform, and shall be able to coordinate the test sequences to perform complex parallel measurements via wireless communications.
2. The RPT test engine, shall contain all the intelligence to take the measurements, compare against the limits, data log the test results, and branch accordingly, without the need to burden the test engineer with this functionality, other than sequence manipulation, as determined by the associated test script. Additionally, the RPT shall have a concise UI that displays header information, real-time test program sequencing, waveform graphs, and sequential data logs.
3. Post-test processing and data reduction shall be accomplished by SQL interrogations of the logged data in the associated data logging table.
4. The RPT shall be equitable in support of test equipment vendors, and thus would support various VISA interfaces as defined by the test equipment vendors.
5. Finally, the RPT shall be inexpensive (<$1000.00 for a single license).
This concludes my simplified wish list for an RPT, and I hope this stimulates your interest. I would be more than interested in follow-on discussions of this endeavor. I truly, believe an RPT, of this nature, would be of great value to the ATE and Automation industry.
Bottom Line: ScpiStudio meets the RPT (rapid prototyping tool) requirements!.
[1] Keysight, National Instruments, Tektronix, among others