Hi all,
Recap- I had the low Cmos Clock Lithium Battery in a computer.
I received a Cmos Clock Lithium Battery from China, had some question
about the date code. I installed the Cmos Clock Lithium Battery and had
the same message low CMOS battery. I order a new one from Mouser and
the computer now works properly.
Now I'm onto making the computer control some HP equipment via GPIB,
which it did before the CMOS battery died.
So,
I have a 3570A and a 3330B under GPIB control. I got this equipment
from my former employer and have not used it for about 12 years. When I
was at the job we had a another company write a software program to scan
frequency and measure R and X then output a file to the computer.
I connected the external sense resistor and probes as I could recall.
I did get the program to scan and make a file, but the data was
nonsense. I troubleshot and noted no signal on the front panel output
of the 3330B. (thus the nonsense data) After removing the covers on the
3330B I noticed the front panel connector was not connected, the
connection was made to the rear panel connector.
This gave me the clue that I actually would have an output on the
3570A output connectors, and I do.
(There are three 3330B rear panel connections are made to the 3570A
rear panel, giving an output on the two output connectors on the 3570A
front panel.)
This info now allowed my to hook up cabling to calibrate the 3570A and
all seems well.
However,
Now when I run the software to scan, I get the following error,
"Error while interpreting the response from the 3570. Type mismatch"
Seems a little odd because the program ran when I had no drive voltage
during my first tests.
I have removed the drive voltage and it still gives me the same error.
(no surprise)
There are two programs involved here, the original software mentioned
above and the National Instruments "NI-488.2" for the GPIB pcb.
Any ideas on where this problem may be?
I do have a copy of both of these programs, but hesitate to make any
changes until I get some feedback regarding which program could be at
fault, or if there could be another problem.
Thank you, Mikek
PS. Any group/forum that would be a better fit to answer my question?
Error message on GPIB program, Help
Started by ●December 11, 2014
Reply by ●December 11, 20142014-12-11
On 12/11/2014 2:58 PM, amdx wrote:> Hi all, > Recap- I had the low Cmos Clock Lithium Battery in a computer. > I received a Cmos Clock Lithium Battery from China, had some question > about the date code. I installed the Cmos Clock Lithium Battery and had > the same message low CMOS battery. I order a new one from Mouser and > the computer now works properly. > Now I'm onto making the computer control some HP equipment via GPIB, > which it did before the CMOS battery died. > So, > I have a 3570A and a 3330B under GPIB control. I got this equipment > from my former employer and have not used it for about 12 years. When I > was at the job we had a another company write a software program to scan > frequency and measure R and X then output a file to the computer. > I connected the external sense resistor and probes as I could recall. > I did get the program to scan and make a file, but the data was > nonsense. I troubleshot and noted no signal on the front panel output > of the 3330B. (thus the nonsense data) After removing the covers on the > 3330B I noticed the front panel connector was not connected, the > connection was made to the rear panel connector. > This gave me the clue that I actually would have an output on the > 3570A output connectors, and I do. > (There are three 3330B rear panel connections are made to the 3570A > rear panel, giving an output on the two output connectors on the 3570A > front panel.) > > This info now allowed my to hook up cabling to calibrate the 3570A and > all seems well. > However, > Now when I run the software to scan, I get the following error, > > "Error while interpreting the response from the 3570. Type mismatch" > > Seems a little odd because the program ran when I had no drive voltage > during my first tests. > I have removed the drive voltage and it still gives me the same error. > (no surprise) > > There are two programs involved here, the original software mentioned > above and the National Instruments "NI-488.2" for the GPIB pcb. > > Any ideas on where this problem may be? > > I do have a copy of both of these programs, but hesitate to make any > changes until I get some feedback regarding which program could be at > fault, or if there could be another problem. > > Thank you, Mikek > > PS. Any group/forum that would be a better fit to answer my question?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 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 The next command is to TURN OFF the Amplitude Offset light Returns the same error. Mikek
Reply by ●December 11, 20142014-12-11
On 12/11/2014 6:18 PM, amdx wrote:>> I have a 3570A and a 3330B under GPIB control. I got this equipmentYou *hope* they are under GPIB control. But, have you been able to PROVE that for both devices?>> from my former employer and have not used it for about 12 years. When I >> was at the job we had a another company write a software program to scan >> frequency and measure R and X then output a file to the computer.>> This info now allowed my to hook up cabling to calibrate the 3570A and >> all seems well. >> However, >> Now when I run the software to scan, I get the following error, >> >> "Error while interpreting the response from the 3570. Type mismatch"Perhaps the 3570 is returning a result that the software isn't expecting (or, prepared to handle -- e.g., an error message instead of a numeric value)>> Seems a little odd because the program ran when I had no drive voltage >> during my first tests. >> I have removed the drive voltage and it still gives me the same error. >> (no surprise) >> >> There are two programs involved here, the original software mentioned >> above and the National Instruments "NI-488.2" for the GPIB pcb. >> >> Any ideas on where this problem may be? >> >> I do have a copy of both of these programs, but hesitate to make any >> changes until I get some feedback regarding which program could be at >> fault, or if there could be another problem. >> >> PS. Any group/forum that would be a better fit to answer my question?Doesn't NI have a forum at <http://forums.ni.com> ?> 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 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 > > The next command is to TURN OFF the Amplitude Offset light > Returns the same error.Are you sure you are accessing the correct device? (i.e., that there is actually *any* device on the bus where you think it is?) Connected, powered, etc. (swap cables around wrt the first "working" device)
Reply by ●December 11, 20142014-12-11
amdx wrote:> Hi all, > Recap- I had the low Cmos Clock Lithium Battery in a computer. > I received a Cmos Clock Lithium Battery from China, had some question > about the date code. I installed the Cmos Clock Lithium Battery and had > the same message low CMOS battery. I order a new one from Mouser and > the computer now works properly. > Now I'm onto making the computer control some HP equipment via GPIB, > which it did before the CMOS battery died. > So, > I have a 3570A and a 3330B under GPIB control. I got this equipment from > my former employer and have not used it for about 12 years. When I was > at the job we had a another company write a software program to scan > frequency and measure R and X then output a file to the computer. > I connected the external sense resistor and probes as I could recall. I > did get the program to scan and make a file, but the data was nonsense. > I troubleshot and noted no signal on the front panel output > of the 3330B. (thus the nonsense data) After removing the covers on the > 3330B I noticed the front panel connector was not connected, the > connection was made to the rear panel connector. > This gave me the clue that I actually would have an output on the 3570A > output connectors, and I do. > (There are three 3330B rear panel connections are made to the 3570A rear > panel, giving an output on the two output connectors on the 3570A front > panel.) > > This info now allowed my to hook up cabling to calibrate the 3570A and > all seems well. > However, > Now when I run the software to scan, I get the following error, > > "Error while interpreting the response from the 3570. Type mismatch" > > Seems a little odd because the program ran when I had no drive voltage > during my first tests. > I have removed the drive voltage and it still gives me the same error. > (no surprise) > > There are two programs involved here, the original software mentioned > above and the National Instruments "NI-488.2" for the GPIB pcb. > > Any ideas on where this problem may be? > > I do have a copy of both of these programs, but hesitate to make any > changes until I get some feedback regarding which program could be at > fault, or if there could be another problem. > > Thank you, Mikek > > PS. Any group/forum that would be a better fit to answer my question?I do not have a clue,BUT... GPIB AKA HPIB all used DOS-based programs and 286 or older interface cards. Maybe some of that was upgraded later, but what i saw,was the programs were not altered for the Pentium type computers and the old hardware still was used. Now,maybe one of those programs is a DOS-based variant, and the other something more modern...leading to variable types being different and so the "type mismatch". I would expect the original software you mention may be DOS-based,and the National Instruments software more modern maybe even WynDoze. Match age of software with age of interface cards as best you can..
Reply by ●December 11, 20142014-12-11
amdx wrote:> On 12/11/2014 2:58 PM, amdx wrote: >> Hi all, >> Recap- I had the low Cmos Clock Lithium Battery in a computer. >> I received a Cmos Clock Lithium Battery from China, had some question >> about the date code. I installed the Cmos Clock Lithium Battery and had >> the same message low CMOS battery. I order a new one from Mouser and >> the computer now works properly. >> Now I'm onto making the computer control some HP equipment via GPIB, >> which it did before the CMOS battery died. >> So, >> I have a 3570A and a 3330B under GPIB control. I got this equipment >> from my former employer and have not used it for about 12 years. When I >> was at the job we had a another company write a software program to scan >> frequency and measure R and X then output a file to the computer. >> I connected the external sense resistor and probes as I could recall. >> I did get the program to scan and make a file, but the data was >> nonsense. I troubleshot and noted no signal on the front panel output >> of the 3330B. (thus the nonsense data) After removing the covers on the >> 3330B I noticed the front panel connector was not connected, the >> connection was made to the rear panel connector. >> This gave me the clue that I actually would have an output on the >> 3570A output connectors, and I do. >> (There are three 3330B rear panel connections are made to the 3570A >> rear panel, giving an output on the two output connectors on the 3570A >> front panel.) >> >> This info now allowed my to hook up cabling to calibrate the 3570A and >> all seems well. >> However, >> Now when I run the software to scan, I get the following error, >> >> "Error while interpreting the response from the 3570. Type mismatch" >> >> Seems a little odd because the program ran when I had no drive voltage >> during my first tests. >> I have removed the drive voltage and it still gives me the same error. >> (no surprise) >> >> There are two programs involved here, the original software mentioned >> above and the National Instruments "NI-488.2" for the GPIB pcb. >> >> Any ideas on where this problem may be? >> >> I do have a copy of both of these programs, but hesitate to make any >> changes until I get some feedback regarding which program could be at >> fault, or if there could be another problem. >> >> Thank you, Mikek >> >> PS. Any group/forum that would be a better fit to answer my question? > > 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 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 > > The next command is to TURN OFF the Amplitude Offset light > Returns the same error. > > Mikek >Does the HP3570A connect to the same card or a different card? Is there a "legacy" mismatch (hardware and/or software) for the HP3570A?
Reply by ●December 11, 20142014-12-11
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
Reply by ●December 12, 20142014-12-12
On 12/11/2014 8:46 PM, Don Y wrote:> On 12/11/2014 6:18 PM, amdx wrote: > >>> I have a 3570A and a 3330B under GPIB control. I got this equipment > > You *hope* they are under GPIB control. But, have you been able to PROVE > that for both devices? >I'm pretty sure that it is close to having control? The program actually ran once, but I didn't have any drive voltage and the data was garbage, but I did get data back to the computer.>>> from my former employer and have not used it for about 12 years. When I >>> was at the job we had a another company write a software program to scan >>> frequency and measure R and X then output a file to the computer. > >>> This info now allowed my to hook up cabling to calibrate the 3570A and >>> all seems well. >>> However, >>> Now when I run the software to scan, I get the following error, >>> >>> "Error while interpreting the response from the 3570. Type mismatch" > > Perhaps the 3570 is returning a result that the software isn't > expecting (or, prepared to handle -- e.g., an error message instead > of a numeric value) >May be, how would troubleshoot such a thing.>>> Seems a little odd because the program ran when I had no drive voltage >>> during my first tests. >>> I have removed the drive voltage and it still gives me the same error. >>> (no surprise) >>> >>> There are two programs involved here, the original software mentioned >>> above and the National Instruments "NI-488.2" for the GPIB pcb. >>> >>> Any ideas on where this problem may be? >>> >>> I do have a copy of both of these programs, but hesitate to make any >>> changes until I get some feedback regarding which program could be at >>> fault, or if there could be another problem. >>> >>> PS. Any group/forum that would be a better fit to answer my question? > > Doesn't NI have a forum at <http://forums.ni.com> ?I'll check again, I think I looked there but there was very little activity.> >> 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 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 >> >> The next command is to TURN OFF the Amplitude Offset light >> Returns the same error. > > Are you sure you are accessing the correct device?As I read the manual order is not important, also I have it connected as it was when it worked. (re: GPIB) (i.e., that> there is actually *any* device on the bus where you think it is?)Only thing I think I know is the 3330B is being told what to do and it does start at that frequency. I don't know if it is being told what voltage level to output, istr it stays at minimum (-86db). But I'll check that this evening.> Connected, powered, etc. (swap cables around wrt the first "working" > device)As I said above, the program worked as expected ONE time but I didn't have the drive voltage connected, so the data was garbage. Also the "Verifying Communication" procedure also worked once, coincident with me wiggling the GPIB connectors on the rear of the 3570A. Then when it didn't work again, I remove and cleaned all the GPIB connections with Caig Deoxit D5 and then treated them with Deoxit gold series. It didn't help. It is odd that in it seems to have worked properly twice out of 25 or 30 attempts. Thanks for the help, Mikek --- This email has been checked for viruses by Avast antivirus software. http://www.avast.com
Reply by ●December 12, 20142014-12-12
On 12/11/2014 9:25 PM, Robert Baer wrote:> amdx wrote: >> On 12/11/2014 2:58 PM, amdx wrote: >>> Hi all, >>> Recap- I had the low Cmos Clock Lithium Battery in a computer. >>> I received a Cmos Clock Lithium Battery from China, had some question >>> about the date code. I installed the Cmos Clock Lithium Battery and had >>> the same message low CMOS battery. I order a new one from Mouser and >>> the computer now works properly. >>> Now I'm onto making the computer control some HP equipment via GPIB, >>> which it did before the CMOS battery died. >>> So, >>> I have a 3570A and a 3330B under GPIB control. I got this equipment >>> from my former employer and have not used it for about 12 years. When I >>> was at the job we had a another company write a software program to scan >>> frequency and measure R and X then output a file to the computer. >>> I connected the external sense resistor and probes as I could recall. >>> I did get the program to scan and make a file, but the data was >>> nonsense. I troubleshot and noted no signal on the front panel output >>> of the 3330B. (thus the nonsense data) After removing the covers on the >>> 3330B I noticed the front panel connector was not connected, the >>> connection was made to the rear panel connector. >>> This gave me the clue that I actually would have an output on the >>> 3570A output connectors, and I do. >>> (There are three 3330B rear panel connections are made to the 3570A >>> rear panel, giving an output on the two output connectors on the 3570A >>> front panel.) >>> >>> This info now allowed my to hook up cabling to calibrate the 3570A and >>> all seems well. >>> However, >>> Now when I run the software to scan, I get the following error, >>> >>> "Error while interpreting the response from the 3570. Type mismatch" >>> >>> Seems a little odd because the program ran when I had no drive voltage >>> during my first tests. >>> I have removed the drive voltage and it still gives me the same error. >>> (no surprise) >>> >>> There are two programs involved here, the original software mentioned >>> above and the National Instruments "NI-488.2" for the GPIB pcb. >>> >>> Any ideas on where this problem may be? >>> >>> I do have a copy of both of these programs, but hesitate to make any >>> changes until I get some feedback regarding which program could be at >>> fault, or if there could be another problem. >>> >>> Thank you, Mikek >>> >>> PS. Any group/forum that would be a better fit to answer my question? >> >> 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 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 >> >> The next command is to TURN OFF the Amplitude Offset light >> Returns the same error. >> >> Mikek >> > Does the HP3570A connect to the same card or a different card? > Is there a "legacy" mismatch (hardware and/or software) for the HP3570A? >Both the 3330B and the 3570A are connected to the same card, as it was 12 years ago. By legacy mismatch, I suspect you mean a change of OS or such causing a mismatch. Everything is the same, using the same computer, still running Windows 95. I just replaced the dead CMOS battery/clock. Now before that I tried putting the drive into another computer and running the GPIB hardware (no success). Mikek --- This email has been checked for viruses by Avast antivirus software. http://www.avast.com
Reply by ●December 12, 20142014-12-12
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 --- This email has been checked for viruses by Avast antivirus software. http://www.avast.com
Reply by ●December 12, 20142014-12-12
On 12/11/2014 9:21 PM, Robert Baer wrote:> amdx wrote: >> Hi all, >> Recap- I had the low Cmos Clock Lithium Battery in a computer. >> I received a Cmos Clock Lithium Battery from China, had some question >> about the date code. I installed the Cmos Clock Lithium Battery and had >> the same message low CMOS battery. I order a new one from Mouser and >> the computer now works properly. >> Now I'm onto making the computer control some HP equipment via GPIB, >> which it did before the CMOS battery died. >> So, >> I have a 3570A and a 3330B under GPIB control. I got this equipment from >> my former employer and have not used it for about 12 years. When I was >> at the job we had a another company write a software program to scan >> frequency and measure R and X then output a file to the computer. >> I connected the external sense resistor and probes as I could recall. I >> did get the program to scan and make a file, but the data was nonsense. >> I troubleshot and noted no signal on the front panel output >> of the 3330B. (thus the nonsense data) After removing the covers on the >> 3330B I noticed the front panel connector was not connected, the >> connection was made to the rear panel connector. >> This gave me the clue that I actually would have an output on the 3570A >> output connectors, and I do. >> (There are three 3330B rear panel connections are made to the 3570A rear >> panel, giving an output on the two output connectors on the 3570A front >> panel.) >> >> This info now allowed my to hook up cabling to calibrate the 3570A and >> all seems well. >> However, >> Now when I run the software to scan, I get the following error, >> >> "Error while interpreting the response from the 3570. Type mismatch" >> >> Seems a little odd because the program ran when I had no drive voltage >> during my first tests. >> I have removed the drive voltage and it still gives me the same error. >> (no surprise) >> >> There are two programs involved here, the original software mentioned >> above and the National Instruments "NI-488.2" for the GPIB pcb. >> >> Any ideas on where this problem may be? >> >> I do have a copy of both of these programs, but hesitate to make any >> changes until I get some feedback regarding which program could be at >> fault, or if there could be another problem. >> >> Thank you, Mikek >> >> PS. Any group/forum that would be a better fit to answer my question? > I do not have a clue,BUT... GPIB AKA HPIB all used DOS-based programs > and 286 or older interface cards. > Maybe some of that was upgraded later, but what i saw,was the > programs were not altered for the Pentium type computers and the old > hardware still was used. > Now,maybe one of those programs is a DOS-based variant, and the other > something more modern...leading to variable types being different and so > the "type mismatch". > I would expect the original software you mention may be DOS-based,and > the National Instruments software more modern maybe even WynDoze. > Match age of software with age of interface cards as best you can.. > >It all worked 12 years ago, and I'm using the same computer, that has not been upgraded nor been connected to the internet. Thanks, Mikek --- This email has been checked for viruses by Avast antivirus software. http://www.avast.com
