Programmable DC Electronic Loads with the BK8600 - Review

Table of contents

RoadTest: Programmable DC Electronic Loads with the BK8600

Author: shabaz

Creation date:

Evaluation Type: Independent Products

Did you receive all parts the manufacturer stated would be included in the package?: True

What other parts do you consider comparable to this product?: There are not many options! The 8600 series was attractive because it was likely to have been built based on the experience from the earlier 8500 series.

What were the biggest problems encountered?: Nothing major. LabVIEW is not as popular for some engineers, so some time was needed to build some open source software. This wasn't a problem, but did consume some time. But in the end It was rewarding to see that it was not difficult to interface to the BK8600 via USB.

Detailed Review:

Introduction

The BK Precision 8600 Electronic Load in a nutshell provides an adjustable current sinking capability when it is applied to a DC source. It also has microcontroller-based closed-loop feedback; since V=IR and P=VI it follows that by measuring voltage and current dynamically it is possible for a microcontroller to automatically adjust the amount of current sinking in order to implement modes of operation that can provide a constant resistance or constant voltage or constant power. Non-constant (varying) loads are also possible if desired. These can be useful for observing dynamic behaviour of the DC source as the load changes.

BK Precision’s 8600 series has seven models covering operation up to 30A/150W for the base 8600 model and up to 60A/1.2kW for the top-end 8616 model8616 model. For the RoadTest the model supplied was the 8600 version, order code BK8600BK8600.

 

I was interested in trying out the BK8600 Electronic Load for Internet of Things (IoT) related projects. In fact the BK8600 can be used for more than DC power supply testing. For IoT projects the load would also have uses for testing analog and digital outputs (for example for driving lamps).

 

It would also be useful for testing many energy sources that have complex behaviour that needs to be characterised. In my case, I wished to examine solar panels. This RoadTest examines several use-cases and explores how to make the most of the BK8600 through software automation.

 

How Does it Work?

The easiest way to picture a DC load is to imagine a variable resistor connected to the source equipment under test. By monitoring the voltage across the variable resistor and the current passing through it, it is possible to adjust the variable resistor to set any desired current. If the source changes, or if the source has internal resistance, then that can be compensated by changing the variable resistance until the measured voltage and current are of the desired values.

 

In an electronic DC load, the measurement and adjustment of the variable resistance are automated using a control loop. The diagram below shows an approximation of how the BK8600 can function at a high level (note – the BK8600 actually incorporates multiple processors and more advanced circuitry – this diagram is just demonstrating what end functionality is embedded inside the BK8600, not how it is implemented). The heart of the control loop can be implemented in hardware or for more flexibility as algorithms in software.

 

User Interface

The BK8600 is easy to use, I did not find myself needing to reach for the user manual too often (incidentally, the user manual is well written). There are plenty of buttons and a shift key for accessing the menu options. The vacuum fluorescent display is large, very bright and clear, and because it is alphanumeric and there is space for reasonable amounts of text, the menu options are easy to follow. I also liked the fast update rate; the readings on the screen update around three times per second (this is a visual estimation). The buttons have a beeping tone but the user can disable this sound from a menu option. The power button is unusually long, and I did accidentally power off the BK8600 when I brushed against the switch by mistake. It is minor and easy to fix; I cannot actually fault the controls or user interface too much.

 

Setting up the BK8600

The BK8600 Electronic Load comes with some very large (6mm) threaded posts for connecting up the source that is to be tested. At the rear is a connector for additional signals that are used less frequently. I decided to build up a set of cables that I could dedicate for Electronic Load test purposes.

 

For the front cables I used M6 lug terminalsM6 lug terminals and redred and black banana connectorsblack banana connectors and some 2mm2 wire (see Make your own Test Leads for more information).

 

A rear connector comes with the BK8600 and it offers screw connections for some features like external triggering, fault alert, and remote sensing to allow the BK8600 to make accurate measurements much like a 4-wire measurement with a bench multi-meter. I wired two croc clips for remote sensing purposes. I used ferrules for a reliable termination at the screw connector end.

 

The depth of the instrument is 387mm and that is quite good. The workspace in the photo below has less depth compared to desks in most labs, and there was no issue with using it. It is also extremely quiet! The fan will only kick up in speed when it needs to.

 

Controlling Test Equipment Easily

The next step was to examine automation.

 

 

Unlike some test equipment such as multi-meters and oscilloscopes that traditionally are often (although not always) used standalone, an electronic load is a device that especially benefits from automation for design engineers. This is because the design engineer is very interested in making adjustments and seeing the effect and for Electronic Load use-cases the adjustment can be complex and the effect may need processing, conversion and graphing.

 

The BK8600 electronic load offers the ability to perform adjustments in load value, and has measurement capabilities built-in. It is supplied with example software based on National Instruments LabVIEW and this is extremely popular for large testbeds especially for engineers in production environments. For a design engineer I feel that quicker and simpler control and monitoring software can be useful. LabVIEW is very full-featured but I often encounter problems when using it on PCs that already have different versions of National Instruments VISA drivers installed for controlling other test equipment and I do not want to risk breaking existing installed software for other test equipment.

 

A design engineer might not have the time or dedicated computer (or virtual machine) to build out a static testbed that will work reliably for just one test scenario without affecting other software installed on the machine. Furthermore not everyone is experienced in developing for LabVIEW because it uses a graphical oriented system for defining much of the test procedures.

 

The BK8600 has RS232 and USB connectivity options on the rear panel. I decided to use the USB connection since my laptop no longer has RS232 capability without an adapter anyway. By default the BK8600 is set up to use RS232 so the user needs to explicitly enable USB in the menu options.

 

Once the device is plugged in, a device appears in the /dev folder on the PC (I used Linux since everyone can run this for free in a virtual machine, regardless of their host operating system). From there it is easy to start interacting (using read and write functions) with the BK8600 using a communication format called SCPI (short for Standard Commands for Programmable Instruments). I used the C programming language for this. However, not everyone knows C either.

 

 

So, I decided to implement a type of gateway in C, that would allow users to send an instruction using HTTP, and the gateway would extract it from HTTP and send it to the BK8600. With few tweaks it would be adaptable for any test instrument that uses SCPI (and most do).

 

Now, anyone can send instructions to the BK8600 using a web browser; just type the desired SCPI instruction in the browser address bar (e.g. http://xx.xx.xx.xx/FETC:VOLT ) and the BK8600 will get queried correctly and the result will appear as a text string in the web browser.

 

Taking this a few steps further, it means that engineers can program test scenarios into web pages and provided they send the correct requests over HTTP, the user can automate many tasks. From my perspective, this is handy because the user can simply create a new web page (in other words a single HTML file), or copy and modify an existing one, for performing any new task or test.

 

Furthermore, I can archive off the .html files into a folder or paste into a lab notebook so that I can always rerun the test scenario. No need for configuration files or remembering settings! Every time I need to run a slightly different test, I can just clone a HTML file and save it under a new name on my PC.

 

The code is published on github; it is proof-of-concept code but works well enough that I cannot see myself not using it whenever I turn on the BK8600. The code deserves a re-write, but it is easy to see how it works and make changes. If others make use of the code then it would be interesting if users shared their HTML files for different test scenarios. We could all make use of these by picking the HTML file closest to the desired test scenario and then modifying it.

 

From a software implementation point of view the code merely checks to see if the HTTP request looks recognisable as a SCPI command and passes it onto the BK8600. If the HTTP request looks more like a filename then the code will query the file system and serve up the requested web page. To execute a full test procedure the web page file just needs to contain JavaScript code to issue more SCPI commands as desired to implement the procedure. Any graphics and charts can be implemented in the web page too.

 

The code performs some minimal modifications to the incoming request in order to simplify SCPI command requests, and implements a few special local instructions too. As an example of a special request, a HTTP request containing ‘open_usb’ will prepare the software interface to become ready to accept SCPI commands. Another special request called ‘start_log’ is used to instruct the server to record measurements to timestamped files.

 

As an example, I wrote a HTML file called logger.html. When this web page is accessed, the user gets a live status of the current measurements from the BK8600 and live scrolling graph of current, voltage and power, and logging to the server.

 

It won’t replace an oscilloscope for observing rapid changes, but it is useful for logging things over a very long time and observing trends over long time periods. The code currently shows a graph of the past five minutes (logged every second) but it would be easy to rename a copy of the file to (say) long_logger.html and edit the file to any desired settings.

 

Working with Supercapacitors

Once I had the basic logging function working I discovered that one of the very flexible things about the BK8600 was that it was easy to capture data to a log file while continuing to manually operate the BK8600. As a result, I could concentrate on the test and be reassured that data would continue to be logged all the while.

 

 

I used this procedure to test out some supercapacitors. I had a 350F supercap rated to 2.7V. Firstly I carefully charged it using a power supply and resistor, until the voltage across the capacitor was 2.6V (this needs to be accurately monitored!), and then I disconnected it and attached it to the BK8600.

 

Next, I used the logger.html file to start a capture (just clicking on the ‘Start Logging’ button) and the scrolling voltage plot showed the voltage across the capacitor to be 2.6V. Current and Power graphs were at zero because no load had been enabled on the BK8600 yet.

 

It was easy to configure it to act as a 0.3 ohm load; just hit the CR button (for constant resistance) on the BK8600, then type in 0.3 followed by Enter, then then press the On/Off button to enable the load. Immediately I could see in the scrolling graphs the voltage gradually dropping as the capacitor discharged, and the current and power graphs updated in real time too.

With a little bit of effort it would be possible to compute the area under the curve and display the energy that was inside the capacitor. I might implement that later in a fourth graph, and have a box for typing the resistance value and have a ‘Go’ button, and call the test procedure capacitor_logger.html for example.

 

Working with Solar Cells and MPPT

Maximum Power Point Tracking (MPPT) is something particularly useful with devices like solar cells and panels. The amount of power generated by these devices varies dependent on the amount of solar energy hitting the panel but it is also dependent on the specific load attached to it. If the load is heavy (i.e. low applied resistance) then the solar cell behaves like a constant current source and since P=I2R this means that the desire is to increase the applied resistance up until the point that the solar cell no longer behaves in this manner. At that point, since the current has remained constant, the power delivered to the load (resistance) will be at its maximum. At very light loads (very high resistance) the solar cell is no longer functioning as a constant current source and the power delivered to the load will not be at its peak.

 

Note that the maximum power point could vary dependent on temperature and amount of light hitting the cell.

 

There are different ways of implementing MPPT, some more accurate than others. The aim of using the BK8600 with solar panels was in order to characterise the panels, so that a decision could be made not only how to implement MPPT and how precise the MPPT method would need to be, but to also make a decision if the solar cells were any good and would generate sufficient power for the end application. These are important decisions to maximise the operation time for outdoor devices and so the BK8600 could really help here.

 

The test procedure is straightforward in theory; a load is applied and then the voltage across the cell and the current through it need to be measured to calculate the power being supplied to the load, and this test needs to be repeated at different load settings and different illumination levels.

 

 

The test procedure was implemented in a file called solar.html and it was run with a small solar panel (BP Solar polycrystalline panel, model MSX-01FMSX-01F shown in the photo above) as the device-under-test. It is a compact panel about the size of a CDROM case. The stars aligned in the UK (at least, the sun did : ) and it was possible to run a decent test in outdoor conditions.

 

It was a nice sunny day and the tests were run mid-afternoon. With the software it was dead easy. Just set the min/max voltage range in the web page and click the ‘Start Test’ button. The graph is drawn in real-time as the test runs.

 

The orange trace shows the power supplied to the load with the panel fully exposed to UK sunshine and the panel’s constant current behaviour can be seen from the near-straight line up to close to where the maximum power point is reached. At that point, 1.26W of power was possible when the applied load dropped the panel voltage to around 7.8V (open-circuit voltage was around 10V). This matches the data sheet closely to within a few hundred millivolts, and it can be concluded that the solar panel is very healthy; it is generating slightly more than the typical power expected from the data sheet figure. Armed with this knowledge, it is possible to design a circuit that makes good use of the energy collected by this solar panel in similar conditions. For a more fuller characterisation the test should be repeated at different temperatures and different light levels to check what difference it makes. Just out of interest, I also placed the panel indoors close to a window that was not directly facing the sun. The power output was (as expected) far lower.

 

The orange trace shows that the maximum power output was reached at about 5V. The red and purple traces are with the panel partially covered with a small scrap of paper. What I loved was that here I was observing two orders of magnitude less power (single-digit milliwatts) and the BK8600 provided decent resolution. I only graphed about a dozen points in my test procedure because this was sufficient to find the maximum power point with reasonable accuracy. The BK8600 measurements are in two modes, a high-res and low-res mode. If it is known that the current to be measured will be less than 3A then it is possible to go into a high-res mode where the resolution is 10uA. As a result, the BK8600 is quite good for milliwatt-level measurements as shown in the traces above. Lower than this is possible but at these extremes it would be advisable to use additional tools for logging the current to increase accuracy at very low levels. An example would be a multimeter which can measure and log current through a USB or Bluetooth connection such as the Keysight U1282A. A multimeter will of course be a lot more flexible and allow setting of one of many current ranges to get the best measurement to suit the desired task at hand.

The BK8600 can have around +-1.5mA offset in the set current, and the read current value, so it is not intended for all scenarios; a different type of product should be used in these cases such as a Source Measure Unit with load capability. Sometimes it is possible to construct a small load too, e.g. see this 3-in-1 source-sink-reference project which contains a 50uA current sink.

 

I also had another polycrystalline solar panel at hand, a slightly smaller Multicomp solar panelMulticomp solar panel rated for 0.8W power output. I subjected that to the outdoor sun too.

 

With this panel, I achieved 0.9W at about 3.5V panel voltage (the datasheet specified 0.8W at 3.85V so again this panel was very healthy). It is a great panel at very low cost, but sadly it is only available until stock is exhausted : ( I need to search for more panels to test!

 

In summary the BK8600 performed extremely well for the solar panel tests and I’m confident it is the right tool for this. The software worked very well for this use-case too.

 

Working with LEDs

In the world of IoT there is lots of interest in home automation. A very common need is LED lighting automation in the home as an example.

 

The BK8600 is advertised to be able to simulate non-linear devices like LEDs. As a result it is possible to use the BK8600 to test LED driver circuits. However, I was curious to see if it was also possible to use the BK8600 to test LEDs themselves. Basically it uses the electronic load, in conjunction with a basic power supply, and turns the two items into a more advanced power supply, suitable for driving an LED.

Here is how it works:

 

It relies on the fact that whatever current is flowing through the load must be equal to the current flowing through the LEDs. Therefore if the LEDs require 700mA drive current (this is one of the popular values for LEDs intended for room lighting) then the Electronic Load merely needs to be set to 700mA and the LEDs will operate. The DC power supply needs to be set to a voltage higher than the sum of the forward voltages of all the LEDs in the string of course.

 

This is extremely useful to characterize LEDs. Usually LED datasheets describe the forward voltage only at a specific current setting. By reading off the voltage on the BK8600 display, one can subtract this value from the DC supply voltage and determine the LED forward voltage at any given current value. I’m tempted to produce a led.html file for plotting exactly this.

 

Another use of the BK8600 is for the user to test out brightness levels at different drive currents. It is also possible to implement PWM to see its effect by programming the DC load to toggle between two currents. This feature is normally used to test DC power supplies for their behaviour under the dynamic load condition created by the PWM. Invoking PWM is easy to do from the front panel, by selecting the ‘Transition’ mode and selecting two currents (such as 700mA and 0mA) and then programming a frequency and duty cycle. Slightly non-intuitive, the user then needs to invoke a trigger action (such as pressing the ‘Trig’ key) before switching the output on. Anyway, the procedure works and it is possible to test out LEDs for lighting purposes. I used a Vishay 9-LED moduleVishay 9-LED module for the tests; according to the datasheet this had a forward voltage of between 27-36V so I used a 48V power supply. It worked great! If I had a minor feature request to BK Precision, it would be to modify the software to offer a dynamically adjusted duty cycle on the fly, if the user tries to modify the value in the configuration while the output is on.

By using the Electronic Load with the Vishay LED module, I was able to determine what PWM levels I would use to implement discrete dimming levels.

 

Another interesting thing that was noticed was that around 100uA of current flows through the load even when the load has its soft-key set to the ‘off state’ or even when the BK8600 is switched off. I don’t know if this is a bug or issue with my particular model, but it is technically within spec if the load is set to 0mA. I will check with BK Precision to confirm if this is expected behaviour in the off state too (I don’t think it is), and the recommended procedure to remove the DC supply to ensure no unexpected brief current sinking at times of switch-off. It may be a minor fault, but there is a three-year warranty which is a very positive thing.

 

Summary

There are an astonishing number of use-cases for a DC Electronic Load, and I am happy to see that the BK8600 provides a lot of flexibility for users to create their own test procedures and logging tools. The programming manual is extremely valuable and it allows users to get a lot out of the product. I hope people share their procedures for a variety of tasks.

 

I liked the super-easy-to-use menu system which was reasonably intuitive, and the quite good interfacing options. Ethernet would be nice, but I am happy that USB is available.

 

 

It is a very feature-rich product, and I plan to explore the BK8600 more, in particular additional dynamic tests including the ability to adjust rise and fall times and the ability to control the load using signals wired to the rear connector. Overall I’m very happy that the DC Electronic Load worked well for the scenarios that were tried (logging, discharge tests, solar panel MPPT tests and LED tests). I really hope others can make use of the software framework and the initial few HTML based procedures and build on them so that we all benefit from any improvements that we make. The code will be published on github in the next day or two and the link will be recorded here.

 

I also intend to try some more solar panels once summer arrives.

 

As with any complex product there are a couple of outstanding queries which I’ll address to BK Precision regarding the low current (100uA) observed in off state, guidelines on power-off procedure and a feature request (ability to perform PWM duty rate adjustment on-the-fly) and I’ll document the answers here when I get them.

 

The BK8600 is easy to use, provides deep insight into all sorts of circuits and devices and that means it will get used a lot in any lab.

Anonymous

Top Comments

  • From the BK 8500 manual page 46:

    DTR and RTS signal lines must be enabled/asserted.

    and https://www.tldp.org/HOWTO/Modem-HOWTO-7.html#ss7.2

    made me check for crtscts using:

    # stty -F /dev/ttyUSB0 -a | grep crtscts
    -parenb -parodd -cmspar cs8 hupcl -cstopb cread clocal -crtscts
    

    Not having hardware flow control enabled seems my first dependency not met, let me fix that with a:

    # stty -F /dev/ttyUSB0 crtscts

    However only starting the screen command with or without -f(a) will immediately disable hardware flow control again. My next guess is that I will need a terminal emulator application like minicom.

     

    Finally I got the light. The issue here might be simpler: the BK Precision 8500 series doesn't understand SCPI commands (I misread the 8800 as 8500 in the SCPI programming manual). On the other hand there is an IT8500+ Programming Guide, where Revision 1, is published on May 4th, 2018 and there is another IT8500 SCPI manual  that dates back to 2010.

     

    Luckily BK Precision published a python library for the BK8500 series and mattvenn modified that python library for the IT8512 and Linux.

  • Hi Max,

     

    If you're using just shell commands like echo, then you'll need to do something like cat a file to see the output, since it won't appear as a response on stdout etc..

    See here for details:

    https://unix.stackexchange.com/questions/117037/how-to-send-data-to-a-serial-port-and-see-any-answer

    Also, the echo command will need carriage return and/or newline, and possibly in a certain combination, because some implementations are not designed to handle all the combinations.

    To see how to do that, see here: https://ubuntuforums.org/showthread.php?t=1163937

  • Change the serial to USB converter. Now it is Prolific pl2303.

    It turns out I should configure the baud rate and parity using stty -F /dev/ttyUSB0 -cstopb cs8 -parenb 38400, then I think I should open a screen -f /dev/ttyUSB0 and finally do something like echo 'SYSTem:VERSion?' > /dev/ttyUSB0 and have matching RS-232 baudrate configured at the a-load.

    When this is currect, something is broken in the e-load, because no characters are ever returned...

  • Hi Max,

     

    Do you mean your load only has a serial (RS232) connector and you're using some FTDI adapter?

    I don't think the code will work with an FTDI adapter. The reason is, a true USBTMC instrument doesn't use USB UART as I understand. I think USB TMC is a different protocol. I'm not an expert on this.

    If it is a different protocol, then the python USBTMC library can't work (at least not without changes or configuration) with a serial device that is connected via a FTDI USB-UART.

    If your test instrument only has RS232 and therefore the FTDI adapter has to be used, then some code changes will be needed to use USB UART instead of USB TMC.

    You can probably use PyVISA, because it allows for serial (RS232, and therefore USB UART too) devices to be connected. My code doesn't use PyVISA because I had issues with it (I can't recall what the issues were). But I was testing with USBTMC, and maybe you won't have any issues with RS232/USB UART if you use PyVISA.

  • Hi shabaz, the Itech goes to short circuit (near 0 volts) in CW mode with a solar panel attached. I am still struggling with python-usbtmc to get the FTDI connected eload recognized.

  • test message, please ignore (just checking a website bug).

     

    test line 1
    test line 2
    boo!!
    boobooboo

     

     

     

    ^^ Weird.. the text is invisible when editing it.

  • Hi Max,

     

    It's easy finding the MPP with the BK8600, but it isn't automatic, it will require computer control to set different load levels. The BK8600 has no built-in algorithm to test across a range and automatically stop or display the maximum.  There is some battery test algorithm as I understand, but really the electronic load should be paired with a computer for such tests too.

     

    In the example for the review above, I used the constant voltage mode, i.e. the code tried a range of voltages and measured the power - the graph then shows the MPP. It's very quick though, especially if you know the approximate location of the MPP, then you don't need to test across a large voltage range. As you say, it would need to be done at different illumination levels, depending on how accurately you wish to track it. I think all 1000 panels should behave the same, if they are all of the same type - but I'm not very knowledgeable in this area.

    The reason for selecting constant voltage was just that it allows me to plot a graph with voltage on one axis, and that's useful because it is likely that any end MPPT circuit implementation will be measuring the voltage anyway.

     

    Regarding the code, it should run on any machine running Linux, e.g. a Pi. However I tested on x86. It uses the Python usbtmc library (not the pyvisa library, because that gave me problems with these test instruments).

  • Hi Shabaz,

     

    I'd like to do solar panel matching by mpp current for 1000+ panels. That means finding solar panel MPP using an (Itech 8512+) electronic load (the 8512+ looks similar to the BK8600), and on a 2nd SCPI device read reference PV sensor voltage to determine illumination, thus in the end to calculate Impp at a fixed illumination.

     

    I am going to try your code. What is your development environment? F.e. Python version? And in case it matters on which OS?

     

    PS Have you ever tried to connect a solar panel in CW mode? Is the BK8600 then able to find MPP on its own?

  • If you ‘d be Ok with a socket scpi gateway instead of http, I wrote one in c++ for a project here on element14. basic but working. tested on single board linux machines (a BB and a RPi) .

    SCPI on a Linux Board - Part 4b: TCP/IP SCPI and Instrument Service 100% Working.

     

    I never tested it on another OS though.

  • Hi Max,

     

    Good question - I actually re-wrote it recently in Python instead, for a different review. The C code was a bit of a mess, so with that benefit of hindsight the Python code is a lot better. I split the functionality into two separate pieces of code - a web server, and a SCPI gateway. I've attached the gateway code to this blog post, it is a zip file containing a program called usbtmc_talk.py.

     

    To use it, just type:

     

    ./usbtmc.py help

    This is the help output:

     

    Instrument Control Tool version 1.0
    
    
    Usage:
      ./usbtmc_talk.py <command> [value] [<command> [value]]...
    
    
    Parameters:
      <list_all>  - list all attached USB instruments
      <search> vendorname productname  - search for an instrument
      <identifier> val:val  - set the vendor and product ID for comms
      <vendorid> int_value  - set a vendor ID for comms
      <productid> int_value  - set a product ID for comms
      <inst> name  - sets a friendly name device for comms
      <format> format_string  - set up a conversion format
      <ask> string  - performs instruction and gets response from the instrument
      <write> string  - sends an instruction to the instrument
      <sleep>  - half a second delay
    
    
    Examples:
      ./usbtmc_talk.py list_all
      ./usbtmc_talk.py search "B&K Precision" 8600
      ./usbtmc_talk.py search "B&K" 8600 ask *IDN?
      ./usbtmc_talk.py inst bk8600 write "SYST:REM"
      ./usbtmc_talk.py identifier ffff:8800 ask "*IDN?"
      ./usbtmc_talk.py search "B&K" "8600" ask "SYST:ERR?"
      ./usbtmc_talk.py inst bk8600 ask "*IDN?"
      ./usbtmc_talk.py inst ba6010 format ",m1" ask ":FETC?"
    
    
    Formats:
      First character is the character for splitting the string
      All subsequent characters are the conversion per item where:
        1 = multiply by 1
        m = convert to thousands (i.e. multiply by 1000)
        u = convert to millionths (i.e. multiply by 1M
    
    
      Format example:
        ... format ",m1" ask ":FETC?"
          Above will split at comma and multiply first value by 1000
    
    
    Notes:
      Parameters are case-sensitive.
      Ideally use speech-marks for parameters.

    The code can be executed in different ways - either directly from the command line, or from a script, or another Python program, or a web server. It uses the USB connection to attach to the instrument. It should work with any instrument, but it has the identifiers for the BK8600 already configured, so you can directly talk to that without issuing the 'search' parameter.

    The code may have bugs - it has only had limited basic testing, but it worked fine for me, to configure the BK8600 load to specific settings, and switch the load on and off, and read measurements.

     

    Here's an example command:

    ./usbtmc_talk.py inst bk8600 ask ":FETCH:VOLTAGE?"

     

    You can also specify format modifiers to make the output human-readable (see the help output for that).