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