Experimental Physics and
Industrial Control System

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

On 08.11.2012 16:17, Nicholas P. DiMonte wrote:

On 11/8/2012 7:50 AM, Dirk Zimoch wrote:

Do not use devGpib for any new project!

I find that devGpib with the GPIBCVTIO function has be able to solve
erratic communication problems that streams has been unable to deal
with. Case in point is with a Kalmus IF-488 device were the error
message would be inserted at any point in the reply (readback) string.
Using Streams I could not devise a return string argument that would
capture all the possible error messages embedded in a normal reply
string. But , using the GPIBCVTIO function I was able to write a single
function that parsed out all possible error messages from any command
and flag it appropriately.

Can you give me examples of "good" replies and "error message spoiled"

replies? Maybe I can find a solution.

Currently I'm in the middle of writing a Streams support for a LM-500
Cryogenic Liquid Level Monitor but have discovered that this device will
get out of sync with it reply messages, that is part of a reply is in
one string while the other half is in another reply string. I'm
seriously considering starting over to use the GPIBCVTIO function to
clean this up.

I like Streams for the ease of creating a quick device support but have
found it difficult for devices that do not have a robust command
interface. This could be the lack of ingenuity on my part to create a
complex reply argument in Streams which devGpib seems to overcome this
short coming of mine.

And devGpib has no problem with this? Any examples of "bad" command

interfaces are welcome.

So, for me, devGpib will always be considered on new projects.
Nick

Dirk

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System