Error message on GPIB program, Help

On 12/15/2014 9:26 AM, amdx wrote:

I've lost the context of the thread. I'll throw out some issues that may or may not be relevant... Sometimes, tests that seem to verify performance are not conclusive because of some error in some configuration somewhere...

When you replaced the cmos, you did the hardware reset, followed by the cmos reset to default followed by any customizations you need?

Early port I/O required mapping of ports and interrupts. Later software did this automagically. Check for interrupt sharing issues.

I recall a lot of futzing around with the software. Did you get everything reloaded from a backup made BEFORE the cmos debacle? You need the right version of the NI software for your card and OS. Typically, you have to run the NI utility to find and configure all the gpib devices. All my experience is from my own code in visual basic. Have no idea how "other" programs handle the mapping to the GPIB hardware. I've never tried to control more than one instrument at a time from the same program, but I have run multiple instances of the program pointed at different hardware on the same bus.

Depending on your OS, you may not have access to some required ports. Something like giveIO or userportXP may be required to allow port access from older software that expects free reign on the ports. Remember what I said above, errors in configuration can make one thing work while another may not, even though you think the commands are exactly the same. Seemingly equivalent top level commands may take different low level paths.

Some software may need to run in compatibility mode.

The commands executed thru the diagnostic interface may not use the same paths as the real software.

Surely you googled the ENOL error. Two minutes of that suggests that there is no active listener. Another google minute suggests that there are issues when the gpib address is over 15. Many more google minutes left to examine. Remember that one diagnostic path may not be conclusive proof that another path will work.

Early gpib required binary commands. 488.2 allows ascii commands in plain language. One thing that can get you is the end of line sequence. Depending...you can modify the behavior via switch on the device setting in the device menu setting in the driver menu setting in the software menu hard coded in the software that depends on other stuff being correctly configured

If the EOL sequences don't match, confusion ensues.

Setting for talk only has been discussed.

IIRC, there's a bus reset command that can give you a stable starting point for each test command.

If it were me, I'd stick a logic analyzer on the GPIB port and see what is actually happening.

This is one version of a VB6 class module that uses the NI driver. Has some listing of error messages and other comments that might give you some clues. It has the inpout32 port access declarations and the code that removes the linefeed (EOL) character. I did not write most of it.

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Option Explicit 'National Instruments PCIIA GPIB interface Also works with TNT cards 'Using national drivers 'keep them in sync 'Function Declares 'Inp and Out declarations for direct port I/O 'in 32-bit Visual Basic 4 programs. Private Declare Function Inp Lib "inpout32.dll" _ Alias "Inp32" (ByVal PortAddress As Integer) As Integer Private Declare Sub Out Lib "inpout32.dll" _ Alias "Out32" (ByVal PortAddress As Integer, ByVal value As Integer) Private Declare Sub Sleep Lib "kernel32" (ByVal dwMilliseconds As Long)

'my variable declarations Dim Dev As Integer Dim wrtbuf As String Dim rdbuf As String

Dim abase As Integer, instadr As Integer, stadr As Integer, ladr As Integer, Unlall As Integer, Untall As Integer, intst0 As Integer, intst1 As Integer Dim addstat As Integer, bustat As Integer, cpass As Integer, datain As Integer, imask0 As Integer, imask1 As Integer, auxcmdr As Integer, st0byt As Integer, st1byt As Integer Dim address As Integer, serpoll As Integer, parpoll As Integer, dataout As Integer, sswrst As Integer, cswrst As Integer, ssic As Integer, csic As Integer, ssre As Integer, csre As Integer, feoi As Integer, sget As Integer, cget As Integer Dim tcs As Integer, gts As Integer ', UNL As Integer, ton As Integer, toff As Integer, lon As Integer, loff As Integer, tca As Integer, SDC As Integer, DCL As Integer, aGet As Integer, GTL As Integer Private Function AddIbcnt() As String AddIbcnt = Chr$(13) + Chr$(10) + "ibcnt = 0x" + Hex$(ibcnt) End Function

Private Function AddIberr() As String If (ibsta And EERR) Then If (iberr = EDVR) Then AddIberr = Chr$(13) + Chr$(10) + "iberr = EDVR " If (iberr = ECIC) Then AddIberr = Chr$(13) + Chr$(10) + "iberr = ECIC " If (iberr = ENOL) Then AddIberr = Chr$(13) + Chr$(10) + "iberr = ENOL " If (iberr = EADR) Then AddIberr = Chr$(13) + Chr$(10) + "iberr = EADR " If (iberr = EARG) Then AddIberr = Chr$(13) + Chr$(10) + "iberr = EARG " If (iberr = ESAC) Then AddIberr = Chr$(13) + Chr$(10) + "iberr = ESAC " If (iberr = EABO) Then AddIberr = Chr$(13) + Chr$(10) + "iberr = EABO " If (iberr = ENEB) Then AddIberr = Chr$(13) + Chr$(10) + "iberr = ENEB " If (iberr = EOIP) Then AddIberr = Chr$(13) + Chr$(10) + "iberr = EOIP " If (iberr = ECAP) Then AddIberr = Chr$(13) + Chr$(10) + "iberr = ECAP " If (iberr = EFSO) Then AddIberr = Chr$(13) + Chr$(10) + "iberr = EFSO " If (iberr = EBUS) Then AddIberr = Chr$(13) + Chr$(10) + "iberr = EBUS " If (iberr = ESTB) Then AddIberr = Chr$(13) + Chr$(10) + "iberr = ESTB " If (iberr = ESRQ) Then AddIberr = Chr$(13) + Chr$(10) + "iberr = ESRQ " If (iberr = ETAB) Then AddIberr = Chr$(13) + Chr$(10) + "iberr = ETAB " Else AddIberr = Chr$(13) + Chr$(10) + "iberr = " + str$(iberr) End If End Function

Private Function AddIbsta() As String Dim sta As String sta = Chr$(13) + Chr$(10) + "ibsta = &H" + Hex$(ibsta) + " " AddIbsta = sta End Function

' ' Clear the list of readings in the test window '

Private Sub GpibErr(msg$) msg$ = msg$ + AddIbsta() + AddIberr() + AddIbcnt() + Chr$(13) + Chr$(13) + "I'm quitting!" MsgBox msg$, vbOKOnly + vbExclamation, "Error"

' Take the device offline.

ilonl Dev, 0

End End Sub

Private Sub getoffthebus() ' Take the device offline.

ilonl Dev, 0

End Sub Property Get datastring() As String

' Read the identification code by calling ilrd. If the ERR bit is set in ' ibsta, call GpibErr with an error message.

rdbuf = Space$(100) ilrd Dev, rdbuf, Len(rdbuf) If (ibsta And EERR) Then GpibErr ("Error reading from device.") End If

' The device returns a Line Feed character with the identification ' string. You could use the LEFT$() function which returns a ' specified number of characters from the left side of a string to ' remove the Line Feed character. The code fragment below illustrates ' how to use the LEFT$() function along with the GPIB global count ' variable, ibcntl, to copy the contents of rdbuf into a new string ' called DisplayStr. Note, that you need one less character than the ' total number contained in ibcntl.

datastring = Left$(rdbuf, ibcntl - 1) Debug.Print "Got String ", datastring 'ilonl Dev, 0 ' If (ibsta And EERR) Then ' GpibErr ("Error putting device offline.") ' End If

End Property

Sub chekstat() Exit Sub Dim st0 As Integer, st1 As Integer, adstat As Integer st1 = Inp(intst1) st0 = Inp(intst0) adstat = Inp(addstat) End Sub

Property Get databyte() As Integer Dim k As Integer k = MsgBox("shouldn't get to getdatabyte", vbOKOnly) End Property

Property Let datastring(strn As String) 'send a string to the device Debug.Print "sending string "; strn wrtbuf = strn ilwrt Dev, wrtbuf, Len(wrtbuf) If (ibsta And EERR) Then GpibErr ("Error writing to device.") End If

End Property

Public Property Let instaddress(instadr As Integer)

Const BDINDEX = 0 ' Board Index 'PRIMARY_ADDR_OF_DEV = 4 ' Primary address of device in Const NO_SECONDARY_ADDR = 0 ' Secondary address of device Const TIMEOUT = T10s ' Timeout value = 10 seconds Const EOTMODE = 1 ' Enable the END message Const EOSMODE = 0 ' Disable the EOS mode

Dev = ildev(BDINDEX, instadr, _ NO_SECONDARY_ADDR, TIMEOUT, EOTMODE, EOSMODE) If (ibsta And EERR) Then GpibErr ("Error opening device.") End If

' Clear the internal or device functions of the device. If the error bit ' EERR is set in ibsta, call GpibErr with an error message.

ilclr Dev If (ibsta And EERR) Then GpibErr ("Error clearing device.") End If

End Property Private Sub Class_Initialize() Debug.Print "Using National PCIIA Drivers"

End Sub

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

There will also be manual switch(es) on the back panel that set the device address and other properties (secondary addressing etc).

OK. Go back to that configuration and see if it still works now.

I have lost track of which device is actually causing trouble. The indicator lamp that doesn't come on may just have failed.

Pity since adding diagnostics to the program would help a lot.

OK. So find some simple commands to send to it (the 3330) by hand and see if you can make it respond correctly to them. Particularly sending get reading and then reading back data. Likely sources of trouble are strings terminated bv CRLF vs CR expected or vice versa.

I thought you said it had lain unused for more than a decade.

I'll try to make a long story short. System sat unpowered 8 years, then I moved it and set it up. The computer gave me a Low Cmos battery message. So, i pulled the HD and put it in a newer computer along with the NI GPIB pcb. After a few attempts to make it work and conversations, I found this was not the way to make it work. Then I received the CMOS battery (snipped story) when I installed it the computer started working properly. I reinstalled the NI GPIB pcb and plugged in all the cables and hooked up the probes, sense resistor and the cable for the drive voltage. I ran the private software "Frequency Sweep" and I got data output, garbage, but still data. It worked as it should, however, I had the drive voltage connected to a "dead" (Not connected internally) output on the HP3330B. A little checking and I found the Drive Voltage comes out a rear connector on the HP3330B and into the 3570A then out the front panel output connector. So I repositioned the Drive voltage cable. At this point the unit should have worked. It didn't, the frequency was set on the HP3330B but I "think" the first data point didn't get to the HP3570A and the error message appeared. "Error while interpreting the response from the 3570. Type mismatch" Now, it doesn't even set the frequency, it just waits a few seconds then gives the error message.

The only things in the bios was set the date and something with the HD.

If only I knew how to check for interrupt sharing issues.

Almost all of that was when I put the HD into the other computer. I did uninstall any thing I installed.

There was no backup. I assumed that what ever was on the HD before I changed the Battery, is still there. Am I wrong?

You need the right version of the NI software for

This all worked together at sometime. FWIW, the computer has no internet connection to ad havoc.

I note this is running Windows 95, I said 98 elsewhere.

I did, and then spent a day switching cables checking for different errors for different connections, using and ohmmeter to check connections. Cables seem fine. Some of the other suggestion are things I don't know about.

I'll stop responding for a bit and get back to the unit. Thanks, Mikek

I may have found something in the manual the pertains.

"After the National Instruments software has been installed, the PCI_GPIB interface card must be installed into an open PCI slot of the computer. [This card requires a PCI interrupt.] Depending on the computer, a BIOS configuration may be necessary to make an interrupt available to the card (this often involves allocating an interrupt to Auto/PCI/PnP or similar). When the computer is next booted, Microsoft Windows will automatically detect the card and install the drivers. This should not require user intervention because the National Instruments driver has already been installed.

Since I lost the BIOS when the battery died, Maybe I need to make an interrupt available to the card.

Is this possible? And how do I go about that?

Thanks, Mikek

Press one of F!, F2, F8, F10 or Del during boot and pray.

Chances are one of those will let you into the BIOS. But if the GPIB card is talking to anything at all then the card must be either operating in polling mode or already have claimed its interrupt.

The sort of problem you describe sounds more like a mismatch between what data the PC software expects to see and what the HP deigns to send.

An HPIB bus analyser (or a generic analyser) would go a long way to allowing you to see who says what to who and what responses occur. This might be your path of least resistance if you can't alter the software.

Can't tell from your response. I'm telling you that I have experienced BIOS setup corruption that caused unexplainable errors that seemed to have been fixed by entering cmos setup and actually entering the keystrokes labeled something like, "restore defaults", rebooting, then changing anything required by my setup. There was no obvious change to the CMOS setup screens, but the system seemed to behave after that. YMMV

It's been over a decade since I've used win95, but I'd start looking in device manager. in win7 it's in the view tab under resources by type.

I'm not suggesting that there's a high probability of your problem being caused by any of the suggestions I've made. But you seem to have exhausted the high probability possible causes.

Don't ever do that again. When the computer boots it attempts to react to any hardware changes it sees. Linux does pretty well at that. I accuse MS of actively screwing up your configuration in the name of copy protection. I wouldn't trust anything after you move the disk to a new computer, boot it, then back to the original. May be ok. I wouldn't trust it if it isn't working.

I think that's true. What's wrong is moving the disk to a different machine and expecting the configuration to be unchanged. I would never, ever, move a windows disk to a different machine without first doing an image backup of it.

Yes, before you booted the disk in a different machine.

When I installed the National Instruments software, I got an icon for "national instruments measurement & automation explorer". In the configuration column on the left, there's an entry for NI Spy It claims to log API calls that should tell you what is being sent over the bus. I don't recall ever using it. Worth a shot.

It turns out the way into BIOS is the insert key! I found a discussion from 2000 that someone posted after a hair pulling search.

The PCI slots are all in auto mode.

Mikek

Someone mentioned NI Spy, so I pulled that up and it list the commands/addresses when I try to run my program.

I made a screen shot of the info, the first 5 lines write when I open my software, the rest write when I try to run a scan using the software.

I have no convenient method to copy and paste from one computer to this one, so a real screenshot.

Is there anything helpful in this data?

Thanks, Mikek

Here's another screen shot that includes the command with the data back from NI Spy.

First input is ibdev 0 4 0 11 0 0 then 3 more.

Thanks, Mikek

Yes. Although I am forced to guess at NI's error codes I would venture that it is complaining about UD1 with a red ENOL(2) rather than 0.

At a guess I'd venture Error No Listener.

IOW there is no recognisable device sat at address 15 on the GPIB.

OK, what is a UD0 vs UD1. I'm thinking it is my software that is calling up the UD1, but it doesn't seem right that it would. Mikek

One *possible* problem: on most machines, there are only a limited number of interrupts available to PCI slots. The BIOS may very well be mapping the PCI slot to an interrupt number which is being shared with other PCI slots or with on-board peripherals.

Normally, with good PCI devices and a good o/s and well-written drivers, this shouldn't be a problem. PCI devices should have their own status registers which indicate whether they're generating an interrupt, and each device driver for a device sharing an interrupt will be given a chance to check its status.

However, there are some bad PCI cards, and bad operating systems, and bad drivers, and any of these can result in lost or spurious interrupts or in delay in processing interrupts.

If you boot up Linux (from e.g. a Knoppix live CD) you can log in and then see what interrupts are actually assigned to (or shared by) which devices... "cat /proc/interrupts". This only works for devices that have drivers installed, though.

There's probably a similar capability available under Windows (e.g. the Hardware tab under the System control panel).

You *might* find it beneficial to do manual assignment of your PCI interrupts, to try to give the GPIB card an interrupt of its own. There's no certainty that you can achieve this with your motherboard and BIOS, and no guarantee at all that it would help.

I am guessing at NI's notation here but UD = User Device

UD0 is the handle of the first device you declared and UD1 is the handle of the second

You should be able to figure out which is which from the command syntax since one will be the signal gen and the other a DVM or something.

Check the manuals and dip switches on the two HP devices and see if you can't find a noddy test program in the NI distribution that lets you send strings to a device number and watch what comes back. That is likely to be the fastest way to figure out what is going wrong.