Semi-standard protocol for controlling instrumentation?

[c4757p]

So, I'm currently working on a programmable load, and hope to do a power supply next, and maybe some other instrumentation (for some reason I really like designing instrumentation). It has emulated serial connectivity over USB.

I was wondering, is there some "standard" serial protocol for controlling and receiving data from it? I'd much rather use something that already exists than reinvent the wheel. (Of course, I really doubt there is a protocol out there for instrumentation that is both standard and open, where I can actually get a hold of the specs, but it's worth a try...)

[c4757p]

Hmm. Pretty sure I read about that at some point and forgot about it. Guess I should be happy I chose to use a dsPIC running at 96 MHz as the controller (gross overkill, but I wanted to play with the dsPIC, and it let me do things like constant power/resistance without some funky analog multiply/divide circuitry). Not sure I could get an interpreter for SCPI running in my usual 8 MHz, 8-bit PIC!

Honestly I'm a bit surprised that a standard for equipment like that defined in 1990 was so textual - a lot of equipment around that time still had relatively light processors that already had a lot to do. I kind of figured a binary protocol that can be interpreted with a basic lookup table, plus a set of text mnemonics to be translated on the controlling PC if a human has to operate the thing manually.

[robrenz]

I wanted to play with the dsPIC, and it let me do things like constant power/resistance without some funky analog multiply/divide circuitry).

I am very interested in this part of your project. I would like to control these bipolar operational power supplies in CW and CR also. Your project looks like it would fit the bill.

[ejeffrey]

GPIB/HBIB  have always used predominantly text based protocols since they were developed in the 60s.  That predates the PC by quite a bit, and you couldn't just ship a CD with control software... End users had to be able to use whatever hardware they had to communicate whether it was a terminal or a minicomputer.  It was also common to do data logging by connecting a GPIB printer that just printed the responses to a trigger, so the data format had to be readable on a printout.

You would be surprised how much text processing you can do with even just a few discrete logic gates. GPIB control lines help you out by signaling EOL.  SCPI is more sophisticated than the early non-standard text protocols, but still quite easy to parse.  An 8 bit MCU can easily handle it, and those were quite common and inexpensive by the time SCPI became widespread.

[c4757p]

True, ejeffrey, I didn't think about it being related to a legacy protocol that even predates the PC. Makes a lot more sense. And yeah, I know you can process the text protocol very efficiently if you're clever (there are still quite a few areas of EE that I'm still making my way into, but I am quite a good programmer), but I just kind of assumed it'd be better to make it easier on yourself and design it so you didn't have to. Forgot about the "standardized in 1990" protocol really dating back to a long time before that.

robrenz, those things look awesome. I think it'd take a bit of an overhaul of my design to control them though - it's not really meant for even just 20 kHz bandwidth. It's meant for testing power supplies and such, and really wouldn't do very well at AC. At my target bandwidth (a pathetic 500 Hz, though I think it will exceed that by a good bit when it's all complete), constant power and resistance are just a simple matter of running Ohm's Law calculations and constantly adjusting the set output current. No fancy clever math and control loop stuff to get it working at a high frequency. I just wanted the dsPIC for the hardware multiply/divide.

[robrenz]

I think it'd take a bit of an overhaul of my design to control them though - it's not really meant for even just 20 kHz bandwidth. It's meant for testing power supplies and such, and really wouldn't do very well at AC.

They work all the way to DC.  It is really just a huge bipolar op amp, It just follows the input signal. So I think whatever signal you drive your power section with could drive one of these. Even though these are called power supplies they are 4 quadrant so they can sink power just like an Eload. My CR and CW request was for when these would be used as a Eload.  They can be a CV or CC Eload directly as they stand. A FG/AWG can feed the input if loading patterns or frequencies are needed but I can't do CR or CW that way.

[c4757p]

Oh, I didn't know you wanted to use it for DC/low-frequency. Yeah, it'd probably work. I'm sure I'll post the entire project including firmware somewhere when it's done, so you can pick over the source code. (That is, if you don't mind assembly. I'm pretty good at assembly and gave up trying to get Microchip's C compiler to install on my computer  )

[mrflibble]

...  and maybe some other instrumentation (for some reason I really like designing instrumentation). It has emulated serial connectivity over USB.

I was wondering, is there some "standard" serial protocol for controlling and receiving data from it? I'd much rather use something that already exists than reinvent the wheel. (Of course, I really doubt there is a protocol out there for instrumentation that is both standard and open, where I can actually get a hold of the specs, but it's worth a try...)

I'm in pretty much the same boat. Either roll your own lame/quick/dirty command parser, or do it properly. Decisions, decisions. Since there's a few relatively simple projects in the pipeline in need of a command interface, I thought I'd try to do it the proper way this time.

Right now I'm looking at doing the protocol for controlling a DDS based signal generator and a PWM test generator for a motor control thingy.

I just grabbed this scpi parser and it looks like a decent enough starting point. Also, in case you decided to use SCPI, what did you use as a template for your command syntax?

For the DDS I think I'll just get some inspiration from the "REMOTE INTERFACE REFERENCE" section:

http://www.bkprecision.com/products/signal-generators/4086-80-mhz-programmable-dds-function-generator.html
http://www.bkprecision.com/downloads/manuals/en/408x_manual.pdf

Anyways, I was just wondering what you ended up implementing? SCPI?

[quantumvolt]

Very interesting thread. It has missed me - or maybe I missed it. I have been working with this for a long time but still have a long way to go (sometimes I think I'd better buy a GPIB board/adapter from fleabay).

Anyway - here is my modern 4Q Source Unit. I already control it in C++ from Arduino (and a new ARM M3 based DUE).

http://cds.linear.com/docs/en/demo-board-schematic/DC453B-SCH.pdf

I am going to make a DCPA-LITE ...

Here is the ultimate DC box - The N6705B DC Power Analyzer & N6784A 4-Quadrant General-Purpose Source/Measure Unit & 14585A Control and Analysis Software





PS Even if it is US made it also runs on 220 V AC. Classy machine ...

[dr.diesel]

serial connectivity over USB.

Don't forget Linux support!  Something like serial FTDI is cheap and easy.

[c4757p]

Hmm, this is an old thread! That project is long gone... In more recent things, I've just been using a "SCPI-like" protocol. No need to go through the whole standard for something relatively simple, it's not like I've built many DSOs lately! But familiarity is good.

Don't forget Linux support!

That comes first!

[dr.diesel]

ha, didn't even notice the OP date.

Old school text is hard to beat, especially for low speed stuff without screenshots.  Also makes it super easy for end users to develop their own software.

[mrflibble]

Hmm, this is an old thread! That project is long gone...

Yeah, sorry for the necropost.

In more recent things, I've just been using a "SCPI-like" protocol. No need to go through the whole standard for something relatively simple, it's not like I've built many DSOs lately! But familiarity is good.

That's the thing. I always end up doing almost-but-not-quite SCPI/GPIB. As in implement just the absolute minimum set of instructions required. And for small projects it often means I'll just do some exceedingly lame strcmp based "parsing" as opposed to a proper parser with lex+yacc or whatever the crazy kids use these days.

The two main reasons (for me at least) not to implement it according to standard would be:

• code size
• implementation cost (aka your hobby time that you never have enough of)

Relevance of code size as an argument depends a bit on what you run it on. On an stm32 with 1 Mb of flash it's not that much of an issue.

Having to actually code the handlers is most of the work. So if you can find a library/framework that already does all of the standard scpi stuff then ideally you will mostly be spending time on the actual functionality you were going to do anyway in the minimalistic case. Put another way: if done right, doing it "properly" should have little or no overhead compared to the minimalistic implementation. And the bonus is that all the goodies you accumulate over the years will have a uniform interface. That way they might even work with other people's scpi gui/scripting lab tools, as opposed to just your own stuff.

So far that scpi-parser looks promising. Even has some tcp and LwIP (on FreeRTOS) examples of an scpi server. Right now all I need is to feed it a string buffer to parse, but nice to know it also has some code for this.

The goal is to have a uniform command interface (SCPI) for future projects. And then your scripts and GUI's just have to emit these standardized commands. I use Qt on android to cobble together a pretty gui with some buttons. Bind the buttons to SCPI commands, emit over USB to serial dongle, and you're all set. Touch screen interface for your projects. Although to be fair, I end up using laptop + console far more often. But the android looks shiney. 

Anyways, I'll stop rambling thinking out loud and make me some tea.

[Harvs]

On a side note, what is the best way of implementing a text based command system on a uC (i.e. the command recognition)? 

Anyone have any good examples, links to app notes, etc?

I've always tended to say away from the standard C string functions largely because some of them can quickly gobble codespace.  However that's probably been to my detriment in some cases.