1. Home
  2. Electronics Design
  3. Error message on GPIB program, Help

Error message on GPIB program, Help

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?

Reply to
amdx
Loading thread data ...

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 to
amdx

You *hope* they are under GPIB control. But, have you been able to PROVE that for both devices?

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)

Doesn't NI have a forum at ?

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 to
Don Y

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 to
Robert Baer

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 to
Robert Baer

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 to
John Miles, KE5FX

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.

May be, how would troubleshoot such a thing.

I'll check again, I think I looked there but there was very little activity.

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

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.

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 to
amdx

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 to
amdx

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 to
amdx

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
Reply to
amdx

Ah, this is very active. I did ask for help on the forum. Mikek

--
This email has been checked for viruses by Avast antivirus software. 
http://www.avast.com
Reply to
amdx

I meant "physical order". I.e., you have a cable connecting the "first device" (whatever that may be) to your PC. And, another cable connecting that first device to the second device (which is whatever the first device was NOT).

Swap the cables (or, swap the devices). "In theory" the observed behavior should not change. If it *does*... :>

You can also individually verify connectivity with the "host". Connect

*one* device and verify that you can control and query it AS YOU EXPECT. Then, disconnect it and try the same for the second device. (noting which cables are involved in each transaction -- or, verifying that you always use the *same* cable, etc.).

If each device works in isolation -- but not in concert -- then there is some interaction between the devices. E.g., an addressing issue whereby one device "talks over" a transaction intended for the other device.

The error from the 3570 indicates "no listeners" -- so, either there was not an acknowledgement *from* the 3570 *or*, the command timed out before a reply was received.

[I have no idea where the timing is done in your setup.]

But *lots* of things can change between now and then. Each device contains "state" -- memory of what has happened before.

If something is truly intermittent, then you have to remove that state from subsequent experiments to get repeatability. E.g., a "free" experiment would be to power everything down. Then, power everything back up IN SOME PARTICULAR ORDER (as long as you can reproduce that order) giving each device (and PC) time to "get stable" before moving on to the next device.

*Then*, try talking to the devices. E.g., have you tried talking to the 3570 *first*? Or, have you always talked to it *after* talking to the 3330? Theoretically, the results from the commands (the specific *data*) may change based on what you tell each device to do and how they are wired together (signal paths) *but* the commands should still *complete* regardless of the order in which the devices were accessed/commanded. *If* everything is cabled/configured properly!

As I said, swap the cables. What if you have a break/intermittent inside the connector shell or the body of the cable? Cleaning it won't help (i.e., consider the physical strains on the cables and where they might be fatigued over time).

Reply to
Don Y

Yes, that is the way I understood what you said, and as I understand GPIB order is not important (also per the manual) and the the order is the same as it was when it did work.

Good point! I'm having a creeping feeling that I might have a broken wire in a cable, because it has worked on two occasions. Once after I wiggled the cables on the back. (or was that just a coincidence?)

Yes on checking cables. I am a bit uncomfortable with a hard bend in one of the cables. I did get help on the NI forum, the ENOL error Info says, ENOL (2) Error Condition:Function detected no Listener(s). So, I've got some checking to do. And the rest,

Description: GPIB communications require a single Talker (to write data messages) and one or more Listeners (to read data messages). ENOL usually occurs when a write operation is attempted, but no Listeners are addressed or there are no Listeners at the specified address(es). For a device write, ENOL indicates that the GPIB address you are attempting to communicate with does not mach the GPIB address of the device connected to the bus. Possible Cause: The instrument you are trying to communicate with is not at the expected primary address, the instrument is not powered on, or the cable to the instrument is either disconnected or broken. Solutions:

Make sure that the GPIB address of your device matches the GPIB address of the device to which you want to write data.

Verify that the cable is properly connected to the instrument. Try switching cables to verify that the cable is not broken.

Make sure that at least two-thirds of your devices are powered on. For board-level communications, use the appropriate hex code in the ibcmd function to address your device as a Listener.

Call the ibpad function (and ibsad, if necessary) to set the primary address of your device. The ibpad function will return what the previous setting for the device was, and you can check to see if the configured address matches the device's actual address.

Thanks, Mikek

--
This email has been checked for viruses by Avast antivirus software. 
http://www.avast.com
Reply to
amdx

Grrrr... sorry, I'm still apparently not being clear. It doesn't matter where "on the bus" a device is located (physically, electrically). But, there is a physical path that the electrons follow to get from PC to "device". I.e., "go out this connector on the PC, down *this* cable, etc. until you reach the targeted device".

Imagine part of that path has a pothole in it! The path to one device may be "smooth sailing" while the other device incurs the disturbance of the pothole.

Move ("change the PHYSICAL order") the devices so the paths (cables, connectors, etc.) involved in accessing the two devices are swapped. Force the 'good'/performant device to sit where the 'bad' device was seated!

That was my point. As was removing all but one device from the chain initially and verifying operation of each, "solo".

I kept replacing the power cord on our toaster oven as it had an obvious break (big kink where the cord passed through the strain relief). But, the problem kept reappearing! Turns out, there was *another* break inside the oven that my first repair hadn't addressed.

--------------------------------------^^^^^^^^^^^^

Yes. Your command was not ("correctly") acknowledged.

I.e., you are talking to the 3570 at "15" but it's really at "14". Note that it *may* actually be at 15 but a flaw in the cable is causing "14" to appear AT THE 3570!

Note that a flaw could also result in the 3330 (sorry if I am screwing up these numbers) responding when the 3570 was targeted. Or, vice versa. This is why I suggested moving back to a smaller configuration where you can independently "verify" performance of instruments, software, cables, etc.

"Gee, I can talk to this device with this cable *or* that cable (perhaps because a particular BROKEN conductor is not required in those transactions). But, I can only use THIS cable to talk to the other device. A cable is a cable is a cable -- so, why isn't this one??!"

+42

I'd go further and try to *remove* the cable completely (how do you know it doesn't have a SHORT and all you are doing is MOVING THE SHORT closer or further from the PC)

Reply to
Don Y

OK, ok! Order shouldn't matter, unless there is a problem. :-) I'm certainly going to checking into cables as the next step.

Thank you, Mikek

Reply to
amdx

But there *is* a problem! So, a cable is NOT necessarily a cable! :> I.e., "this can't happen" (if things were working as intended) so

*something* is not what you expect it to be.

I would fall back to one cable with one device; then the other device. Then, the other cable with the one device; and the other.

If you can't get through this much, then you know you have something significantly SNAFU'd. And, you will have trimmed something(s) out of the mix so you can narrow down the potential problem source.

If things "suddenly" start working, I would be annoyed and seriously motivated to start stressing connections, etc. Problems rarely fix themselves! Six months from now, you'll wonder why things aren't working and may forget what you did to get them working "tentatively" to begin with.

Reply to
Don Y

Ergg..'twas an idea. Sorry.

Reply to
Robert Baer

Stupid idea: interchange device addressing for the two instruments and make appropriate command changes.

Reply to
Robert Baer

had

I

scan

recall.

the

mentioned

question?

12.3 Hz

I am used to seeing much longer device settings strings. But these may be enough for communications tests. Do you have the sources to thee programs? I would like to take a look at them. Also do yo have the manuals or the control commands and result formats?

josephkk

?-)

Reply to
josephkk

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.

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. 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?

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.

--
Regards, 
Martin Brown
Reply to
Martin Brown

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.