Corrupt 488.2 function calls in gpib-32.dll ??

[Kurt__]

Hi,

it appears as if the 488.2 function calls Send() and Receive() in the gpib-32.dll are producing corrupt results in certain circumstances as shown with the following example with an Agilent 3606A Multimeter (GPIB 6) and a Lakeshore 340 Temperature Controller (GPIB 4):

Using the 488.2 function calls in gpib-32.dll (called from a JAVA program using Java Native Access JNA)

m_gpib32.Send(BOARD_NR, MakeAdr(GPIB_Adr, 0), BBuffer, Msg.length(), EOT_MODE);
m_gpib32.Receive(BOARD_NR, MakeAdr(GPIB_Adr, 0), m_ReceiveBuffer, m_ReceiveBuffer.limit(), RECEIVE_TERMINATION)

caused the following output recorded with NI Spy:

Send(0, 0x0006, "*IDN?", 5 (0x5), NULLend (0x00))
   [Although I specified NLend as EOT_MODE, NULLend is used]
Receive(0, 0x0006, "", 150000 (0x249F0), 0x0) 
   [iberr=6 because the newline is missing and the instrument is not ready to send when addressed to talk]

The software handles this case and proceeds with a query of the temperature (on the instrument that did not cause an error) and NI Spy recorded:

Send(0, 0x0004, "KRDG? A", 7 (0x7), NULLend (0x00))
Receive(0, 0x0004, "LSCI,MODEL340...", 150000 (0x249F0), 0x0)
   [interestingly, the IDN is returned instead of the temperature !!]

When the same steps are repeated with 488.1 function calls

m_gpib32.ibwrt(m_UnitDescriptor, BBuffer, Msg.length());
m_gpib32.ibrd(m_UnitDescriptor, m_ReceiveBuffer, m_ReceiveBuffer.limit());

NI Spy records:

ibwrt(UD3, "*IDN?", 5 (0x5))
ibrd(UD3, "", 150000 (0x249F0)) [iberr=6 as expected]


ibwrt(UD2, "KRDG? A", 7 (0x7))
ibrd(UD2, "+227.746E+0..", 150000 (0x249F0))
   [now the actual temperature is returned as desired]

In my first guess I expected that calls into the dll from JAVA might be causing troubles, but because NI Spy is recording the GPIB traffic, I think it might be a bug in the gpib-32.dll.

Although I can use the 488.1 function calls to solve the problem, I would be interested in understanding what went wrong.

Any suggestions/thoughts why Receive() returns the IDN instead of the temperature are highly appreciated. It would also be interesting why the EOT_MODE is not not set as specified.

Thanks,

Kurt

[Efrain_G]

Hi Kurt,

As you probably already know, the NI 488.2 and NI 488.1 language interfaces are not compatible. The NI 488.2 driver had fundamental changes in terms of how it manages the registers for the data passed by the GPIB drivers. The NI 488.2 drivers were designed to be backwards compatible. However, you cannot use them to communicate with National Instruments 488.1 GPIB controllers. The 488.1 boards were only supported under DOS and cannot be used with current NI-488.2 driver software. Are you using any NI 488.1 GPIB controller?

You will find more information in the fowllowing KnowledgeBases:

NI-488.2 Language Interfaces Are Not Compatible with NI-488.1 Drivers

488.1 and 488.2 Compliant GPIB Boards

[Efrain_G]

Hi Kurt,

I am sorry, you can disregard my last post. For some reason I was assuming that you were using the NI 488.1 and NI 488.2 drivers on the same computer, but that is not possible obviously since NI 488.1 is not even compatible with any 32 bit version of Windows. To be honest with you, I am not sure why would there be a difference between using the Receive() and Send() commands in 488.2 and using ibwrt() and ibrd() in 488.1. I will see if I can reproduce this issue or find documentation that might explain this situation. I appreciate your patience.

[AngeloGomes]

Since 4 days ago I am with the same problem or at least similar problem. I am using VB and I have problems with a Signal Recovery 5209 lockin. I was using only 488.2 calls to send and receive data, but only this lockin does not work properly, while all other equipments do

Sometime it responds to a query, sometime it does not, sometimes it returns incorrect data.

 After reading this post, I think that the old equipment can be in trouble with 488.2 calls. I will try to rewrite the code for this lockin using 488.1 calls only.

[AngeloGomes]

Yeah. FINALLY...

Correct, for some reason I cannot mix wrt/rd/ibsp  with Send/Receive/ReadStatusByte commands, doing so causes the 5209 lockin to get lost with the GPIB BUS.

I just converted all Send/Receive/ReadStatusByte  calls to wrt/rd/ibsp call and eveything is fine now.

[Steven_T]

Hello All,

If anyone runs into problems like this, please include a .spy file from a spy capture.  The problem could be caused by one API changing the state of the GPIB or from an internal bug in the driver.  A spy capture will help us figure out the problem.

Thanks,

Steven T.

[AngeloGomes]

Hi Steven, I am attaching a capture1.spy which maybe is not (maybe it is...) the exact case as I told above because I already changed the code to use all ibwrt,ibrd commands (I will try to recover the old code and I will post the spy file as well).

Well the capture.spy file that I am attaching is for the following behavior I noticed just 3 minutes ago.

As I said, I converted the code to use only ibwrt and ibrd. I noticed that LR-700 (ac-resistence bridge) was not responding accordingly, the message received was "?SYNTAX" which means that it did not receive the correct string(it did not recognized the command sent), but I was completely sure the command sent was correct, I did run the code step by step. Then I open a MAX session and typed and sent the same command and the Bridge responded as expected. At this point I decided to open Ni SPY and check what was happening. I noticed that another thread in my code was trying to comunicate with other equipment which was not ON, after fixed this, actually I did isolate the code so only the thread for the AC bridge would be running, and run the Ac-bridge code again  and everything was fine since them. Then I concluded that something was messing the BUS, something that should not interfere with the AC-Bridge commands as the other equipment is not connected(turned on etc).

Notice from line 53 after I allowed the code for AC-bridge ro run only.

[Steven_T]

Hello,

The spy capture shows some really big problems...almost every line resulted in an error.  Please read the help regarding the ibrd and ibwrt functions.  You will notice that the first parameter is NOT the primary address of the instrument (as I think you are using it).  You should call ibdev (please check that function too).  The value that ibdev returns should be used as the first arguement in ibrd and ibwrt.

These errors need to be cleared up before we can expect reliable communication.

Thanks,

Steven T.

[AngeloGomes]

Hi Steven, I dont send the PAD to ibwrt and ibrd commands.

I am will paste below  some code:

1)The routine QueryGpib indeed receives the PAD address but it is only used to track which instrument is in trouble.

2) To confirm that the unique identifier is correct I just inserted an "ibdev" call in the code below, but now it was removed as in other routine for initialization I already had called ibdev and got the UdGpib for the equipment in PAD addrGPIB. 

Private Function QueryGPIB(ByVal addrGPIB As Integer, ByVal udGPIB As Integer, ByVal querycmd As String, ByVal LenghtStr As Integer, ByVal Id As Integer, ByRef ResultCode As Integer) As String

Dim attempt As Integer

Dim dev As Integer

Dim Cmd As String

Dim ValueStr  As String

Dim CmdErr As String

Dim ResponseCmd As String

Dim status As Integer

If (Right(querycmd, 2) <> vbCrLf) Then querycmd = querycmd + vbCrLf

Cmd = querycmd

attempt = 1

REPETE:

Call ibdev(0, AddrGPIB_LR700, 0, T3s, 1, 0, udGpib_LR700)  'This was inserted to track what was happen

Call ibwrt(udGPIB, Cmd)

If (ibsta And EERR) Then

    GoSub gpib_ErrHandler

    GoTo REPETE

End If

ResponseCmd = Space$(LenghtStr)

Call ibrd(udGPIB, ResponseCmd)

If (ibsta And EERR) Then

    GoSub gpib_ErrHandler

    GoTo REPETE

End If

ResultCode = 0

QueryGPIB = ResponseCmd

Exit Function

'

'

gpib_ErrHandler: 

    Windir = Environ$("windir") + "\"

    ValueStr = ReadDataIni(Windir + OptionStr + ".ini", "Install Path", "Path")

    PathSetup = ValueStr + "\config\"

    attempt = attempt + 1

    CmdErr = ThreadIdentification + " - Gpib_Err[Enter] Addr " + Format(addrGPIB, "00") + " - ID: " + Format(Id, "###0") + " STATUS= " + Format(ibsta, "#####0")

    Debug.Print CmdErr

    AsyncReport "DEVMEAS_Err", CmdErr

    dev = FreeFile

    Open PathSetup + "DEVMEAS.ERR" For Append As dev

        Print #dev, CmdErr

    Close dev

    If attempt = 5 Then

        ResultCode = 999

        Exit Function

    End If

    Call Send(addrGPIB, "SDC" + vbCrLf, status)

    Delay (1)

    Return

ErrHandler:

    ResultCode = 998

    CmdErr = "Error [Id:" + Format(Id, "###0") + ": " + Format(Err.Number, "#####0") + " Description: " + Err.Description

    Debug.Print CmdErr

    AsyncReport "DEVMEAS_Err", CmdErr

    dev = FreeFile

    Open PathSetup + "DEVMEAS.ERR" For Append As dev

        Print #dev, CmdErr

    Close dev

    Exit Function

End Function

[Kurt__]

Hi Steven,

thanks for looking into this.

Attached please find two .spy files for the case described initially.

In line 12 of 'Capture ibrd ibwrt.spy' the correct temperature is read, while in line 17 of 'Capture Send Receive.spy' the ID string is received instead of the temperature. I think it should be save to disregard the lines starting from line 18.

Please also note that in 'Capture Send Receive.spy' the EOTmode NULLend (0x00) is used despite the fact that I have passed DABend(0x02). Maybe something else to fix, although it's easy to fix in my program.

Thanks a lot,

Kurt