Reverse Engineering Communication Protocols (Part 3: True Usability)

To summarize where we left off, we have the control scheme for the device, a control algorithm that can easily be implemented across devices, and a interface to control those devices (part one). However, we’re still lacking an electronic load definition, and a way to use csv files to controls those devices.

The electronic load was a bit trickier in some ways, and much easier in others. The only load I had usable was an Array 3721A, so that was the device I worked with. The first job was to grab any files available, which I’ll say isn’t much. It took some time, and some finagling.¬†Array provided a LabView set of files which isn’t really a program. From my guess of using it, it must be some kind of scripting program from within LabView. I had never used LabView, so thankfully it wasn’t to difficult to figure out which file to open, and how to compile the program to run it. Once I did, rinse and repeat previous steps. Array also provided a programming manual, and the functions were all defined in SCPI, something I was completely unfamiliar with.

After observing the commands and reading about it online, it took a while to figure out. For instance, the wiki page showed ‘MEASure:CURRent:AC?’, which I tried sending as a string, but to no avail. The manual gave a command ‘CURR:LOW 1’, which I also tried, but to no avail. I did finally figure it out, and it turns out, the command looks like, ‘MEAS:CURR:AC?\r\n’, or ‘CURR:LOW 1’\r\n’. My first algorithmic implementation was a simple com port, but problematically, I was getting timeouts when trying to perform two different tasks simultaneously within the greater scope of the program. Luckily I found a python library called pyvisa, that implements a common usage for SCPI devices, able to both send and receive commands with a simple function. I would recommend this route as the library is a fool proof way that will help you to avoid the timeout errors I was getting. Another benefit is the library allows to probe all com ports with a query for the Identification for each device. Thus allowing for a device specific definition in a class, and well as auto finding on the bus.

The last step was to create a loop for a automatic run, reading the settings from file implementing a ‘wait this long, then do this’ structure that I assume would work for most customers. I used the threading library in python to start the keyboard input so I can grab from the keyboard while in a loop, while at the same time run a loop reading and writing files. It needed to read the time to wait from the autorun csv and wait that long until the next fileline read, while at the same time writing the measured voltage and current, and logging that to a csv file.

This concludes this series, I hope you have learned something. Thanks for reading.

Leave a Reply