- Posted on: 2023-04-10
Test and measurement (T&M) instruments that can be controlled over a serial communication with a computer typically use very standard command and response formats. Those are the same whether the connection is made over USB, TCP/IP, GPIB or RS232. This standard is called “Standard Commands for Programmable Instrumentation” (SCPI). The image below shows an example of commands for a multi-channel power supply:
As you can see, all those commands are human readable and the same goes for the responses from the instruments. Most of them return one or more numbers (typically comma separated) and sometimes other characters for information such as errors and the instrument’s make/model/serial number.
Do I need instrument specific code then?
Technically, you do not need instrument/vendor specific code. One can easily write those commands and parse the responses with simple code in LabVIEW (the same as in Python or any text based programming language.) However, by supplying ready made and validated functions, the existing code typically saves a lot of development and troubleshooting time for most applications.
Are those commands and APIs bus specific?
This is a really important question. Even though the same messages and responses are received in the payload regardless of the communication channel, sending a message over USB is immensely different than sending a message over RS-232. However, it would be pretty cumbersome to have to write a different version of the API for each communication bus. This is where VISA (Virtual Instrument Software Architecture) and NI-VISA drivers shine. This driver completely abstracts the hardware communication layer and transparently handles the command/response exchange for any of the supported communication bus. The code below shows how the code remains un-changed regardless of the I/O type.
Does Symplify require custom code to communicate with my power supply?
If you are developing your own application in LabVIEW, it is likely that you want to use the manufacturer’s code (VI) to save time and quickly integrate the specific functionalities that you need. However, as most developers have already experienced, the operator constantly require more features from their automated test systems and this means modifying the source code and making/testing a new build which can take quite some time.
Synovus’ goal with Symplify (and even more so with Symplify Now!) is that the developer can customize what the system does at runtime. This means having the flexibility to use any command supported by the instrument without having to make changes in the source code. As you can imagine, this is not really compatible with each “manufacturer specific” driver implementations.
Instead of using custom code, our engineers designed a simple method to map Symplify Tag values (which can be scripted, graphed, logged, etc.) to numbers sent to or received from an instrument. The objective is to offer this data exchange to the user at runtime:
This means that inside the driver, we must be able to format commands with Tag values such as:
It also means that we must extract values from the responses to store them into Tags:
To do this, we offer a table that can be populated at runtime and uses standard type specifiers as well as Regular Expressions to prepare commands and read values from the responses.
Different commands can be sent at different intervals (every 2 seconds in the example above to read the current, voltage and power from channel 1) or sent as soon as the Tag value changes (voltage setpoint). This approach covers approximately 95% of the communication needs of typical ATE applications. But what about the other specific needs of users with more complicated requirements?
It is possible for the driver to send an arbitrary command coming directly from a script or from the user interface and to pass all the data received back to that caller. The image below demonstrates the logical flow of information.
In the example above, the script could be used to program a fast transient into the power supply or possibly to set limits once before a specific test without exposing those to the operator as Tags. Those commands still need to be sent through the same SCPI driver to make sure that the command and the response are exchanged synchronously among other commands sent and received from the table configuration.
Watch it in action
There are many videos available in the video section that describe our drivers, including the standard SCPI driver found in Symplify Now! The video library can be found here: https://www.synovus.ca/symplify-video-gallery/.
There is also a specific page dedicated to the standard SCPI driver. IT can be found here: https://www.synovus.ca/generic-scpi-driver/.
Don’t hesitate to contact us if you want to know how Synovus and Symplify can help you reduce development and troubleshooting time to bring better products to market faster.