On 12/15/2014 7:41 AM, Martin Brown wrote:> On 12/12/2014 16:13, amdx wrote: >> On 12/11/2014 9:30 PM, John Miles, KE5FX wrote: >>> On Thursday, December 11, 2014 5:18:19 PM UTC-8, amdx wrote: >>>> So Far So Good. The next commands test the HP3570A >>>> >>>> Type ibdev 0 15 0 11 0 0 (enter) >>>> This presents the ud0 : prompt >>>> ibwrt "%" should TURN ON the Amplitude Offset light >>>> It Does Not. >>>> It returns [8100] (err cmpl) >>>> error : ENOL >>>> count : 0 >>>> >>> >>> Make sure your 3570A is really at address 15, and that it isn't set to >>> talk-only or some other mode that keeps it from being addressed by the >>> host. >>> >>> If its remote light never comes on, one of those is the likely reason. >>> >>> -- john, KE5FX >>> >> Ok, as posted, >> I have went through a section in the manual, >> "Verifying Communication" >> ibdev 0 4 0 11 0 0 >> Turns on the Remote lights both machines >> and it presents with a ud0 : Prompt >> Entering; ibwrt "L12.3=" causes the display on the 3330B to read 12.3 Hz >> Entering 'exit' causes the remote lights to turnoff. >> >> So the remote light on the 3570A does operate. (I verified) >> It looks like the Amplitude Offset light does not get the note to turn >> on. >> Regarding the address 15 and talk only, I have no clue how to check >> that. I do note the manual states the default address is 1, programers >> are making it 15, >> so I tried typing ibdev 0 1 0 11 0 0 and hitting enter, but that didn't >> work either. >> Thanks for looking at this, Mikek > > GPIB is a (slow by todays standards) parallel data bus so the most > likely cause of lost functionality is either one of the units is dead or > that a bit of swarf has made its way between adjacent data lines.The odd part the program operated one time, But I didn't have any drive voltage, (misplaced cable). After that it would set the start frequency on the 3330 and then gave the mismatch from the 3570.> > Looking through the code for the offending error message and changing it > to print out the command sent and the response would be one way to > proceed.Don't have a clue how to do that. Or manually doing the actions of the program until first> failure assuming that you can't step it line by line in an interpreter. > > Are there any commands you can send to the 3570A that it recognises? >Only two that I have tried, Amplitude Offset light turn on and remote light turn on. The both work. It is the 3330 that seems not to respond.> IEEE488.2 is a slightly later dialect of classic GPIB so it is possible > that older units do not speak it, but if you had a programme that > previously worked with these units then the chances are that some manual > override setting is wrong for automated slave operation. >The unit function well up to the Cmos battery replacement and the move. It seemed to make one scan with data, and then stopped working. Mikek --- This email has been checked for viruses by Avast antivirus software. http://www.avast.com
Error message on GPIB program, Help
Started by ●December 11, 2014
Reply by ●December 15, 20142014-12-15
Reply by ●December 15, 20142014-12-15
On 12/15/2014 9:26 AM, amdx wrote:> On 12/15/2014 7:41 AM, Martin Brown wrote: >> On 12/12/2014 16:13, amdx wrote: >>> On 12/11/2014 9:30 PM, John Miles, KE5FX wrote: >>>> On Thursday, December 11, 2014 5:18:19 PM UTC-8, amdx wrote: >>>>> So Far So Good. The next commands test the HP3570A >>>>> >>>>> Type ibdev 0 15 0 11 0 0 (enter) >>>>> This presents the ud0 : prompt >>>>> ibwrt "%" should TURN ON the Amplitude Offset light >>>>> It Does Not. >>>>> It returns [8100] (err cmpl) >>>>> error : ENOL >>>>> count : 0 >>>>> >>>> >>>> Make sure your 3570A is really at address 15, and that it isn't set to >>>> talk-only or some other mode that keeps it from being addressed by the >>>> host. >>>> >>>> If its remote light never comes on, one of those is the likely reason. >>>> >>>> -- john, KE5FX >>>> >>> Ok, as posted, >>> I have went through a section in the manual, >>> "Verifying Communication" >>> ibdev 0 4 0 11 0 0 >>> Turns on the Remote lights both machines >>> and it presents with a ud0 : Prompt >>> Entering; ibwrt "L12.3=" causes the display on the 3330B to read 12.3 Hz >>> Entering 'exit' causes the remote lights to turnoff. >>> >>> So the remote light on the 3570A does operate. (I verified) >>> It looks like the Amplitude Offset light does not get the note to turn >>> on. >>> Regarding the address 15 and talk only, I have no clue how to check >>> that. I do note the manual states the default address is 1, programers >>> are making it 15, >>> so I tried typing ibdev 0 1 0 11 0 0 and hitting enter, but that didn't >>> work either. >>> Thanks for looking at this, Mikek >> >> GPIB is a (slow by todays standards) parallel data bus so the most >> likely cause of lost functionality is either one of the units is dead or >> that a bit of swarf has made its way between adjacent data lines. > > The odd part the program operated one time, But I didn't have any > drive voltage, (misplaced cable). > After that it would set the start frequency on the 3330 and then gave > the mismatch from the 3570. > >> >> Looking through the code for the offending error message and changing it >> to print out the command sent and the response would be one way to >> proceed. > > Don't have a clue how to do that. > > Or manually doing the actions of the program until first >> failure assuming that you can't step it line by line in an interpreter. >> >> Are there any commands you can send to the 3570A that it recognises? >> > Only two that I have tried, Amplitude Offset light turn on and remote > light turn on. The both work. > It is the 3330 that seems not to respond. > >> IEEE488.2 is a slightly later dialect of classic GPIB so it is possible >> that older units do not speak it, but if you had a programme that >> previously worked with these units then the chances are that some manual >> override setting is wrong for automated slave operation. >> > The unit function well up to the Cmos battery replacement and the move. > It seemed to make one scan with data, and then stopped working. > Mikek > > > --- > This email has been checked for viruses by Avast antivirus software. > http://www.avast.com >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 <DOS Error>" If (iberr = ECIC) Then AddIberr = Chr$(13) + Chr$(10) + "iberr = ECIC <Not CIC>" If (iberr = ENOL) Then AddIberr = Chr$(13) + Chr$(10) + "iberr = ENOL <No Listener>" If (iberr = EADR) Then AddIberr = Chr$(13) + Chr$(10) + "iberr = EADR <Address Error>" If (iberr = EARG) Then AddIberr = Chr$(13) + Chr$(10) + "iberr = EARG <Invalid argument>" If (iberr = ESAC) Then AddIberr = Chr$(13) + Chr$(10) + "iberr = ESAC <Not Sys Ctrlr>" If (iberr = EABO) Then AddIberr = Chr$(13) + Chr$(10) + "iberr = EABO <Op. aborted>" If (iberr = ENEB) Then AddIberr = Chr$(13) + Chr$(10) + "iberr = ENEB <No GPIB board>" If (iberr = EOIP) Then AddIberr = Chr$(13) + Chr$(10) + "iberr = EOIP <Async I/O in prg>" If (iberr = ECAP) Then AddIberr = Chr$(13) + Chr$(10) + "iberr = ECAP <No capability>" If (iberr = EFSO) Then AddIberr = Chr$(13) + Chr$(10) + "iberr = EFSO <File sys. error>" If (iberr = EBUS) Then AddIberr = Chr$(13) + Chr$(10) + "iberr = EBUS <Command error>" If (iberr = ESTB) Then AddIberr = Chr$(13) + Chr$(10) + "iberr = ESTB <Status byte lost>" If (iberr = ESRQ) Then AddIberr = Chr$(13) + Chr$(10) + "iberr = ESRQ <SRQ stuck high>" If (iberr = ETAB) Then AddIberr = Chr$(13) + Chr$(10) + "iberr = ETAB <Table overflow>" 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) + " <" If (ibsta And EERR) Then sta$ = sta$ + " ERR" If (ibsta And TIMO) Then sta$ = sta$ + " TIMO" If (ibsta And EEND) Then sta$ = sta$ + " END" If (ibsta And SRQI) Then sta$ = sta$ + " SRQI" If (ibsta And RQS) Then sta$ = sta$ + " RQS" If (ibsta And CMPL) Then sta$ = sta$ + " CMPL" If (ibsta And LOK) Then sta$ = sta$ + " LOK" If (ibsta And RREM) Then sta$ = sta$ + " REM" If (ibsta And CIC) Then sta$ = sta$ + " CIC" If (ibsta And AATN) Then sta$ = sta$ + " ATN" If (ibsta And TACS) Then sta$ = sta$ + " TACS" If (ibsta And LACS) Then sta$ = sta$ + " LACS" If (ibsta And DTAS) Then sta$ = sta$ + " DTAS" If (ibsta And DCAS) Then sta$ = sta$ + " DCAS" sta$ = sta$ + ">" 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 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Reply by ●December 15, 20142014-12-15
On 15/12/2014 17:26, amdx wrote:> On 12/15/2014 7:41 AM, Martin Brown wrote: >> On 12/12/2014 16:13, amdx wrote: >>> On 12/11/2014 9:30 PM, John Miles, KE5FX wrote: >>>> On Thursday, December 11, 2014 5:18:19 PM UTC-8, amdx wrote: >>>>> So Far So Good. The next commands test the HP3570A >>>>> >>>>> Type ibdev 0 15 0 11 0 0 (enter) >>>>> This presents the ud0 : prompt >>>>> ibwrt "%" should TURN ON the Amplitude Offset light >>>>> It Does Not. >>>>> It returns [8100] (err cmpl) >>>>> error : ENOL >>>>> count : 0 >>>>> >>>> >>>> Make sure your 3570A is really at address 15, and that it isn't set to >>>> talk-only or some other mode that keeps it from being addressed by the >>>> host. >>>> >>>> If its remote light never comes on, one of those is the likely reason. >>>> >>>> -- john, KE5FX >>>> >>> Ok, as posted, >>> I have went through a section in the manual, >>> "Verifying Communication" >>> ibdev 0 4 0 11 0 0 >>> Turns on the Remote lights both machines >>> and it presents with a ud0 : Prompt >>> Entering; ibwrt "L12.3=" causes the display on the 3330B to read 12.3 Hz >>> Entering 'exit' causes the remote lights to turnoff. >>> >>> So the remote light on the 3570A does operate. (I verified) >>> It looks like the Amplitude Offset light does not get the note to turn >>> on. >>> Regarding the address 15 and talk only, I have no clue how to check >>> that. I do note the manual states the default address is 1, programers >>> are making it 15,There will also be manual switch(es) on the back panel that set the device address and other properties (secondary addressing etc).>>> so I tried typing ibdev 0 1 0 11 0 0 and hitting enter, but that didn't >>> work either. >>> Thanks for looking at this, Mikek >> >> GPIB is a (slow by todays standards) parallel data bus so the most >> likely cause of lost functionality is either one of the units is dead or >> that a bit of swarf has made its way between adjacent data lines. > > The odd part the program operated one time, But I didn't have any > drive voltage, (misplaced cable).OK. Go back to that configuration and see if it still works now.> After that it would set the start frequency on the 3330 and then gave > the mismatch from the 3570.I have lost track of which device is actually causing trouble. The indicator lamp that doesn't come on may just have failed.>> Looking through the code for the offending error message and changing it >> to print out the command sent and the response would be one way to >> proceed. > > Don't have a clue how to do that.Pity since adding diagnostics to the program would help a lot.> > Or manually doing the actions of the program until first >> failure assuming that you can't step it line by line in an interpreter. >> >> Are there any commands you can send to the 3570A that it recognises? >> > Only two that I have tried, Amplitude Offset light turn on and remote > light turn on. The both work. > It is the 3330 that seems not to respond.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.> >> IEEE488.2 is a slightly later dialect of classic GPIB so it is possible >> that older units do not speak it, but if you had a programme that >> previously worked with these units then the chances are that some manual >> override setting is wrong for automated slave operation. >> > The unit function well up to the Cmos battery replacement and the move. > It seemed to make one scan with data, and then stopped working. > MikekI thought you said it had lain unused for more than a decade. -- Regards, Martin Brown
Reply by ●December 15, 20142014-12-15
On 12/15/2014 4:33 PM, mike wrote:> On 12/15/2014 9:26 AM, amdx wrote: >> On 12/15/2014 7:41 AM, Martin Brown wrote: >>> On 12/12/2014 16:13, amdx wrote: >>>> On 12/11/2014 9:30 PM, John Miles, KE5FX wrote: >>>>> On Thursday, December 11, 2014 5:18:19 PM UTC-8, amdx wrote: >>>>>> So Far So Good. The next commands test the HP3570A >>>>>> >>>>>> Type ibdev 0 15 0 11 0 0 (enter) >>>>>> This presents the ud0 : prompt >>>>>> ibwrt "%" should TURN ON the Amplitude Offset light >>>>>> It Does Not. >>>>>> It returns [8100] (err cmpl) >>>>>> error : ENOL >>>>>> count : 0 >>>>>> >>>>> >>>>> Make sure your 3570A is really at address 15, and that it isn't set to >>>>> talk-only or some other mode that keeps it from being addressed by the >>>>> host. >>>>> >>>>> If its remote light never comes on, one of those is the likely reason. >>>>> >>>>> -- john, KE5FX >>>>> >>>> Ok, as posted, >>>> I have went through a section in the manual, >>>> "Verifying Communication" >>>> ibdev 0 4 0 11 0 0 >>>> Turns on the Remote lights both machines >>>> and it presents with a ud0 : Prompt >>>> Entering; ibwrt "L12.3=" causes the display on the 3330B to read >>>> 12.3 Hz >>>> Entering 'exit' causes the remote lights to turnoff. >>>> >>>> So the remote light on the 3570A does operate. (I verified) >>>> It looks like the Amplitude Offset light does not get the note to turn >>>> on. >>>> Regarding the address 15 and talk only, I have no clue how to check >>>> that. I do note the manual states the default address is 1, programers >>>> are making it 15, >>>> so I tried typing ibdev 0 1 0 11 0 0 and hitting enter, but that >>>> didn't >>>> work either. >>>> Thanks for looking at this, Mikek >>> >>> GPIB is a (slow by todays standards) parallel data bus so the most >>> likely cause of lost functionality is either one of the units is dead or >>> that a bit of swarf has made its way between adjacent data lines. >> >> The odd part the program operated one time, But I didn't have any >> drive voltage, (misplaced cable). >> After that it would set the start frequency on the 3330 and then gave >> the mismatch from the 3570. >> >>> >>> Looking through the code for the offending error message and changing it >>> to print out the command sent and the response would be one way to >>> proceed. >> >> Don't have a clue how to do that. >> >> Or manually doing the actions of the program until first >>> failure assuming that you can't step it line by line in an interpreter. >>> >>> Are there any commands you can send to the 3570A that it recognises? >>> >> Only two that I have tried, Amplitude Offset light turn on and remote >> light turn on. The both work. >> It is the 3330 that seems not to respond. >> >>> IEEE488.2 is a slightly later dialect of classic GPIB so it is possible >>> that older units do not speak it, but if you had a programme that >>> previously worked with these units then the chances are that some manual >>> override setting is wrong for automated slave operation. >>> >> The unit function well up to the Cmos battery replacement and the move. >> It seemed to make one scan with data, and then stopped working. >> Mikek >> >> >> --- >> This email has been checked for viruses by Avast antivirus software. >> http://www.avast.com >> > 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...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.> > When you replaced the cmos, you did the hardware reset, > followed by the cmos reset to default followed by any > customizations you need? >The only things in the bios was set the date and something with the HD.> Early port I/O required mapping of ports and interrupts. > Later software did this automagically. Check for interrupt > sharing issues. >If only I knew how to check for interrupt sharing issues.> I recall a lot of futzing around with the software.Almost all of that was when I put the HD into the other computer. I did uninstall any thing I installed.> Did you > get everything reloaded from a backup made BEFORE the cmos > debacle?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> your card and OS. Typically, you have to run the NI utility > to find and configure all the gpib devices.This all worked together at sometime. FWIW, the computer has no internet connection to ad havoc.> 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.I note this is running Windows 95, I said 98 elsewhere.> 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.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.> 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. >I'll stop responding for a bit and get back to the unit. Thanks, Mikek> 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 <DOS Error>" > If (iberr = ECIC) Then AddIberr = Chr$(13) + Chr$(10) + "iberr > = ECIC <Not CIC>" > If (iberr = ENOL) Then AddIberr = Chr$(13) + Chr$(10) + "iberr > = ENOL <No Listener>" > If (iberr = EADR) Then AddIberr = Chr$(13) + Chr$(10) + "iberr > = EADR <Address Error>" > If (iberr = EARG) Then AddIberr = Chr$(13) + Chr$(10) + "iberr > = EARG <Invalid argument>" > If (iberr = ESAC) Then AddIberr = Chr$(13) + Chr$(10) + "iberr > = ESAC <Not Sys Ctrlr>" > If (iberr = EABO) Then AddIberr = Chr$(13) + Chr$(10) + "iberr > = EABO <Op. aborted>" > If (iberr = ENEB) Then AddIberr = Chr$(13) + Chr$(10) + "iberr > = ENEB <No GPIB board>" > If (iberr = EOIP) Then AddIberr = Chr$(13) + Chr$(10) + "iberr > = EOIP <Async I/O in prg>" > If (iberr = ECAP) Then AddIberr = Chr$(13) + Chr$(10) + "iberr > = ECAP <No capability>" > If (iberr = EFSO) Then AddIberr = Chr$(13) + Chr$(10) + "iberr > = EFSO <File sys. error>" > If (iberr = EBUS) Then AddIberr = Chr$(13) + Chr$(10) + "iberr > = EBUS <Command error>" > If (iberr = ESTB) Then AddIberr = Chr$(13) + Chr$(10) + "iberr > = ESTB <Status byte lost>" > If (iberr = ESRQ) Then AddIberr = Chr$(13) + Chr$(10) + "iberr > = ESRQ <SRQ stuck high>" > If (iberr = ETAB) Then AddIberr = Chr$(13) + Chr$(10) + "iberr > = ETAB <Table overflow>" > 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) + " <" > If (ibsta And EERR) Then sta$ = sta$ + " ERR" > If (ibsta And TIMO) Then sta$ = sta$ + " TIMO" > If (ibsta And EEND) Then sta$ = sta$ + " END" > If (ibsta And SRQI) Then sta$ = sta$ + " SRQI" > If (ibsta And RQS) Then sta$ = sta$ + " RQS" > If (ibsta And CMPL) Then sta$ = sta$ + " CMPL" > If (ibsta And LOK) Then sta$ = sta$ + " LOK" > If (ibsta And RREM) Then sta$ = sta$ + " REM" > If (ibsta And CIC) Then sta$ = sta$ + " CIC" > If (ibsta And AATN) Then sta$ = sta$ + " ATN" > If (ibsta And TACS) Then sta$ = sta$ + " TACS" > If (ibsta And LACS) Then sta$ = sta$ + " LACS" > If (ibsta And DTAS) Then sta$ = sta$ + " DTAS" > If (ibsta And DCAS) Then sta$ = sta$ + " DCAS" > sta$ = sta$ + ">" > 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 > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > >
Reply by ●December 15, 20142014-12-15
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
Reply by ●December 16, 20142014-12-16
On 16/12/2014 02:04, amdx wrote:> > > 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?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. -- Regards, Martin Brown
Reply by ●December 16, 20142014-12-16
On 12/15/2014 4:52 PM, amdx wrote:> On 12/15/2014 4:33 PM, mike wrote: >> On 12/15/2014 9:26 AM, amdx wrote: >>> On 12/15/2014 7:41 AM, Martin Brown wrote: >>>> On 12/12/2014 16:13, amdx wrote: >>>>> On 12/11/2014 9:30 PM, John Miles, KE5FX wrote: >>>>>> On Thursday, December 11, 2014 5:18:19 PM UTC-8, amdx wrote: >>>>>>> So Far So Good. The next commands test the HP3570A >>>>>>> >>>>>>> Type ibdev 0 15 0 11 0 0 (enter) >>>>>>> This presents the ud0 : prompt >>>>>>> ibwrt "%" should TURN ON the Amplitude Offset light >>>>>>> It Does Not. >>>>>>> It returns [8100] (err cmpl) >>>>>>> error : ENOL >>>>>>> count : 0 >>>>>>> >>>>>> >>>>>> Make sure your 3570A is really at address 15, and that it isn't >>>>>> set to >>>>>> talk-only or some other mode that keeps it from being addressed by >>>>>> the >>>>>> host. >>>>>> >>>>>> If its remote light never comes on, one of those is the likely >>>>>> reason. >>>>>> >>>>>> -- john, KE5FX >>>>>> >>>>> Ok, as posted, >>>>> I have went through a section in the manual, >>>>> "Verifying Communication" >>>>> ibdev 0 4 0 11 0 0 >>>>> Turns on the Remote lights both machines >>>>> and it presents with a ud0 : Prompt >>>>> Entering; ibwrt "L12.3=" causes the display on the 3330B to read >>>>> 12.3 Hz >>>>> Entering 'exit' causes the remote lights to turnoff. >>>>> >>>>> So the remote light on the 3570A does operate. (I verified) >>>>> It looks like the Amplitude Offset light does not get the note to turn >>>>> on. >>>>> Regarding the address 15 and talk only, I have no clue how to check >>>>> that. I do note the manual states the default address is 1, programers >>>>> are making it 15, >>>>> so I tried typing ibdev 0 1 0 11 0 0 and hitting enter, but that >>>>> didn't >>>>> work either. >>>>> Thanks for looking at this, Mikek >>>> >>>> GPIB is a (slow by todays standards) parallel data bus so the most >>>> likely cause of lost functionality is either one of the units is >>>> dead or >>>> that a bit of swarf has made its way between adjacent data lines. >>> >>> The odd part the program operated one time, But I didn't have any >>> drive voltage, (misplaced cable). >>> After that it would set the start frequency on the 3330 and then gave >>> the mismatch from the 3570. >>> >>>> >>>> Looking through the code for the offending error message and >>>> changing it >>>> to print out the command sent and the response would be one way to >>>> proceed. >>> >>> Don't have a clue how to do that. >>> >>> Or manually doing the actions of the program until first >>>> failure assuming that you can't step it line by line in an interpreter. >>>> >>>> Are there any commands you can send to the 3570A that it recognises? >>>> >>> Only two that I have tried, Amplitude Offset light turn on and remote >>> light turn on. The both work. >>> It is the 3330 that seems not to respond. >>> >>>> IEEE488.2 is a slightly later dialect of classic GPIB so it is possible >>>> that older units do not speak it, but if you had a programme that >>>> previously worked with these units then the chances are that some >>>> manual >>>> override setting is wrong for automated slave operation. >>>> >>> The unit function well up to the Cmos battery replacement and the >>> move. >>> It seemed to make one scan with data, and then stopped working. >>> Mikek >>> >>> >>> --- >>> This email has been checked for viruses by Avast antivirus software. >>> http://www.avast.com >>> >> 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... > > 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. > > >> >> When you replaced the cmos, you did the hardware reset, >> followed by the cmos reset to default followed by any >> customizations you need? >> > The only things in the bios was set the date and something with the HD.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> > > >> Early port I/O required mapping of ports and interrupts. >> Later software did this automagically. Check for interrupt >> sharing issues. >> > > If only I knew how to check for interrupt sharing issues.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.> > > >> I recall a lot of futzing around with the software. > > Almost all of that was when I put the HD into the other computer. > I did uninstall any thing I installed.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.> > >> Did you >> get everything reloaded from a backup made BEFORE the cmos >> debacle? > > There was no backup. I assumed that what ever was on the HD before > I changed the Battery, is still there. Am I wrong?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.> > 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. > > This all worked together at sometime.Yes, before you booted the disk in a different machine.> FWIW, the computer has no internet connection to ad havoc. > >> 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. > > I note this is running Windows 95, I said 98 elsewhere. > >> 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. > > 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. > >> 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. >> > > I'll stop responding for a bit and get back to the unit. > Thanks, Mikek > > >> If it were me, I'd stick a logic analyzer on the GPIB port >> and see what is actually happening. >> >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.>
Reply by ●December 16, 20142014-12-16
On 12/16/2014 2:33 AM, Martin Brown wrote:> On 16/12/2014 02:04, amdx wrote: >> >> >> 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? > > Press one of F!, F2, F8, F10 or Del during boot and pray.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.> > 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 PCI slots are all in auto mode. Mikek> 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 analyzer (or a generic analyzer) 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. >
Reply by ●December 16, 20142014-12-16
On 12/16/2014 7:53 AM, amdx wrote: 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.> http://s395.photobucket.com/user/Qmavam/media/P1010134_zps7478c31f.jpg.htmlIs there anything helpful in this data? Thanks, Mikek
Reply by ●December 16, 20142014-12-16
On 12/16/2014 10:36 AM, amdx wrote:> On 12/16/2014 7:53 AM, amdx wrote: > > > 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. > >> http://s395.photobucket.com/user/Qmavam/media/P1010134_zps7478c31f.jpg.html >> > > 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.> http://s395.photobucket.com/user/Qmavam/media/CommunicationtestsNISpy_zps80d8f947.jpg.htmlThanks, Mikek
