Menu
▾
▴
linux-gpib-general — linux-gpib package mailing list
You can subscribe to this list here.
| 2002 |
Jan
(2) |
Feb
(2) |
Mar
(22) |
Apr
(24) |
May
(7) |
Jun
(44) |
Jul
(16) |
Aug
(2) |
Sep
(13) |
Oct
(11) |
Nov
(19) |
Dec
(25) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(16) |
Feb
(27) |
Mar
(5) |
Apr
(20) |
May
(17) |
Jun
(34) |
Jul
(29) |
Aug
(22) |
Sep
(25) |
Oct
(11) |
Nov
(13) |
Dec
(18) |
| 2004 |
Jan
(25) |
Feb
(22) |
Mar
(33) |
Apr
(15) |
May
(37) |
Jun
(15) |
Jul
(12) |
Aug
(22) |
Sep
(18) |
Oct
(45) |
Nov
(19) |
Dec
(30) |
| 2005 |
Jan
(31) |
Feb
(35) |
Mar
(27) |
Apr
(22) |
May
(9) |
Jun
(13) |
Jul
(13) |
Aug
(9) |
Sep
(25) |
Oct
(25) |
Nov
(12) |
Dec
(20) |
| 2006 |
Jan
(14) |
Feb
(16) |
Mar
(17) |
Apr
(8) |
May
(7) |
Jun
(20) |
Jul
(21) |
Aug
(12) |
Sep
(19) |
Oct
(6) |
Nov
(23) |
Dec
(15) |
| 2007 |
Jan
(13) |
Feb
(14) |
Mar
(24) |
Apr
(21) |
May
(9) |
Jun
(5) |
Jul
(7) |
Aug
(9) |
Sep
(21) |
Oct
(5) |
Nov
(30) |
Dec
(9) |
| 2008 |
Jan
(15) |
Feb
(18) |
Mar
(4) |
Apr
(11) |
May
(3) |
Jun
(14) |
Jul
(12) |
Aug
(1) |
Sep
(31) |
Oct
(10) |
Nov
(9) |
Dec
(2) |
| 2009 |
Jan
(9) |
Feb
(6) |
Mar
(9) |
Apr
(2) |
May
(7) |
Jun
(22) |
Jul
(5) |
Aug
(1) |
Sep
(26) |
Oct
(13) |
Nov
(2) |
Dec
(10) |
| 2010 |
Jan
(29) |
Feb
(2) |
Mar
(23) |
Apr
(9) |
May
(7) |
Jun
(8) |
Jul
(4) |
Aug
(4) |
Sep
(1) |
Oct
(3) |
Nov
(2) |
Dec
(9) |
| 2011 |
Jan
(1) |
Feb
|
Mar
|
Apr
(25) |
May
(2) |
Jun
(19) |
Jul
(6) |
Aug
(4) |
Sep
(9) |
Oct
(3) |
Nov
(8) |
Dec
(7) |
| 2012 |
Jan
(5) |
Feb
(10) |
Mar
(10) |
Apr
(1) |
May
(2) |
Jun
|
Jul
|
Aug
(4) |
Sep
(1) |
Oct
|
Nov
(18) |
Dec
(10) |
| 2013 |
Jan
(1) |
Feb
(2) |
Mar
|
Apr
(1) |
May
(4) |
Jun
|
Jul
(26) |
Aug
(13) |
Sep
(24) |
Oct
(2) |
Nov
(1) |
Dec
(4) |
| 2014 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
(1) |
Aug
(2) |
Sep
(6) |
Oct
(1) |
Nov
|
Dec
(5) |
| 2015 |
Jan
(1) |
Feb
(8) |
Mar
(7) |
Apr
(30) |
May
(3) |
Jun
(4) |
Jul
|
Aug
(7) |
Sep
(6) |
Oct
(13) |
Nov
(9) |
Dec
(2) |
| 2016 |
Jan
|
Feb
(7) |
Mar
(11) |
Apr
(6) |
May
(2) |
Jun
(16) |
Jul
(2) |
Aug
(6) |
Sep
(2) |
Oct
(2) |
Nov
(2) |
Dec
(7) |
| 2017 |
Jan
(9) |
Feb
(25) |
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
(5) |
Aug
(14) |
Sep
(23) |
Oct
(3) |
Nov
|
Dec
(4) |
| 2018 |
Jan
|
Feb
|
Mar
(6) |
Apr
(4) |
May
(11) |
Jun
(2) |
Jul
|
Aug
|
Sep
(2) |
Oct
(3) |
Nov
(20) |
Dec
(10) |
| 2019 |
Jan
(4) |
Feb
(2) |
Mar
(9) |
Apr
(7) |
May
(2) |
Jun
(14) |
Jul
(17) |
Aug
(8) |
Sep
(9) |
Oct
(2) |
Nov
(2) |
Dec
(5) |
| 2020 |
Jan
(5) |
Feb
(13) |
Mar
|
Apr
(6) |
May
|
Jun
(7) |
Jul
(1) |
Aug
(3) |
Sep
|
Oct
|
Nov
(11) |
Dec
(4) |
| 2021 |
Jan
|
Feb
(3) |
Mar
(2) |
Apr
(4) |
May
(7) |
Jun
|
Jul
|
Aug
(4) |
Sep
|
Oct
(8) |
Nov
|
Dec
(3) |
| 2022 |
Jan
(5) |
Feb
(13) |
Mar
|
Apr
(3) |
May
(4) |
Jun
(4) |
Jul
|
Aug
(10) |
Sep
|
Oct
(1) |
Nov
(4) |
Dec
(4) |
| 2023 |
Jan
(10) |
Feb
(5) |
Mar
|
Apr
|
May
(5) |
Jun
(4) |
Jul
(6) |
Aug
(4) |
Sep
(28) |
Oct
(8) |
Nov
(2) |
Dec
(1) |
| 2024 |
Jan
|
Feb
(1) |
Mar
(2) |
Apr
|
May
(3) |
Jun
(1) |
Jul
(10) |
Aug
(6) |
Sep
(3) |
Oct
|
Nov
(9) |
Dec
|
| 2025 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: dave p. <dpe...@gm...> - 2023-09-30 07:50:42
|
Hi Jim, I got it the wrong way round. The agilent_82357 only supports 8 bit compares. To reproduce the IBEOS message I had to configure "set-bin = no" and "set-reos = yes" in gpib.conf -Dave On Fri, 29 Sept 2023 at 10:58, dave penkler <dpe...@gm...> wrote: > Thanks - all the runs look good except of course the R&S NRVD. > @Jim - the IBEOS ioctl failed could be due to a set-bin=1 option for the > board in your gpib.conf file. > The agilent_82357 does not support 8 bit compares. > What is the general opinion as to whether the ATN workaround should be > pushed to the SVN ? > -Dave > > On Fri, 29 Sept 2023 at 02:58, Jim Houston <ji...@ov...> wrote: > >> Hi Dave,Everyone >> >> I ran the onebyte2 test against both the SVN kernel and the patched kernel >> the output follows. I'm getting failures on IBEOS ioctl. I'm still >> looking at >> this and I may send another email if I figure it out. I did a fresh >> install and >> I may have broken something in the process. >> >> JIm Houston >> >> Test with current SVN kernel: >> >> jhouston@gpib-test2:~/onebyte$ ./onebyte2 -d 22 s >> 0x0168 ibwrt >> + 0x0138 ibrd dev >> libgpib: IBEOS ioctl failed >> 0 0x0130 ibrd board >> libgpib: IBEOS ioctl failed >> 0 0x0130 ibrd board >> libgpib: IBEOS ioctl failed >> . 0x013c ibrd board >> libgpib: IBEOS ioctl failed >> 0 0x0130 ibrd board >> libgpib: IBEOS ioctl failed >> 0 0x0130 ibrd board >> libgpib: IBEOS ioctl failed >> 0 0x0130 ibrd board >> libgpib: IBEOS ioctl failed >> 9 0x0130 ibrd board >> libgpib: IBEOS ioctl failed >> E 0x01a4 ibrd board >> libgpib: IBEOS ioctl failed >> - 0x0134 ibrd board >> libgpib: IBEOS ioctl failed >> 3 0x0138 ibrd board >> libgpib: IBEOS ioctl failed >> 0x0124 ibrd board >> libgpib: IBEOS ioctl failed >> >> 0x2128 ibrd board >> jhouston@gpib-test2:~/onebyte$ >> >> With patched kernel: >> >> jhouston@gpib-test2:~/onebyte$ ./onebyte2 -d 22 s >> 0x0128 ibwrt >> 0 0x0174 ibrd dev >> libgpib: IBEOS ioctl failed >> . 0x0174 ibrd board >> libgpib: IBEOS ioctl failed >> 0 0x0174 ibrd board >> libgpib: IBEOS ioctl failed >> 0 0x0174 ibrd board >> libgpib: IBEOS ioctl failed >> 0 0x0174 ibrd board >> libgpib: IBEOS ioctl failed >> 7 0x0174 ibrd board >> libgpib: IBEOS ioctl failed >> E 0x0174 ibrd board >> libgpib: IBEOS ioctl failed >> - 0x0174 ibrd board >> libgpib: IBEOS ioctl failed >> 3 0x0174 ibrd board >> libgpib: IBEOS ioctl failed >> 0x0174 ibrd board >> libgpib: IBEOS ioctl failed >> >> 0x2174 ibrd board >> jhouston@gpib-test2:~/onebyte$ >> >> >> On 9/28/23 13:13, dave penkler wrote: >> >> Hi Jim, >> Please find attached a new version of onebyte to check that board level >> reads work after setting ATN at the end of the read. >> The attached patch for the driver is against the current SVN and sets ATN >> at the end of the read as you proposed. >> @MichaelK you might try this one on the R&S power meter. >> It worked on my Beiming clone: >> In the ibsta 0x174 = CMPL | REM | CIC | ATN | LACS we see the ATN bit >> set. >> $ onebyte2 -d8 >> 0x0168 ibwrt >> H 0x0174 ibrd dev >> E 0x0174 ibrd board >> W 0x0174 ibrd board >> L 0x0174 ibrd board >> E 0x0174 ibrd board >> T 0x0174 ibrd board >> T 0x0174 ibrd board >> - 0x0174 ibrd board >> P 0x0174 ibrd board >> A 0x0174 ibrd board >> C 0x0174 ibrd board >> K 0x0174 ibrd board >> A 0x0174 ibrd board >> R 0x0174 ibrd board >> D 0x0174 ibrd board >> , 0x0174 ibrd board >> E 0x0174 ibrd board >> 3 0x0174 ibrd board >> 6 0x0174 ibrd board >> 3 0x0174 ibrd board >> 1 0x0174 ibrd board >> A 0x0174 ibrd board >> , 0x0174 ibrd board >> 0 0x0174 ibrd board >> , 0x0174 ibrd board >> 2 0x0174 ibrd board >> . 0x0174 ibrd board >> 1 0x0174 ibrd board >> - 0x0174 ibrd board >> 5 0x0174 ibrd board >> . 0x0174 ibrd board >> 0 0x0174 ibrd board >> - 0x0174 ibrd board >> 1 0x0174 ibrd board >> . 0x0174 ibrd board >> 0 0x0174 ibrd board >> >> 0x2174 ibrd board >> Cheers, >> -Dave >> >> >> On Thu, 28 Sept 2023 at 17:59, dave penkler <dpe...@gm...> wrote: >> >>> Hi Jim, >>> Can you please let us know if the removal of TCS in the SVN works for >>> your reading of the calibration data. >>> I have thought some more about your proposal to set ATN at the end of >>> the read. We just need to verify that board level reads after the first >>> device level read still work with the ATN workaround. >>> If it does that would give us a reliable board level ibsta, From the >>> logic analyser traces it looks like the board gives valid ADSR responses >>> when it is in the Talker Active state i.e. after ibwrt. >>> -Dave >>> >> >> |
|
From: Jim H. <ji...@ov...> - 2023-09-29 12:46:23
|
Hi Dave, Thanks again for all of your efforts in debugging this problem. I have enjoyed working with you. I like setting ATN from the end of the read function. I think this works well for the normal case where we send a query and get a reply. I would avoid duplicating code and call the agilent_82357_take_control function. I see a balance between the chance that setting ATN might break something against knowing that having a correct ibsta() value will fix something. Jim Houston On 9/29/23 04:58, dave penkler wrote: > Thanks - all the runs look good except of course the R&S NRVD. > @Jim - the IBEOS ioctl failed could be due to a set-bin=1 option for > the board in your gpib.conf file. > The agilent_82357 does not support 8 bit compares. > What is the general opinion as to whether the ATN workaround should be > pushed to the SVN ? > -Dave > |
|
From: dave p. <dpe...@gm...> - 2023-09-29 09:00:40
|
Thanks - all the runs look good except of course the R&S NRVD.
@Jim - the IBEOS ioctl failed could be due to a set-bin=1 option for the
board in your gpib.conf file.
The agilent_82357 does not support 8 bit compares.
What is the general opinion as to whether the ATN workaround should be
pushed to the SVN ?
-Dave
On Fri, 29 Sept 2023 at 02:58, Jim Houston <ji...@ov...> wrote:
> Hi Dave,Everyone
>
> I ran the onebyte2 test against both the SVN kernel and the patched kernel
> the output follows. I'm getting failures on IBEOS ioctl. I'm still
> looking at
> this and I may send another email if I figure it out. I did a fresh
> install and
> I may have broken something in the process.
>
> JIm Houston
>
> Test with current SVN kernel:
>
> jhouston@gpib-test2:~/onebyte$ ./onebyte2 -d 22 s
> 0x0168 ibwrt
> + 0x0138 ibrd dev
> libgpib: IBEOS ioctl failed
> 0 0x0130 ibrd board
> libgpib: IBEOS ioctl failed
> 0 0x0130 ibrd board
> libgpib: IBEOS ioctl failed
> . 0x013c ibrd board
> libgpib: IBEOS ioctl failed
> 0 0x0130 ibrd board
> libgpib: IBEOS ioctl failed
> 0 0x0130 ibrd board
> libgpib: IBEOS ioctl failed
> 0 0x0130 ibrd board
> libgpib: IBEOS ioctl failed
> 9 0x0130 ibrd board
> libgpib: IBEOS ioctl failed
> E 0x01a4 ibrd board
> libgpib: IBEOS ioctl failed
> - 0x0134 ibrd board
> libgpib: IBEOS ioctl failed
> 3 0x0138 ibrd board
> libgpib: IBEOS ioctl failed
> 0x0124 ibrd board
> libgpib: IBEOS ioctl failed
>
> 0x2128 ibrd board
> jhouston@gpib-test2:~/onebyte$
>
> With patched kernel:
>
> jhouston@gpib-test2:~/onebyte$ ./onebyte2 -d 22 s
> 0x0128 ibwrt
> 0 0x0174 ibrd dev
> libgpib: IBEOS ioctl failed
> . 0x0174 ibrd board
> libgpib: IBEOS ioctl failed
> 0 0x0174 ibrd board
> libgpib: IBEOS ioctl failed
> 0 0x0174 ibrd board
> libgpib: IBEOS ioctl failed
> 0 0x0174 ibrd board
> libgpib: IBEOS ioctl failed
> 7 0x0174 ibrd board
> libgpib: IBEOS ioctl failed
> E 0x0174 ibrd board
> libgpib: IBEOS ioctl failed
> - 0x0174 ibrd board
> libgpib: IBEOS ioctl failed
> 3 0x0174 ibrd board
> libgpib: IBEOS ioctl failed
> 0x0174 ibrd board
> libgpib: IBEOS ioctl failed
>
> 0x2174 ibrd board
> jhouston@gpib-test2:~/onebyte$
>
>
> On 9/28/23 13:13, dave penkler wrote:
>
> Hi Jim,
> Please find attached a new version of onebyte to check that board level
> reads work after setting ATN at the end of the read.
> The attached patch for the driver is against the current SVN and sets ATN
> at the end of the read as you proposed.
> @MichaelK you might try this one on the R&S power meter.
> It worked on my Beiming clone:
> In the ibsta 0x174 = CMPL | REM | CIC | ATN | LACS we see the ATN bit set.
> $ onebyte2 -d8
> 0x0168 ibwrt
> H 0x0174 ibrd dev
> E 0x0174 ibrd board
> W 0x0174 ibrd board
> L 0x0174 ibrd board
> E 0x0174 ibrd board
> T 0x0174 ibrd board
> T 0x0174 ibrd board
> - 0x0174 ibrd board
> P 0x0174 ibrd board
> A 0x0174 ibrd board
> C 0x0174 ibrd board
> K 0x0174 ibrd board
> A 0x0174 ibrd board
> R 0x0174 ibrd board
> D 0x0174 ibrd board
> , 0x0174 ibrd board
> E 0x0174 ibrd board
> 3 0x0174 ibrd board
> 6 0x0174 ibrd board
> 3 0x0174 ibrd board
> 1 0x0174 ibrd board
> A 0x0174 ibrd board
> , 0x0174 ibrd board
> 0 0x0174 ibrd board
> , 0x0174 ibrd board
> 2 0x0174 ibrd board
> . 0x0174 ibrd board
> 1 0x0174 ibrd board
> - 0x0174 ibrd board
> 5 0x0174 ibrd board
> . 0x0174 ibrd board
> 0 0x0174 ibrd board
> - 0x0174 ibrd board
> 1 0x0174 ibrd board
> . 0x0174 ibrd board
> 0 0x0174 ibrd board
>
> 0x2174 ibrd board
> Cheers,
> -Dave
>
>
> On Thu, 28 Sept 2023 at 17:59, dave penkler <dpe...@gm...> wrote:
>
>> Hi Jim,
>> Can you please let us know if the removal of TCS in the SVN works for
>> your reading of the calibration data.
>> I have thought some more about your proposal to set ATN at the end of the
>> read. We just need to verify that board level reads after the first device
>> level read still work with the ATN workaround.
>> If it does that would give us a reliable board level ibsta, From the
>> logic analyser traces it looks like the board gives valid ADSR responses
>> when it is in the Talker Active state i.e. after ibwrt.
>> -Dave
>>
>
>
|
|
From: Jim H. <ji...@ov...> - 2023-09-29 00:58:31
|
Hi Dave,Everyone I ran the onebyte2 test against both the SVN kernel and the patched kernel the output follows. I'm getting failures on IBEOS ioctl. I'm still looking at this and I may send another email if I figure it out. I did a fresh install and I may have broken something in the process. JIm Houston Test with current SVN kernel: jhouston@gpib-test2:~/onebyte$ ./onebyte2 -d 22 s 0x0168 ibwrt + 0x0138 ibrd dev libgpib: IBEOS ioctl failed 0 0x0130 ibrd board libgpib: IBEOS ioctl failed 0 0x0130 ibrd board libgpib: IBEOS ioctl failed . 0x013c ibrd board libgpib: IBEOS ioctl failed 0 0x0130 ibrd board libgpib: IBEOS ioctl failed 0 0x0130 ibrd board libgpib: IBEOS ioctl failed 0 0x0130 ibrd board libgpib: IBEOS ioctl failed 9 0x0130 ibrd board libgpib: IBEOS ioctl failed E 0x01a4 ibrd board libgpib: IBEOS ioctl failed - 0x0134 ibrd board libgpib: IBEOS ioctl failed 3 0x0138 ibrd board libgpib: IBEOS ioctl failed 0x0124 ibrd board libgpib: IBEOS ioctl failed 0x2128 ibrd board jhouston@gpib-test2:~/onebyte$ With patched kernel: jhouston@gpib-test2:~/onebyte$ ./onebyte2 -d 22 s 0x0128 ibwrt 0 0x0174 ibrd dev libgpib: IBEOS ioctl failed . 0x0174 ibrd board libgpib: IBEOS ioctl failed 0 0x0174 ibrd board libgpib: IBEOS ioctl failed 0 0x0174 ibrd board libgpib: IBEOS ioctl failed 0 0x0174 ibrd board libgpib: IBEOS ioctl failed 7 0x0174 ibrd board libgpib: IBEOS ioctl failed E 0x0174 ibrd board libgpib: IBEOS ioctl failed - 0x0174 ibrd board libgpib: IBEOS ioctl failed 3 0x0174 ibrd board libgpib: IBEOS ioctl failed 0x0174 ibrd board libgpib: IBEOS ioctl failed 0x2174 ibrd board jhouston@gpib-test2:~/onebyte$ On 9/28/23 13:13, dave penkler wrote: > Hi Jim, > Please find attached a new version of onebyte to check that board > level reads work after setting ATN at the end of the read. > The attached patch for the driver is against the current SVN and sets > ATN at the end of the read as you proposed. > @MichaelK you might try this one on the R&S power meter. > It worked on my Beiming clone: > In the ibsta 0x174 = CMPL | REM | CIC | ATN | LACS we see the ATN bit > set. > $ onebyte2 -d8 > 0x0168 ibwrt > H 0x0174 ibrd dev > E 0x0174 ibrd board > W 0x0174 ibrd board > L 0x0174 ibrd board > E 0x0174 ibrd board > T 0x0174 ibrd board > T 0x0174 ibrd board > - 0x0174 ibrd board > P 0x0174 ibrd board > A 0x0174 ibrd board > C 0x0174 ibrd board > K 0x0174 ibrd board > A 0x0174 ibrd board > R 0x0174 ibrd board > D 0x0174 ibrd board > , 0x0174 ibrd board > E 0x0174 ibrd board > 3 0x0174 ibrd board > 6 0x0174 ibrd board > 3 0x0174 ibrd board > 1 0x0174 ibrd board > A 0x0174 ibrd board > , 0x0174 ibrd board > 0 0x0174 ibrd board > , 0x0174 ibrd board > 2 0x0174 ibrd board > . 0x0174 ibrd board > 1 0x0174 ibrd board > - 0x0174 ibrd board > 5 0x0174 ibrd board > . 0x0174 ibrd board > 0 0x0174 ibrd board > - 0x0174 ibrd board > 1 0x0174 ibrd board > . 0x0174 ibrd board > 0 0x0174 ibrd board > > 0x2174 ibrd board > Cheers, > -Dave > > > On Thu, 28 Sept 2023 at 17:59, dave penkler <dpe...@gm...> wrote: > > Hi Jim, > Can you please let us know if the removal of TCS in the SVN works > for your reading of the calibration data. > I have thought some more about your proposal to set ATN at the end > of the read. We just need to verify that board level reads after > the first device level read still work with the ATN workaround. > If it does that would give us a reliable board level ibsta, From > the logic analyser traces it looks like the board gives valid ADSR > responses when it is in the Talker Active state i.e. after ibwrt. > -Dave > |
|
From: Jim H. <ji...@ov...> - 2023-09-29 00:48:02
|
Hi Dave, Everyone, Yes the current SVN kernel solves my problem and I'm able to read the calibration data from my HP3478A. Jim On 9/28/23 11:59, dave penkler wrote: > Hi Jim, > Can you please let us know if the removal of TCS in the SVN works for > your reading of the calibration data. > I have thought some more about your proposal to set ATN at the end of > the read. We just need to verify that board level reads after the > first device level read still work with the ATN workaround. > If it does that would give us a reliable board level ibsta, From the > logic analyser traces it looks like the board gives valid ADSR > responses when it is in the Talker Active state i.e. after ibwrt. > -Dave > > On Wed, 27 Sept 2023 at 16:37, Michael K <vk...@ya...> wrote: > > > On Wednesday, September 27, 2023 at 07:02:51 AM EDT, dave > penkler <dpe...@gm...> wrote: > > The 0x164 from the NI-USB-HS is the correct value for ibsta. Did > you do one byte reads with ibtest ? > > No, that would be too logical 😺 > > I tried that and it seems that the device responds to an > unsolicited read with " 9.9E + 37". (which according to the manual > means OFLO - Measured value (invalid)) > ( to do a measurement you are required to send a *TRG) > > On more careful examination, the first byte read by "onebyte.c" is > 'R' of the IDN string 'ROHDE&SCHWARZ,NRVD, 101654.002,V1.52 V1.40'. > I guess the device dumps the rest of the string after the first > read. After than I read the first byte of ' 9.9E + 37'. > > Michael > |
|
From: Michael K <vk...@ya...> - 2023-09-28 23:26:01
|
On the R&S NRVD I get ... [maxwell HPIBtest] 😼 ./onebyte2 -d 20 0x0128 ibwrt R 0x0174 ibrd dev 0x0174 ibrd board . 0x0174 ibrd board 0x0174 ibrd board . 0x0174 ibrd board 0x0174 ibrd board . 0x0174 ibrd board 0x0174 ibrd board . 0x0174 ibrd board 0x0174 ibrd board . 0x0174 ibrd board 0x0174 ibrd board 0x0174 ibrd board 0x0174 ibrd board ^C [maxwell HPIBtest] 😼 (I have to kill it) The HP 8753c I get [maxwell HPIBtest] 😼 ./onebyte2 -d 16 0x0168 ibwrt H 0x0174 ibrd dev E 0x0174 ibrd board W 0x0174 ibrd board L 0x0174 ibrd board E 0x0174 ibrd board T 0x0174 ibrd board T 0x0174 ibrd board 0x0174 ibrd board P 0x0174 ibrd board A 0x0174 ibrd board C 0x0174 ibrd board K 0x0174 ibrd board A 0x0174 ibrd board R 0x0174 ibrd board D 0x0174 ibrd board , 0x0174 ibrd board 8 0x0174 ibrd board 7 0x0174 ibrd board 5 0x0174 ibrd board 3 0x0174 ibrd board C 0x0174 ibrd board , 0x0174 ibrd board 0 0x0174 ibrd board , 0x0174 ibrd board 4 0x0174 ibrd board . 0x0174 ibrd board 1 0x0174 ibrd board 3 0x0174 ibrd board 0x2174 ibrd board [maxwell HPIBtest] 😼 On Thursday, September 28, 2023 at 01:15:19 PM EDT, dave penkler <dpe...@gm...> wrote: The attached patch for the driver is against the current SVN and sets ATN at the end of the read as you proposed. @MichaelK you might try this one on the R&S power meter. It worked on my Beiming clone: |
|
From: dave p. <dpe...@gm...> - 2023-09-28 17:14:55
|
Hi Jim, Please find attached a new version of onebyte to check that board level reads work after setting ATN at the end of the read. The attached patch for the driver is against the current SVN and sets ATN at the end of the read as you proposed. @MichaelK you might try this one on the R&S power meter. It worked on my Beiming clone: In the ibsta 0x174 = CMPL | REM | CIC | ATN | LACS we see the ATN bit set. $ onebyte2 -d8 0x0168 ibwrt H 0x0174 ibrd dev E 0x0174 ibrd board W 0x0174 ibrd board L 0x0174 ibrd board E 0x0174 ibrd board T 0x0174 ibrd board T 0x0174 ibrd board - 0x0174 ibrd board P 0x0174 ibrd board A 0x0174 ibrd board C 0x0174 ibrd board K 0x0174 ibrd board A 0x0174 ibrd board R 0x0174 ibrd board D 0x0174 ibrd board , 0x0174 ibrd board E 0x0174 ibrd board 3 0x0174 ibrd board 6 0x0174 ibrd board 3 0x0174 ibrd board 1 0x0174 ibrd board A 0x0174 ibrd board , 0x0174 ibrd board 0 0x0174 ibrd board , 0x0174 ibrd board 2 0x0174 ibrd board . 0x0174 ibrd board 1 0x0174 ibrd board - 0x0174 ibrd board 5 0x0174 ibrd board . 0x0174 ibrd board 0 0x0174 ibrd board - 0x0174 ibrd board 1 0x0174 ibrd board . 0x0174 ibrd board 0 0x0174 ibrd board 0x2174 ibrd board Cheers, -Dave On Thu, 28 Sept 2023 at 17:59, dave penkler <dpe...@gm...> wrote: > Hi Jim, > Can you please let us know if the removal of TCS in the SVN works for your > reading of the calibration data. > I have thought some more about your proposal to set ATN at the end of the > read. We just need to verify that board level reads after the first device > level read still work with the ATN workaround. > If it does that would give us a reliable board level ibsta, From the logic > analyser traces it looks like the board gives valid ADSR responses when it > is in the Talker Active state i.e. after ibwrt. > -Dave > |
|
From: dave p. <dpe...@gm...> - 2023-09-28 16:00:45
|
Hi Jim, Can you please let us know if the removal of TCS in the SVN works for your reading of the calibration data. I have thought some more about your proposal to set ATN at the end of the read. We just need to verify that board level reads after the first device level read still work with the ATN workaround. If it does that would give us a reliable board level ibsta, From the logic analyser traces it looks like the board gives valid ADSR responses when it is in the Talker Active state i.e. after ibwrt. -Dave On Wed, 27 Sept 2023 at 16:37, Michael K <vk...@ya...> wrote: > > On Wednesday, September 27, 2023 at 07:02:51 AM EDT, dave penkler < > dpe...@gm...> wrote: > > The 0x164 from the NI-USB-HS is the correct value for ibsta. Did you do > one byte reads with ibtest ? > > No, that would be too logical 😺 > > I tried that and it seems that the device responds to an unsolicited read > with " 9.9E + 37". (which according to the manual means OFLO - Measured > value (invalid)) > ( to do a measurement you are required to send a *TRG) > > On more careful examination, the first byte read by "onebyte.c" is 'R' of > the IDN string 'ROHDE&SCHWARZ,NRVD, 101654.002,V1.52 V1.40'. > I guess the device dumps the rest of the string after the first read. > After than I read the first byte of ' 9.9E + 37'. > > Michael > |
|
From: Michael K <vk...@ya...> - 2023-09-27 14:37:14
|
> On Wednesday, September 27, 2023 at 07:02:51 AM EDT, dave penkler <dpe...@gm...> wrote: > The 0x164 from the NI-USB-HS is the correct value for ibsta. Did you do one byte reads with ibtest ? No, that would be too logical 😺 I tried that and it seems that the device responds to an unsolicited read with " 9.9E + 37". (which according to the manual means OFLO - Measured value (invalid)) ( to do a measurement you are required to send a *TRG) On more careful examination, the first byte read by "onebyte.c" is 'R' of the IDN string 'ROHDE&SCHWARZ,NRVD, 101654.002,V1.52 V1.40'. I guess the device dumps the rest of the string after the first read. After than I read the first byte of ' 9.9E + 37'. Michael |
|
From: dave p. <dpe...@gm...> - 2023-09-27 11:03:00
|
The 0x164 from the NI-USB-HS is the correct value for ibsta. Did you do one byte reads with ibtest ? /d On Wed, 27 Sept 2023 at 00:05, Michael K <vk...@ya...> wrote: > BTW I could not get the "onebyte.c" programe to work using the R&S NRVD > power meter. > I got a continuations stream of 0x0130 (occasionally a 0x013c) with the > 82357B and, using the NI USB-HS, a continuous stream of 0x0164. > The NRVD responded correctly when I use ibtest with *IDN? > > Michael > > > On Tuesday, September 26, 2023 at 01:38:05 PM EDT, dave penkler < > dpe...@gm...> wrote: > > > > > > Hi Michael, > Thanks so much for these traces. It certainly looks like the instrument > latches the next data byte when the ADSR (address status register of the > 9914) is read. > f6e240c0 13.914312 S Bo:1:039:6 - 9 = > 03000003 01000000 00 <<< read > f6e240c0 13.914346 C Bo:1:039:6 0 9 > > f6e240c0 13.914352 S Bi:1:039:2 - 2 < > f6e240c0 13.921144 C Bi:1:039:2 0 2 = > 4820 > H > <<< H read over the bus > f6c0bf00 13.921175 S Bo:1:039:6 - 3 = > 050102 <<< > request to read ADSR > f6c0bf00 13.921188 C Bo:1:039:6 0 3 > > f6c0bf00 13.921195 S Bi:1:039:2 - 32 < > f6c0bf00 13.921291 C Bi:1:039:2 0 3 = > fa0045 > . . E <<< > response E (the next byte) > > From the other traces sent by Micha and yourself the following instruments > preciously latch the next byte: HP8753C, HP1660E, HP4191A, HP3458A > In the HP3457A traces the current byte is read as ADSR. > So in conclusion all the Agilent 82357B adapters for which we have seen > traces do not return the actual ADSR from the chip when ATN is not set but > he last data byte on the bus. > Not sure how many folks depend on a reliable board ibsta but for now I > propose to leave it as it is. Avoiding sending TCS should fix Jim's issue > without affecting any other folks. > -Dave > > On Tue, 26 Sept 2023 at 18:07, Michael K <vk...@ya...> wrote: > > > > OK Dave, > > Here is the usbmon output. > > I also connected up the logic analyzer and saved the transaction between > the 82357B and the HP8753C (see attached). > > I installed your latest svn commit but I don't think I rebooted (so the > debugging may not reflect your latest driver mod). > > cheers, > > Michael > > > > > > > > > > > > On Tuesday, September 26, 2023 at 03:25:22 AM EDT, dave penkler < > dpe...@gm...> wrote: > > > > > > > > > > > > Hi Michael, > > Could you please capture the usb traffic with Wireshark or usbmon for > this onebyte run. > > Judging by this output maybe your board behaves differently from Jim's > and Micha's but we would like to check. > > Each line of the decode below shows the character read, ascii code of > character decoded as ADSR and ibsta decode. > > It looks like the ibsta corresponds to the next character read > interpreted as ADSR. > > So it might be that the instrument has already latched the next byte on > the bus when the ibsta of the board is taken after the previous read. > > Could you do a onebyte run with a different instrument too please ? > > No need to take the usb traffic for that also. > > Thanks, > > -Dave > > > > > > > > |
|
From: Michael K <vk...@ya...> - 2023-09-26 22:05:47
|
BTW I could not get the "onebyte.c" programe to work using the R&S NRVD power meter. I got a continuations stream of 0x0130 (occasionally a 0x013c) with the 82357B and, using the NI USB-HS, a continuous stream of 0x0164. The NRVD responded correctly when I use ibtest with *IDN? Michael On Tuesday, September 26, 2023 at 01:38:05 PM EDT, dave penkler <dpe...@gm...> wrote: Hi Michael, Thanks so much for these traces. It certainly looks like the instrument latches the next data byte when the ADSR (address status register of the 9914) is read. f6e240c0 13.914312 S Bo:1:039:6 - 9 = 03000003 01000000 00 <<< read f6e240c0 13.914346 C Bo:1:039:6 0 9 > f6e240c0 13.914352 S Bi:1:039:2 - 2 < f6e240c0 13.921144 C Bi:1:039:2 0 2 = 4820 H <<< H read over the bus f6c0bf00 13.921175 S Bo:1:039:6 - 3 = 050102 <<< request to read ADSR f6c0bf00 13.921188 C Bo:1:039:6 0 3 > f6c0bf00 13.921195 S Bi:1:039:2 - 32 < f6c0bf00 13.921291 C Bi:1:039:2 0 3 = fa0045 . . E <<< response E (the next byte) >From the other traces sent by Micha and yourself the following instruments preciously latch the next byte: HP8753C, HP1660E, HP4191A, HP3458A In the HP3457A traces the current byte is read as ADSR. So in conclusion all the Agilent 82357B adapters for which we have seen traces do not return the actual ADSR from the chip when ATN is not set but he last data byte on the bus. Not sure how many folks depend on a reliable board ibsta but for now I propose to leave it as it is. Avoiding sending TCS should fix Jim's issue without affecting any other folks. -Dave On Tue, 26 Sept 2023 at 18:07, Michael K <vk...@ya...> wrote: > > OK Dave, > Here is the usbmon output. > I also connected up the logic analyzer and saved the transaction between the 82357B and the HP8753C (see attached). > I installed your latest svn commit but I don't think I rebooted (so the debugging may not reflect your latest driver mod). > cheers, > Michael > > > > > > On Tuesday, September 26, 2023 at 03:25:22 AM EDT, dave penkler <dpe...@gm...> wrote: > > > > > > Hi Michael, > Could you please capture the usb traffic with Wireshark or usbmon for this onebyte run. > Judging by this output maybe your board behaves differently from Jim's and Micha's but we would like to check. > Each line of the decode below shows the character read, ascii code of character decoded as ADSR and ibsta decode. > It looks like the ibsta corresponds to the next character read interpreted as ADSR. > So it might be that the instrument has already latched the next byte on the bus when the ibsta of the board is taken after the previous read. > Could you do a onebyte run with a different instrument too please ? > No need to take the usb traffic for that also. > Thanks, > -Dave > > > |
|
From: dave p. <dpe...@gm...> - 2023-09-26 17:38:13
|
Hi Michael,
Thanks so much for these traces. It certainly looks like the instrument
latches the next data byte when the ADSR (address status register of the
9914) is read.
f6e240c0 13.914312 S Bo:1:039:6 - 9 =
03000003 01000000 00 <<< read
f6e240c0 13.914346 C Bo:1:039:6 0 9 >
f6e240c0 13.914352 S Bi:1:039:2 - 2 <
f6e240c0 13.921144 C Bi:1:039:2 0 2 =
4820
H <<<
H read over the bus
f6c0bf00 13.921175 S Bo:1:039:6 - 3 =
050102 <<<
request to read ADSR
f6c0bf00 13.921188 C Bo:1:039:6 0 3 >
f6c0bf00 13.921195 S Bi:1:039:2 - 32 <
f6c0bf00 13.921291 C Bi:1:039:2 0 3 =
fa0045
. . E <<<
response E (the next byte)
>From the other traces sent by Micha and yourself the following instruments
preciously latch the next byte: HP8753C, HP1660E, HP4191A, HP3458A
In the HP3457A traces the current byte is read as ADSR.
So in conclusion all the Agilent 82357B adapters for which we have seen
traces do not return the actual ADSR from the chip when ATN is not set but
he last data byte on the bus.
Not sure how many folks depend on a reliable board ibsta but for now I
propose to leave it as it is. Avoiding sending TCS should fix Jim's issue
without affecting any other folks.
-Dave
On Tue, 26 Sept 2023 at 18:07, Michael K <vk...@ya...> wrote:
>
> OK Dave,
> Here is the usbmon output.
> I also connected up the logic analyzer and saved the transaction between
> the 82357B and the HP8753C (see attached).
> I installed your latest svn commit but I don't think I rebooted (so the
> debugging may not reflect your latest driver mod).
> cheers,
> Michael
>
>
>
>
>
> On Tuesday, September 26, 2023 at 03:25:22 AM EDT, dave penkler <
> dpe...@gm...> wrote:
>
>
>
>
>
> Hi Michael,
> Could you please capture the usb traffic with Wireshark or usbmon for this
> onebyte run.
> Judging by this output maybe your board behaves differently from Jim's and
> Micha's but we would like to check.
> Each line of the decode below shows the character read, ascii code of
> character decoded as ADSR and ibsta decode.
> It looks like the ibsta corresponds to the next character read interpreted
> as ADSR.
> So it might be that the instrument has already latched the next byte on
> the bus when the ibsta of the board is taken after the previous read.
> Could you do a onebyte run with a different instrument too please ?
> No need to take the usb traffic for that also.
> Thanks,
> -Dave
>
>
>
|
|
From: dave p. <dpe...@gm...> - 2023-09-26 07:39:43
|
Hi Michael, The drivers are fairly similar in structure so I would not expect there to be much difference at all. The difference can depend on how quickly commands are processed and the GPIB transfer speed. cheers, -Dave On Tue, 26 Sept 2023 at 01:27, Michael K via Linux-gpib-general < lin...@li...> wrote: > I have both the Agilent 82357B USB GPIB interface and the NI GPIB-USB-HS > USB interface. > Transactions on the NI device are about 30% slower than the Agilent. (i.e > if a bunch of commands take 150ms to complete on the NI device, they will > do the same in 100ms with the Agilent) > > Is this likely to be a driver difference or is the Agilent device doing a > better job than the NI? > > Michael > > > _______________________________________________ > Linux-gpib-general mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linux-gpib-general > |
|
From: dave p. <dpe...@gm...> - 2023-09-26 07:25:31
|
Hi Michael, Could you please capture the usb traffic with Wireshark or usbmon for this onebyte run. Judging by this output maybe your board behaves differently from Jim's and Micha's but we would like to check. Each line of the decode below shows the character read, ascii code of character decoded as ADSR and ibsta decode. It looks like the ibsta corresponds to the* next *character read interpreted as ADSR. So it might be that the instrument has already latched the next byte on the bus when the ibsta of the board is taken after the previous read. Could you do a onebyte run with a different instrument too please ? No need to take the usb traffic for that also. Thanks, -Dave H LLO | TPAS || CMPL | LOK | CIC | LACS E LLO | LA | ulpa || CMPL | LOK | CIC | TACS | LACS W LLO | LPAS | LA | TA | ulpa || CMPL | LOK | CIC | LACS L LLO | TPAS | LA || CMPL | LOK | CIC | LACS E LLO | LA | ulpa || CMPL | LOK | CIC | LACS T LLO | LPAS | LA || CMPL | LOK | CIC | LACS T LLO | LPAS | LA || CMPL | CIC | ATN ATN || CMPL | LOK | CIC P LLO | LPAS || CMPL | LOK | CIC A LLO | ulpa || CMPL | LOK | CIC | TACS C LLO | TA | ulpa || CMPL | LOK | CIC | TACS K LLO | TPAS | TA | ulpa || CMPL | LOK | CIC A LLO | ulpa || CMPL | LOK | CIC | TACS R LLO | LPAS | TA || CMPL | LOK | CIC | LACS D LLO | LA || CMPL | CIC | ATN | LACS , ATN | TPAS | LA || CMPL | CIC | ATN 8 ATN | LPAS | TPAS || CMPL | CIC | ATN | TACS | LACS 7 ATN | LPAS | LA | TA | ulpa || CMPL | CIC | ATN | LACS 5 ATN | LPAS | LA | ulpa || CMPL | CIC | ATN | TACS 3 ATN | LPAS | TA | ulpa || CMPL | LOK | CIC | TACS C LLO | TA | ulpa || CMPL | CIC | ATN | LACS , ATN | TPAS | LA || CMPL | CIC | ATN 0 ATN | LPAS || CMPL | CIC | ATN | LACS , ATN | TPAS | LA || CMPL | CIC | ATN | LACS 4 ATN | LPAS | LA || CMPL | CIC | ATN | TACS | LACS . ATN | TPAS | LA | TA || CMPL | CIC | ATN 1 ATN | LPAS | ulpa || CMPL | CIC | ATN | TACS 3 ATN | LPAS | TA | ulpa || CMPL | CIC | TACS On Fri, 22 Sept 2023 at 18:08, Michael K via Linux-gpib-general < lin...@li...> wrote: > This is what I get ... > > [maxwell HPIBtest] 😼 cat HPIBresult > H 0x01a4 > E 0x01ac > W 0x01a4 > L 0x01a4 > E 0x01a4 > T 0x01a4 > T 0x0130 > 0x01a0 > P 0x01a0 > A 0x01a8 > C 0x01a8 > K 0x01a0 > A 0x01a8 > R 0x01a4 > D 0x0134 > , 0x0130 > 8 0x013c > 7 0x0134 > 5 0x0138 > 3 0x01a8 > C 0x0134 > , 0x0130 > 0 0x0134 > , 0x0134 > 4 0x013c > . 0x0130 > 1 0x0138 > 3 0x0128 > > > 0x0128 > [maxwell HPIBtest] 😼 > > > > _______________________________________________ > Linux-gpib-general mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linux-gpib-general > |
|
From: Michael K <vk...@ya...> - 2023-09-25 23:26:26
|
I have both the Agilent 82357B USB GPIB interface and the NI GPIB-USB-HS USB interface. Transactions on the NI device are about 30% slower than the Agilent. (i.e if a bunch of commands take 150ms to complete on the NI device, they will do the same in 100ms with the Agilent) Is this likely to be a driver difference or is the Agilent device doing a better job than the NI? Michael |
|
From: dave p. <dpe...@gm...> - 2023-09-25 16:22:33
|
Folks, Off-list Micha provided the usbmon traces and the corresponding outputs of onebyte. Analysing the traces shows that his board also returns the last byte read when the ADSR register is read and the ATN line is not asserted. It also shows that take control synchronously (TCS) always times out. TCS was invoked after the read of the "E" and the "\m" where in the value of the ADSR read ATN is not set and LA is. When sending command bytes and ATN is already set in the returned ADSR value the driver skips sending the TCA/TCS. The command succeeds anyway because the firmware always sends a TCA before sending the command bytes to the 9914. On Jim's board when the driver sends TCS it causes the board to hang. On Micha's board it times out. Below is a decode of one of the runs. The first column is the byte read, the second up to || is the byte read decoded as ADSR and the last is ibsta decoded The ATN, LA and TA bits of the ADSR are systematically reflected in ibsta by ATN, LACS and TACS respectively. In the traces the values of ADSR read while the ATN line is asserted are correct: 0xa4 = REM | ATN | LA. - ATN | TPAS | LA || CMPL | CIC | ATN | LACS 1 ATN | LPAS || CMPL | CIC | ATN 7 ATN | LPAS | LA | TA || CMPL | CIC | ATN | TACS | LACS . ATN | TPAS | LA | TA || CMPL | CIC | ATN | TACS | LACS 3 ATN | LPAS | TA | || CMPL | CIC | ATN | TACS 1 ATN | LPAS || CMPL | CIC | ATN 3 ATN | LPAS | TA || CMPL | CIC | ATN | TACS 0 ATN | LPAS || CMPL | CIC | ATN 0 ATN | LPAS || CMPL | CIC | ATN 0 ATN | LPAS || CMPL | CIC | ATN E LLO | LA || CMPL | LOK | CIC | LACS - ATN | TPAS | LA || CMPL | CIC | ATN | LACS 0 ATN | LPAS || CMPL | CIC | ATN 3 ATN | LPAS | TA || CMPL | CIC | ATN | TACS \m TPAS| LA || CMPL | CIC | LACS The conclusion so far is that there is a bug in the 9914 chip used in the 82357B. I will push a patch to the SVN to avoid sending TCS in the driver. When the TCS times out the driver falls back to TCA when it is about to send command bytes. cheers, -Dave On Mon, 25 Sept 2023 at 12:14, Michael Dittrich <mi...@di...p> wrote: > Hi Jim, > attached the readings from two instruments including 'E' (both are > connected to GPIB and on at the same time). > _read are after reset, end_always are with sending "END ALWAYS" (EOI line > set true when the last byte of each reading sent). > > Ciao, Micha > > -----Ursprüngliche Nachricht----- > Von: Jim Houston <ji...@ov...> > Gesendet: Montag, 25. September 2023 02:51 > An: Michael Dittrich <mi...@di...p>; > lin...@li... > Betreff: Re: AW: [Linux-gpib-general] Agilent 82357B repeatable hard > failure > > Hi Micha, Everyone, > > Thank you for running this. Would you do another run, I would like to > see what happens with a response including the letter 'E'. A command that > returns a voltage would likely do. On my HP3478A a 's' returns the front > panel value it may work on your meters. > > Thanks > Jim > > On 9/24/23 19:48, Michael Dittrich wrote: > > Hi Jim, > > attached the outputs from my system. > > > > Ciao, Micha > > > > jhouston@linux-gpib:~$ python3 byte_read.py 4 volt? > > b'0' 256 > > b'.' 256 > > b'0' 256 > > b'E' 256 > > InternalReceiveSetup: command failed > > Traceback (most recent call last): > > File "byte_read.py", line 12, in <module> > > ch = inst.read(1) > > File "/usr/local/lib/python3.6/dist-packages/Gpib.py", line 59, in > read > > self.res = gpib.read(self.id,len) > > gpib.GpibError: read() failed: An attempt to write command bytes to the > bus has timed out. > > jhouston@linux-gpib:~$ > > > > > > _______________________________________________ > Linux-gpib-general mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linux-gpib-general > |
|
From: Michael D. <mi...@di...> - 2023-09-25 10:13:34
|
Hi Jim, attached the readings from two instruments including 'E' (both are connected to GPIB and on at the same time). _read are after reset, end_always are with sending "END ALWAYS" (EOI line set true when the last byte of each reading sent). Ciao, Micha -----Ursprüngliche Nachricht----- Von: Jim Houston <ji...@ov...> Gesendet: Montag, 25. September 2023 02:51 An: Michael Dittrich <mi...@di...p>; lin...@li... Betreff: Re: AW: [Linux-gpib-general] Agilent 82357B repeatable hard failure Hi Micha, Everyone, Thank you for running this. Would you do another run, I would like to see what happens with a response including the letter 'E'. A command that returns a voltage would likely do. On my HP3478A a 's' returns the front panel value it may work on your meters. Thanks Jim On 9/24/23 19:48, Michael Dittrich wrote: > Hi Jim, > attached the outputs from my system. > > Ciao, Micha > > jhouston@linux-gpib:~$ python3 byte_read.py 4 volt? > b'0' 256 > b'.' 256 > b'0' 256 > b'E' 256 > InternalReceiveSetup: command failed > Traceback (most recent call last): > File "byte_read.py", line 12, in <module> > ch = inst.read(1) > File "/usr/local/lib/python3.6/dist-packages/Gpib.py", line 59, in read > self.res = gpib.read(self.id,len) > gpib.GpibError: read() failed: An attempt to write command bytes to the bus has timed out. > jhouston@linux-gpib:~$ > > |
|
From: dave p. <dpe...@gm...> - 2023-09-25 08:24:31
|
Hi Micha, Thanks for the runs. However the ibsta values seem to be all over the place. But in your case the values are not determined by the byte read. This is also evident in the *IDN? trace you had sent earlier. Normally I would expect to see 0x164 = CMPL | REM | CIC | LACS in every case, which is BTW what I get on my Beiming clone. Here is the output showing the character read with its ASCII code and corresponding decoded ibsta bits from your HP3458A trace as an example. H 01001000 CMPL | LOK | CIC P 01010000 CMPL | CIC | ATN | TACS 3 00110011 CMPL | CIC | ATN | LACS 4 00110100 CMPL | CIC | ATN | LACS 5 00110101 CMPL | CIC | ATN 8 00111000 CMPL | LOK | CIC A 01000001 CMPL | CIC | LACS \n 00001010 CMPL | CIC | TACS I'd be interested to see the corresponding usb wireshark trace. cheers, -Dave On Mon, 25 Sept 2023 at 02:16, Michael Dittrich <mi...@di...p> wrote: > Hi Jim, > attached the outputs from my system. > > Ciao, Micha > > -----Ursprüngliche Nachricht----- > Von: Jim Houston <ji...@ov...> > Gesendet: Freitag, 22. September 2023 15:36 > An: lin...@li... > Betreff: Re: [Linux-gpib-general] Agilent 82357B repeatable hard failure > > Hi Everyone, > > > Spoiler: > Proposed fix for flakey behavior of an Agilent 82357B. Testers wanted. > Under unusual conditions the 82357B returns an EBUS timeout for all > commands until it is unplugged and plugged back in. In particular the > problem depends on the last character of the last message received. > The problem doesn't happen in the normal case where the read buffer is > large enough to hold the whole response and the last character is newline. > The accompanying test program reads characters a byte at a time and can > recreate the problem. If you have an Agilent 82357B and an instrument that > responds to commands please run the attached program and send the output to > help determine whether this is a common problem or only specific to my > board. > > TLDR; > > * The problem * > I was trying to use my HP 82357B to read the calibration data from my > HP3478A meter. It failed with EBUS. > > I posted here on July 26th and have been working with Dave Penkler to > debug this problem since then. It wasn't clear if this was flakey hardware > or a problem with the Linux-gpib agilent_82357a driver. > > The calibration data of the HP3478A can be read a nibble at a time by > sending a two character command consisting of a 'W' followed by a byte with > the 8-bit address of thelocation to be read from the ram. Tom Verbeure has > good description of the process here: > > https://tomverbeure.github.io/2022/12/02/HP3478A-Multimeter-Calibration-Data-Backup-and-Battery-Replacement.html > > The calibration data is returned as a single byte with values in the range > 0x40-0x4f where the lower 4 bits are the value of the addressed nibble. > The EBUS failure only happened for some addresses. A 'W1' > command always worked but sending a 'W4' command caused the next command > to receive an EBUS failure. Once the system returned an EBUS the only way > to recover was to unplug the HP 82357B USB cable and plug it back in. > Further testing showed that it was the returned nibble that predicted the > failure. Here is the table: > > @ABC HIJK - The next read works. > DEFG LMNO - The next read fails with EBUS > > So it was the DI[2] bit which determined the result. > > * The Debug * > I had fun chasing this problem. I started with printks in the driver and > determined that the EBUS was the result of agilent_82357_take_control > failing. This function is supposed to assert ATN to signal that the bytes > which follow are command bytes. This is done automatically when a command > is written or can be done with a user call to ibcac(). > The take_control function sends a command to the GPIB bus control logic in > the 82357B and then polls waiting for ATN to be asserted. > In the failure case it timed out waiting for ATN to be asserted. > > I used my logic analyzer to capture the GPIB activity, wireshark and > usbmon to capture the USB traffic and Linux ftrace because I got tired of > adding printk's. Finally I hooked the logic analyzer to the > TMS9914 chip which implements the GPIB control logic in the 82357B. > > * History related problems * > We knew that there had been problems with the agilent_82350b driver which > involved the take_control path. The issue involves the synchronous option > to take_control. This option determines if the GPIB controller in the > 82357B waits (synchronizes with) a pending IO before asserting ATN. If > the sync option is 1 the controller waits. If sync is zero the controller > just asserts ATN. > The default command path calls ibcac() in the common portion of the gpib > driver with sync=1. There is logic to try to recover from a failure to > assert ATN by trying a second time with sync=0. > It also checks if the ATN bit is already set in ibsta and will avoid > calling the take_control function. The problem with the 82350B and > potentially all TMS9914 based designs is that once it has tried to do a > take_control synchronously it is stuck. A subsequent call with sync=0 > doesn't work. The work around for the 82350B is to have the take_control > function return a timeout error if it is called with sync=1. The ibcac() > will call back with sync=0 avoiding the problem. If the call is from the > user-space library ibcac() (contrary to the documentation), it doesn't fall > back to asynchronous. > It will fail a request with sync=1. Does it return failure if the ATN bit > is falsely already set in ibsta? No because if ATN is not asserted by the > controller the firmware will initiate an asynchronous take control > (TCA) on the chip before sending the command bytes. > > * Keysight to the rescue * > I also tried to reproduce the problem with the Keysight IO libraries. > They have a version for Linux. It works with PyVISA and I was able to > send the 'W1' and 'W4' commands to the HP3478A but it always returned the > front panel display value rather than the calibration ram single byte > response which I had expected. I put some effort into diagnosing this new > problem and believe that it was the result of the IO libraries always > sending a secondary address of 0. So the PyVISA identifier GPIB::22::INSTR > was interpreted as GPIB::22::0::INSTR. I could see this on the GPIB bus > using my logic analyzer, and I could see it in the usbmon trace using > Wireshark. The Keysight IO libraries consist of a proprietary user space > and an open source device driver. I had hoped to see if the Keysight > software initialized the 82357B the same as the linux-gpib. I was able to > capture the initialization from the USB bus using Wireshark. I tried using > the same initialization sequence in the linux-gpib driver and still had the > same EBUS failure. > I wrote a python script which allowed me to use the Agilent driver > bypassing the IO libraries. This let me send 'W4' command to the HP3478A. > Subsequent commands worked. I also found that the Keysight code always > used asynchronous take control command to assert ATN. > > > * Enlightenment * > I shared the captured traces with Dave, and he figured out that the > character being read determined if the take_control function was being > called with sync=0 or 1. This is the result of another short cut in the > common gpib ibcac() function that will only use the sync option if the > board is a listener on the GPIB bus. It does this by checking the LACS > status bit. The agilent_82357a driver gets this status from the TMS9914 > ADSR register. In the case of my Agilent 82357B this register was > corrupted with the last character of the last message received. > The failure case with my HP 3478A, issuing a 'W4' command results in > location 0x34 being read and single character 'F' was returned. > This character was also being returned for reads of the ADSR register. > This corruption of the ADSR register caused the common gpib ibcac() to > call the agilent_82357a_take_control() with sync=1. > This triggers a failure similar to the problem previously seen with the > Agilent 82350B. The AUX_TCS is sent but the ATN signal is never asserted. > > * Can you reproduce the failure at home? * From the start I was not sure > if this was a broken Agilent 82357B or a problem with the driver. We still > don't know. We would like other Agilent 82357 owners to test. You don't > need an HP3478A to reproduce this problem. Since the problem depends on > the last character received it would often be masked since a '\n' doesn't > cause the failure. In normal use the receive buffer is large enough to > hold the whole response and the problem is avoided. > The problem is easy to reproduce if you read a character at a time. > The attached python script takes two arguments the device number and a > command. Here is an example using my HP6642 power supply: > > jhouston@linux-gpib:~$ python3 byte_read.py 4 volt? > b'0' 256 > b'.' 256 > b'0' 256 > b'E' 256 > InternalReceiveSetup: command failed > Traceback (most recent call last): > File "byte_read.py", line 12, in <module> > ch = inst.read(1) > File "/usr/local/lib/python3.6/dist-packages/Gpib.py", line 59, in read > self.res = gpib.read(self.id,len) > gpib.GpibError: read() failed: An attempt to write command bytes to the > bus has timed out. > jhouston@linux-gpib:~$ > > In this case the 'E' as the last character read triggers the failure. > > Dave Penkler ran the attached 'C' program on his Beiming 82357B clone with > an HP34401 dmm without errors. But as it has its own firmware it does not > prove that there is not a common problem with the Agilents. > $ onebyte -m2 -d7 "MEAS:VOLT?" > - 0x0164 > 1 0x0164 > . 0x0164 > 9 0x0164 > 4 0x0164 > 8 0x0164 > E 0x0164 > - 0x0164 > 0 0x0164 > 6 0x0164 > > 0x0164 > $ > > * The Hardware * > The Agilent 82357B consists of > a Cypress EZ-USB chip, a GPIB controller chip, a Xilinx XC9536 CPLD and > bus transceivers. On my 82357B the GPIB controller is labeled Agilent > 1822-0639. Google searches find this in the BOM for several > HP/Agilent/Keysight products as a TMS9914. It would be nice to know the > difference between the 82357A and 82357B. From picture of the boards > posted to the internet they have the same major parts. Mine has the same > revision label on the Xilinx XC9536 as a rev A board picture posted on the > Sigrok website here: > https://sigrok.org/wiki/Agilent_82357A > > The firmware for the Cypress EZ-USB is downloaded using a udev script > which runs fxload. The A/B revs of the 82357 have different firmware files > from Agilent. Again we don't know why the firmware is different. > The agilent_82357a driver is used for both and treats them the same. > > This might be a hardware problem unique to my 82357B. In addition to the > failure with the ADSR register corruption, I have seen other strange > behavior. I have seen bursts of traffic which include very fast DMA > transfers which do not match any request from the driver. There is always > a chance that connecting a logic analyzer may effect the circuit under > test. I'm using a HP16702A and connecting to the TMS9914 using a PLCC clip > and flying leads. The GPIB is probed using an HP10342. I don't have a > good ground path for the flying lead probes, but the traces make sense so I > think that the DMA transfers are real. > It would be nice to instrument another 82357 but it is hard to justify > spending the $100 which it is likely to cost. > > * The right fix * > I had hoped that this problem was the same as take_control problem in the > agilent_82350b driver. I tried changing take_control to only use AUX_TCA. > This fix worked and I was able to read the calibration ram of the HP3478A. > > Once we found that the problem was the result of reads of the > TMS9914 ADSR register being corrupted, we tested various commands and > found that only the AUX_TCS and AUX_TCA would restore the ADSR register to > correct operation. We tried using the clear LON (Listener only) command. > This does not restore the correct function of the ADSR register but seems > to make AUX_TCS work if it is used by the take_control function to assert > ATN. > > Calling take_control from the agilent_82357a_read function would restore > the correct ADSR register behavior. I have tested this and it solves my > problems. Dave Penkler is concerned that users of the low-level interface > may be surprised that the ATN signal has been asserted. > Having the ATN asserted works well for most high level operations because > the next operation is likely to have to send commands to setup listen and > talk addresses. > > The other alternative is to understand when we can trust the ADSR register > and to provide a resonable guess of the GPIB state when we know that the > ADSR is corrupt. > > Jim Houston > > > _______________________________________________ > Linux-gpib-general mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linux-gpib-general > |
|
From: Jim H. <ji...@ov...> - 2023-09-25 00:50:50
|
Hi Micha, Everyone, Thank you for running this. Would you do another run, I would like to see what happens with a response including the letter 'E'. A command that returns a voltage would likely do. On my HP3478A a 's' returns the front panel value it may work on your meters. Thanks Jim On 9/24/23 19:48, Michael Dittrich wrote: > Hi Jim, > attached the outputs from my system. > > Ciao, Micha > > jhouston@linux-gpib:~$ python3 byte_read.py 4 volt? > b'0' 256 > b'.' 256 > b'0' 256 > b'E' 256 > InternalReceiveSetup: command failed > Traceback (most recent call last): > File "byte_read.py", line 12, in <module> > ch = inst.read(1) > File "/usr/local/lib/python3.6/dist-packages/Gpib.py", line 59, in read > self.res = gpib.read(self.id,len) > gpib.GpibError: read() failed: An attempt to write command bytes to the bus has timed out. > jhouston@linux-gpib:~$ > > |
|
From: Michael D. <mi...@di...> - 2023-09-25 00:15:41
|
Hi Jim, attached the outputs from my system. Ciao, Micha -----Ursprüngliche Nachricht----- Von: Jim Houston <ji...@ov...> Gesendet: Freitag, 22. September 2023 15:36 An: lin...@li... Betreff: Re: [Linux-gpib-general] Agilent 82357B repeatable hard failure Hi Everyone, Spoiler: Proposed fix for flakey behavior of an Agilent 82357B. Testers wanted. Under unusual conditions the 82357B returns an EBUS timeout for all commands until it is unplugged and plugged back in. In particular the problem depends on the last character of the last message received. The problem doesn't happen in the normal case where the read buffer is large enough to hold the whole response and the last character is newline. The accompanying test program reads characters a byte at a time and can recreate the problem. If you have an Agilent 82357B and an instrument that responds to commands please run the attached program and send the output to help determine whether this is a common problem or only specific to my board. TLDR; * The problem * I was trying to use my HP 82357B to read the calibration data from my HP3478A meter. It failed with EBUS. I posted here on July 26th and have been working with Dave Penkler to debug this problem since then. It wasn't clear if this was flakey hardware or a problem with the Linux-gpib agilent_82357a driver. The calibration data of the HP3478A can be read a nibble at a time by sending a two character command consisting of a 'W' followed by a byte with the 8-bit address of thelocation to be read from the ram. Tom Verbeure has good description of the process here: https://tomverbeure.github.io/2022/12/02/HP3478A-Multimeter-Calibration-Data-Backup-and-Battery-Replacement.html The calibration data is returned as a single byte with values in the range 0x40-0x4f where the lower 4 bits are the value of the addressed nibble. The EBUS failure only happened for some addresses. A 'W1' command always worked but sending a 'W4' command caused the next command to receive an EBUS failure. Once the system returned an EBUS the only way to recover was to unplug the HP 82357B USB cable and plug it back in. Further testing showed that it was the returned nibble that predicted the failure. Here is the table: @ABC HIJK - The next read works. DEFG LMNO - The next read fails with EBUS So it was the DI[2] bit which determined the result. * The Debug * I had fun chasing this problem. I started with printks in the driver and determined that the EBUS was the result of agilent_82357_take_control failing. This function is supposed to assert ATN to signal that the bytes which follow are command bytes. This is done automatically when a command is written or can be done with a user call to ibcac(). The take_control function sends a command to the GPIB bus control logic in the 82357B and then polls waiting for ATN to be asserted. In the failure case it timed out waiting for ATN to be asserted. I used my logic analyzer to capture the GPIB activity, wireshark and usbmon to capture the USB traffic and Linux ftrace because I got tired of adding printk's. Finally I hooked the logic analyzer to the TMS9914 chip which implements the GPIB control logic in the 82357B. * History related problems * We knew that there had been problems with the agilent_82350b driver which involved the take_control path. The issue involves the synchronous option to take_control. This option determines if the GPIB controller in the 82357B waits (synchronizes with) a pending IO before asserting ATN. If the sync option is 1 the controller waits. If sync is zero the controller just asserts ATN. The default command path calls ibcac() in the common portion of the gpib driver with sync=1. There is logic to try to recover from a failure to assert ATN by trying a second time with sync=0. It also checks if the ATN bit is already set in ibsta and will avoid calling the take_control function. The problem with the 82350B and potentially all TMS9914 based designs is that once it has tried to do a take_control synchronously it is stuck. A subsequent call with sync=0 doesn't work. The work around for the 82350B is to have the take_control function return a timeout error if it is called with sync=1. The ibcac() will call back with sync=0 avoiding the problem. If the call is from the user-space library ibcac() (contrary to the documentation), it doesn't fall back to asynchronous. It will fail a request with sync=1. Does it return failure if the ATN bit is falsely already set in ibsta? No because if ATN is not asserted by the controller the firmware will initiate an asynchronous take control (TCA) on the chip before sending the command bytes. * Keysight to the rescue * I also tried to reproduce the problem with the Keysight IO libraries. They have a version for Linux. It works with PyVISA and I was able to send the 'W1' and 'W4' commands to the HP3478A but it always returned the front panel display value rather than the calibration ram single byte response which I had expected. I put some effort into diagnosing this new problem and believe that it was the result of the IO libraries always sending a secondary address of 0. So the PyVISA identifier GPIB::22::INSTR was interpreted as GPIB::22::0::INSTR. I could see this on the GPIB bus using my logic analyzer, and I could see it in the usbmon trace using Wireshark. The Keysight IO libraries consist of a proprietary user space and an open source device driver. I had hoped to see if the Keysight software initialized the 82357B the same as the linux-gpib. I was able to capture the initialization from the USB bus using Wireshark. I tried using the same initialization sequence in the linux-gpib driver and still had the same EBUS failure. I wrote a python script which allowed me to use the Agilent driver bypassing the IO libraries. This let me send 'W4' command to the HP3478A. Subsequent commands worked. I also found that the Keysight code always used asynchronous take control command to assert ATN. * Enlightenment * I shared the captured traces with Dave, and he figured out that the character being read determined if the take_control function was being called with sync=0 or 1. This is the result of another short cut in the common gpib ibcac() function that will only use the sync option if the board is a listener on the GPIB bus. It does this by checking the LACS status bit. The agilent_82357a driver gets this status from the TMS9914 ADSR register. In the case of my Agilent 82357B this register was corrupted with the last character of the last message received. The failure case with my HP 3478A, issuing a 'W4' command results in location 0x34 being read and single character 'F' was returned. This character was also being returned for reads of the ADSR register. This corruption of the ADSR register caused the common gpib ibcac() to call the agilent_82357a_take_control() with sync=1. This triggers a failure similar to the problem previously seen with the Agilent 82350B. The AUX_TCS is sent but the ATN signal is never asserted. * Can you reproduce the failure at home? * From the start I was not sure if this was a broken Agilent 82357B or a problem with the driver. We still don't know. We would like other Agilent 82357 owners to test. You don't need an HP3478A to reproduce this problem. Since the problem depends on the last character received it would often be masked since a '\n' doesn't cause the failure. In normal use the receive buffer is large enough to hold the whole response and the problem is avoided. The problem is easy to reproduce if you read a character at a time. The attached python script takes two arguments the device number and a command. Here is an example using my HP6642 power supply: jhouston@linux-gpib:~$ python3 byte_read.py 4 volt? b'0' 256 b'.' 256 b'0' 256 b'E' 256 InternalReceiveSetup: command failed Traceback (most recent call last): File "byte_read.py", line 12, in <module> ch = inst.read(1) File "/usr/local/lib/python3.6/dist-packages/Gpib.py", line 59, in read self.res = gpib.read(self.id,len) gpib.GpibError: read() failed: An attempt to write command bytes to the bus has timed out. jhouston@linux-gpib:~$ In this case the 'E' as the last character read triggers the failure. Dave Penkler ran the attached 'C' program on his Beiming 82357B clone with an HP34401 dmm without errors. But as it has its own firmware it does not prove that there is not a common problem with the Agilents. $ onebyte -m2 -d7 "MEAS:VOLT?" - 0x0164 1 0x0164 . 0x0164 9 0x0164 4 0x0164 8 0x0164 E 0x0164 - 0x0164 0 0x0164 6 0x0164 0x0164 $ * The Hardware * The Agilent 82357B consists of a Cypress EZ-USB chip, a GPIB controller chip, a Xilinx XC9536 CPLD and bus transceivers. On my 82357B the GPIB controller is labeled Agilent 1822-0639. Google searches find this in the BOM for several HP/Agilent/Keysight products as a TMS9914. It would be nice to know the difference between the 82357A and 82357B. From picture of the boards posted to the internet they have the same major parts. Mine has the same revision label on the Xilinx XC9536 as a rev A board picture posted on the Sigrok website here: https://sigrok.org/wiki/Agilent_82357A The firmware for the Cypress EZ-USB is downloaded using a udev script which runs fxload. The A/B revs of the 82357 have different firmware files from Agilent. Again we don't know why the firmware is different. The agilent_82357a driver is used for both and treats them the same. This might be a hardware problem unique to my 82357B. In addition to the failure with the ADSR register corruption, I have seen other strange behavior. I have seen bursts of traffic which include very fast DMA transfers which do not match any request from the driver. There is always a chance that connecting a logic analyzer may effect the circuit under test. I'm using a HP16702A and connecting to the TMS9914 using a PLCC clip and flying leads. The GPIB is probed using an HP10342. I don't have a good ground path for the flying lead probes, but the traces make sense so I think that the DMA transfers are real. It would be nice to instrument another 82357 but it is hard to justify spending the $100 which it is likely to cost. * The right fix * I had hoped that this problem was the same as take_control problem in the agilent_82350b driver. I tried changing take_control to only use AUX_TCA. This fix worked and I was able to read the calibration ram of the HP3478A. Once we found that the problem was the result of reads of the TMS9914 ADSR register being corrupted, we tested various commands and found that only the AUX_TCS and AUX_TCA would restore the ADSR register to correct operation. We tried using the clear LON (Listener only) command. This does not restore the correct function of the ADSR register but seems to make AUX_TCS work if it is used by the take_control function to assert ATN. Calling take_control from the agilent_82357a_read function would restore the correct ADSR register behavior. I have tested this and it solves my problems. Dave Penkler is concerned that users of the low-level interface may be surprised that the ATN signal has been asserted. Having the ATN asserted works well for most high level operations because the next operation is likely to have to send commands to setup listen and talk addresses. The other alternative is to understand when we can trust the ADSR register and to provide a resonable guess of the GPIB state when we know that the ADSR is corrupt. Jim Houston |
|
From: Michael K <vk...@ya...> - 2023-09-22 17:06:11
|
Hi Jim, I's a '82357B' $ lsusb -v Bus 001 Device 016: ID 0957:0718 Agilent Technologies, Inc. 82357B () Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 0 bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x0957 Agilent Technologies, Inc. idProduct 0x0718 bcdDevice 0.00 iManufacturer 1 Agilent Technologies, Inc. iProduct 2 82357B () iSerial 5 MY49450720 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 0x0027 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 3 HIGHSPEED bmAttributes 0x80 (Bus Powered) MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 0 bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x06 EP 6 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x88 EP 8 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 1 Device Qualifier (for other device speed): bLength 10 bDescriptorType 6 bcdUSB 2.00 bDeviceClass 0 bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 bNumConfigurations 1 Device Status: 0x0000 (Bus Powered) On Friday, September 22, 2023 at 12:30:18 PM EDT, Jim Houston <ji...@ov...> wrote: Hi Michael, Good a passed test. Is this with an Agilent 82357A or B? |
|
From: Jim H. <ji...@ov...> - 2023-09-22 16:30:28
|
Hi Michael, Good a passed test. Is this with an Agilent 82357A or B? JIm Houston On 9/22/23 12:07, Michael K wrote: > This is what I get ... > > [maxwell HPIBtest] 😼 cat HPIBresult > H 0x01a4 > E 0x01ac > W 0x01a4 > L 0x01a4 > E 0x01a4 > T 0x01a4 > T 0x0130 > 0x01a0 > P 0x01a0 > A 0x01a8 > C 0x01a8 > K 0x01a0 > A 0x01a8 > R 0x01a4 > D 0x0134 > , 0x0130 > 8 0x013c > 7 0x0134 > 5 0x0138 > 3 0x01a8 > C 0x0134 > , 0x0130 > 0 0x0134 > , 0x0134 > 4 0x013c > . 0x0130 > 1 0x0138 > 3 0x0128 > > > 0x0128 > [maxwell HPIBtest] 😼 > |
|
From: Michael K <vk...@ya...> - 2023-09-22 16:07:54
|
This is what I get ... [maxwell HPIBtest] 😼 cat HPIBresult H 0x01a4 E 0x01ac W 0x01a4 L 0x01a4 E 0x01a4 T 0x01a4 T 0x0130 0x01a0 P 0x01a0 A 0x01a8 C 0x01a8 K 0x01a0 A 0x01a8 R 0x01a4 D 0x0134 , 0x0130 8 0x013c 7 0x0134 5 0x0138 3 0x01a8 C 0x0134 , 0x0130 0 0x0134 , 0x0134 4 0x013c . 0x0130 1 0x0138 3 0x0128 0x0128 [maxwell HPIBtest] 😼 |
|
From: Jim H. <ji...@ov...> - 2023-09-22 13:35:54
|
Hi Everyone, Spoiler: Proposed fix for flakey behavior of an Agilent 82357B. Testers wanted. Under unusual conditions the 82357B returns an EBUS timeout for all commands until it is unplugged and plugged back in. In particular the problem depends on the last character of the last message received. The problem doesn't happen in the normal case where the read buffer is large enough to hold the whole response and the last character is newline. The accompanying test program reads characters a byte at a time and can recreate the problem. If you have an Agilent 82357B and an instrument that responds to commands please run the attached program and send the output to help determine whether this is a common problem or only specific to my board. TLDR; * The problem * I was trying to use my HP 82357B to read the calibration data from my HP3478A meter. It failed with EBUS. I posted here on July 26th and have been working with Dave Penkler to debug this problem since then. It wasn't clear if this was flakey hardware or a problem with the Linux-gpib agilent_82357a driver. The calibration data of the HP3478A can be read a nibble at a time by sending a two character command consisting of a 'W' followed by a byte with the 8-bit address of thelocation to be read from the ram. Tom Verbeure has good description of the process here: https://tomverbeure.github.io/2022/12/02/HP3478A-Multimeter-Calibration-Data-Backup-and-Battery-Replacement.html The calibration data is returned as a single byte with values in the range 0x40-0x4f where the lower 4 bits are the value of the addressed nibble. The EBUS failure only happened for some addresses. A 'W1' command always worked but sending a 'W4' command caused the next command to receive an EBUS failure. Once the system returned an EBUS the only way to recover was to unplug the HP 82357B USB cable and plug it back in. Further testing showed that it was the returned nibble that predicted the failure. Here is the table: @ABC HIJK - The next read works. DEFG LMNO - The next read fails with EBUS So it was the DI[2] bit which determined the result. * The Debug * I had fun chasing this problem. I started with printks in the driver and determined that the EBUS was the result of agilent_82357_take_control failing. This function is supposed to assert ATN to signal that the bytes which follow are command bytes. This is done automatically when a command is written or can be done with a user call to ibcac(). The take_control function sends a command to the GPIB bus control logic in the 82357B and then polls waiting for ATN to be asserted. In the failure case it timed out waiting for ATN to be asserted. I used my logic analyzer to capture the GPIB activity, wireshark and usbmon to capture the USB traffic and Linux ftrace because I got tired of adding printk's. Finally I hooked the logic analyzer to the TMS9914 chip which implements the GPIB control logic in the 82357B. * History related problems * We knew that there had been problems with the agilent_82350b driver which involved the take_control path. The issue involves the synchronous option to take_control. This option determines if the GPIB controller in the 82357B waits (synchronizes with) a pending IO before asserting ATN. If the sync option is 1 the controller waits. If sync is zero the controller just asserts ATN. The default command path calls ibcac() in the common portion of the gpib driver with sync=1. There is logic to try to recover from a failure to assert ATN by trying a second time with sync=0. It also checks if the ATN bit is already set in ibsta and will avoid calling the take_control function. The problem with the 82350B and potentially all TMS9914 based designs is that once it has tried to do a take_control synchronously it is stuck. A subsequent call with sync=0 doesn't work. The work around for the 82350B is to have the take_control function return a timeout error if it is called with sync=1. The ibcac() will call back with sync=0 avoiding the problem. If the call is from the user-space library ibcac() (contrary to the documentation), it doesn't fall back to asynchronous. It will fail a request with sync=1. Does it return failure if the ATN bit is falsely already set in ibsta? No because if ATN is not asserted by the controller the firmware will initiate an asynchronous take control (TCA) on the chip before sending the command bytes. * Keysight to the rescue * I also tried to reproduce the problem with the Keysight IO libraries. They have a version for Linux. It works with PyVISA and I was able to send the 'W1' and 'W4' commands to the HP3478A but it always returned the front panel display value rather than the calibration ram single byte response which I had expected. I put some effort into diagnosing this new problem and believe that it was the result of the IO libraries always sending a secondary address of 0. So the PyVISA identifier GPIB::22::INSTR was interpreted as GPIB::22::0::INSTR. I could see this on the GPIB bus using my logic analyzer, and I could see it in the usbmon trace using Wireshark. The Keysight IO libraries consist of a proprietary user space and an open source device driver. I had hoped to see if the Keysight software initialized the 82357B the same as the linux-gpib. I was able to capture the initialization from the USB bus using Wireshark. I tried using the same initialization sequence in the linux-gpib driver and still had the same EBUS failure. I wrote a python script which allowed me to use the Agilent driver bypassing the IO libraries. This let me send 'W4' command to the HP3478A. Subsequent commands worked. I also found that the Keysight code always used asynchronous take control command to assert ATN. * Enlightenment * I shared the captured traces with Dave, and he figured out that the character being read determined if the take_control function was being called with sync=0 or 1. This is the result of another short cut in the common gpib ibcac() function that will only use the sync option if the board is a listener on the GPIB bus. It does this by checking the LACS status bit. The agilent_82357a driver gets this status from the TMS9914 ADSR register. In the case of my Agilent 82357B this register was corrupted with the last character of the last message received. The failure case with my HP 3478A, issuing a 'W4' command results in location 0x34 being read and single character 'F' was returned. This character was also being returned for reads of the ADSR register. This corruption of the ADSR register caused the common gpib ibcac() to call the agilent_82357a_take_control() with sync=1. This triggers a failure similar to the problem previously seen with the Agilent 82350B. The AUX_TCS is sent but the ATN signal is never asserted. * Can you reproduce the failure at home? * From the start I was not sure if this was a broken Agilent 82357B or a problem with the driver. We still don't know. We would like other Agilent 82357 owners to test. You don't need an HP3478A to reproduce this problem. Since the problem depends on the last character received it would often be masked since a '\n' doesn't cause the failure. In normal use the receive buffer is large enough to hold the whole response and the problem is avoided. The problem is easy to reproduce if you read a character at a time. The attached python script takes two arguments the device number and a command. Here is an example using my HP6642 power supply: jhouston@linux-gpib:~$ python3 byte_read.py 4 volt? b'0' 256 b'.' 256 b'0' 256 b'E' 256 InternalReceiveSetup: command failed Traceback (most recent call last): File "byte_read.py", line 12, in <module> ch = inst.read(1) File "/usr/local/lib/python3.6/dist-packages/Gpib.py", line 59, in read self.res = gpib.read(self.id,len) gpib.GpibError: read() failed: An attempt to write command bytes to the bus has timed out. jhouston@linux-gpib:~$ In this case the 'E' as the last character read triggers the failure. Dave Penkler ran the attached 'C' program on his Beiming 82357B clone with an HP34401 dmm without errors. But as it has its own firmware it does not prove that there is not a common problem with the Agilents. $ onebyte -m2 -d7 "MEAS:VOLT?" - 0x0164 1 0x0164 . 0x0164 9 0x0164 4 0x0164 8 0x0164 E 0x0164 - 0x0164 0 0x0164 6 0x0164 0x0164 $ * The Hardware * The Agilent 82357B consists of a Cypress EZ-USB chip, a GPIB controller chip, a Xilinx XC9536 CPLD and bus transceivers. On my 82357B the GPIB controller is labeled Agilent 1822-0639. Google searches find this in the BOM for several HP/Agilent/Keysight products as a TMS9914. It would be nice to know the difference between the 82357A and 82357B. From picture of the boards posted to the internet they have the same major parts. Mine has the same revision label on the Xilinx XC9536 as a rev A board picture posted on the Sigrok website here: https://sigrok.org/wiki/Agilent_82357A The firmware for the Cypress EZ-USB is downloaded using a udev script which runs fxload. The A/B revs of the 82357 have different firmware files from Agilent. Again we don't know why the firmware is different. The agilent_82357a driver is used for both and treats them the same. This might be a hardware problem unique to my 82357B. In addition to the failure with the ADSR register corruption, I have seen other strange behavior. I have seen bursts of traffic which include very fast DMA transfers which do not match any request from the driver. There is always a chance that connecting a logic analyzer may effect the circuit under test. I'm using a HP16702A and connecting to the TMS9914 using a PLCC clip and flying leads. The GPIB is probed using an HP10342. I don't have a good ground path for the flying lead probes, but the traces make sense so I think that the DMA transfers are real. It would be nice to instrument another 82357 but it is hard to justify spending the $100 which it is likely to cost. * The right fix * I had hoped that this problem was the same as take_control problem in the agilent_82350b driver. I tried changing take_control to only use AUX_TCA. This fix worked and I was able to read the calibration ram of the HP3478A. Once we found that the problem was the result of reads of the TMS9914 ADSR register being corrupted, we tested various commands and found that only the AUX_TCS and AUX_TCA would restore the ADSR register to correct operation. We tried using the clear LON (Listener only) command. This does not restore the correct function of the ADSR register but seems to make AUX_TCS work if it is used by the take_control function to assert ATN. Calling take_control from the agilent_82357a_read function would restore the correct ADSR register behavior. I have tested this and it solves my problems. Dave Penkler is concerned that users of the low-level interface may be surprised that the ATN signal has been asserted. Having the ATN asserted works well for most high level operations because the next operation is likely to have to send commands to setup listen and talk addresses. The other alternative is to understand when we can trust the ADSR register and to provide a resonable guess of the GPIB state when we know that the ADSR is corrupt. Jim Houston |
|
From: dave p. <dpe...@gm...> - 2023-09-13 07:48:55
|
Hi Saif, On Wed, 13 Sept 2023 at 07:51, Saif Mostafa <goe...@gm...> wrote: > > Thank you for answering, does that mean I can ignore the depmod failing > and proceed assuming the installation was successful? > Yes you can safely ignore that message. cheers, /d > > Sincerely, > Saif Mostafa > ------------------------------ > *From:* dave penkler <dpe...@gm...> > *Sent:* Friday, September 1, 2023 7:47:17 AM > *To:* Saif Mostafa <goe...@gm...> > *Cc:* lin...@li... < > lin...@li...> > *Subject:* Re: [Linux-gpib-general] missing "System.map" and depmod > skipped > > Hi, > The linux-gpib Makefile runs depmod for you. So your installation should > be fine. In Debian based systems, like Ubuntu, the depmod.sh script fails > with the message you posted. > regards, > /d > > On Thu, 24 Aug 2023 at 06:25, Saif Mostafa <goe...@gm...> > wrote: > > Hello, > > I am having trouble installing the linux gpib drivers on Ubuntu 22.04 > LTS. I was able to build using the make command but once I move on to the > install I get: > "Warning: modules_install: missing 'System.map' file. Skipping depmod." > > I am sure this is a common problem but I am not really familiar with it. > I also wanted to mention that I am not entirely sure I am doing all the > correct steps as I untar the downloaded tarball in the Downloads directory > and the install file mentioned a lot about having a copy of the kernel > source. I anticipate this might be one of those "building against a > different kernel" but I am hoping I could get some help. > > Sincerely, > Saif Mostafa > _______________________________________________ > Linux-gpib-general mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linux-gpib-general > > |
5 messages has been excluded from this view by a project administrator.
