Error message on GPIB program, Help

On 12/11/2014 8:46 PM, Don Y wrote:

> Doesn't NI have a forum at <http://forums.ni.com> ?

  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

On 12/12/2014 8:53 AM, amdx wrote:
>>>     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 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.

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

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

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

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!

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

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

>    It is odd that in it seems to have worked properly twice out of 25 or 30
> attempts.

On 12/12/2014 1:12 PM, Don Y wrote:
> On 12/12/2014 8:53 AM, amdx wrote:
>>>>     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 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).
>

  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.

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

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

>
> 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.
>
>>   (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.
>
> 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.]
>
>>> 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.
>
> 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!
>
>> 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.
>
> 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).
>
  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

On 12/12/2014 2:34 PM, amdx wrote:
>>>> 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 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).
>
>   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.

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!

>> Swap the cables (or, swap the devices).  "In theory" the observed behavior
>> should not change.  If it *does*...  :>
>
> 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?)

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.

>>>   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.
>>
>> 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.]
>>
>>>> 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.
>>
>> 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!
>>
>>> 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.
>>
>> 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).
>>
> 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).

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

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

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??!"

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

+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)

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

On 12/12/2014 4:23 PM, Don Y wrote:
> On 12/12/2014 2:34 PM, amdx wrote:
>>>>> 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 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).
>>
>>   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.
>
> 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!
>

  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

On 12/12/2014 5:40 PM, amdx wrote:

>> 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!
>
> OK, ok! Order shouldn't matter, unless there is a problem. :-)

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'm certainly going to checking into cables as the next step.

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.

amdx wrote:
> 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
>
   Ergg..'twas an idea.
   Sorry.

amdx wrote:
> 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
>
   Stupid idea: interchange device addressing for the two instruments 
and make appropriate command changes.

On Thu, 11 Dec 2014 19:18:11 -0600, amdx <nojunk@knology.net> 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=3D"  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

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

?-)
=20

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.

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