Re: Problems sending \x0 with devGpib driver

[Dirk Zimoch <dirk.zimoch@psi.ch>]

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