Experimental Physics and
Industrial Control System

Dirk Zimoch <[email protected]> · Thu, 08 Nov 2012 14:59:55 +0100

On 08.11.2012 14:50, Dirk Zimoch wrote:

On 08.11.2012 05:56, Eric Norum wrote:

The convert routine is passed the parameters from the command table
entry and if it wants it can get at a pointer to the entire command
table entry so you can likely provide a single routine that will
handle lots of table entries. You might be able to get away with
having to write only a single convert routine for all the commands you
need to send.
Certainly a pain, though.

I wonder if StreamDevice would work.

Yes.

The problem is writeMsgString(gpibDpvt *pgpibDpvt,const char *str) from
devGpib/devSupportGpib.c which does not have any length parameter.

The lower level asynOctet function write() as well as all
implementations I have seen have (and use) a length parameter.
StreamDevice uses this function and passes the correct length.

Do not use devGpib for any new project!

Just in case you wonder how the StreamDevice protocol would look like:

terminator = 0x0d;
test_read {
  out 0x00 0x07 "IT0";
  in  0x00 0x07 "IT=%d";
}

This will return the number 547 in your case.

On Nov 7, 2012, at 8:49 PM, Andrew Wagner<[email protected]>
wrote:

Hey Eric,

Thanks for the advice and commiserating. I already wrote a standalone
C++ program to communicate with this thing and it took a little while
to write the functions to append and strip \x0\x7 on/off of every
string I sent/received from it. It really amazed me that they chose
to start every command with \x0 since thats what the entire rest of
the world has agreed means end of string. I was hoping to avoid
having to write my own version of AsynIPPort just to deal with the
\x0\x7 bytes.

Cheers,

Andrew

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System