> Dear All,
> I'm using EPICS R3.13.0.beta11, MV162, VxWorks 5.2 and
> GPIB-1014 (Gpib-VME by National Instruments).
I'm sorry! But one must do what one must do.
> I'm testing a gpib device. The rules are two :
> 1) I must use only EOI true for message termination;
OK. (I think...)
> 2) All data sent to, or read from, the device must be in
> binary, not in ASCII characters.
Bummer! We've got a box that acts like that, except that it doesn't doe EOI
either.
> Now I have a sequence of numbers to execute a device command :
> 30 0 17 0 0 128
> For this test I'm using GPIBInteract, then write:
> \x1e\x0\x11\x0\x0\x80
> but the device don't execute the command (only busy led
> turn on for a second).
> Where is my mistake ?
Well, it's not really your mistake. The problem is that way down in the
bowels of the device/driver support John used some functions from the string
library. When it sees a NULL (\x0) in the string being sent it thinks it's
done and stops. The remainder of the command string goes into the bit bucket.
Our device wanted to see "\x0" as a command - it simply doesn't work.
A similar thing happens to input strings that include NULL characters.
I spent quite a bit of time trying to figure out a work-around, but never got
a solution. In our case, we were able to get the manufacturer of the device to
fix it so that he never sent (or expected) a NULL.
Unfortunately the device can't assert EOI, so we have trouble detecting
the end of the message. There's a bug (or feature, if you prefer) in the
code that swallows the last character when one depends on setting the buffer
size so that End of Message is determined by the buffer being filled. While
I found several places that needed fixing for the input to work, I never
found all of the places that needed to be fixed.
Most GPIB devices are rather more civilized and only use the ascii characters
in their message format, which is how I believe God & H.P. intended things to
work. But I could be wrong.
I _suspect_ that all of the implimentations of GPIB interfaces under EPICS will
suffer from this feature. I haven't tried it on Ben Franksens' HP2050A code,
but I'd be surprised if the device itself can deal with embedded NULLS, much
less the code. One more thing to add to my list of things to poke at!
> Thanks in advance
You're most welcome. And if you find a solution, please let the rest of us
know. Sometimes ya just gotta deal with these uncivilized devices. Sorry
I don't have a solution.
Disclaimer: Any opinions are my own and have | -bill
nothing to do with the official policy or the | [email protected]
management of L.B.N.L, who probably couldn't | Berkeley, CA
care less about employees who play with trains. | aka [email protected]
- Replies:
- Re: GPIB device test >> GPIB-ENET mauro
- Navigate by Date:
- Prev:
GPIB device test mauro
- Next:
Use of the sequencer for run permit calculations Peregrine M. McGehee
- Index:
1994
1995
1996
1997
<1998>
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
GPIB device test mauro
- Next:
Re: GPIB device test >> GPIB-ENET mauro
- Index:
1994
1995
1996
1997
<1998>
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|