Re: [time-nuts] Getting GPIB to work on HP5382B Universal counter
Hi...
I use mostly NI GPIB cards & adapters, but from the little work I've
done with the HP/Agilent stuff, I think the same overall principle
applies, re software development for instrument control.
First step...
Install the USB<>GPIB adapter drivers, tools and utilities "Exactly" as
the instruction say to for whatever OS you are running. Run and verify
any diagnostics they supply too. If anything does not work as expected,
find out what and why.
Then, in the folder tree all that will probably create somewhere on your
system, there will be some documentation, and probably some worked
examples in various languages, VB, C, Delphi etc, as to how to do the
basic (as in simple) IO communication stuff. NI is particularly good in
that respect, it's been a while since I hand hands on, of any Agilent
kit like this.
Look around the web. You will not be the only, or first person to be
doing this! ;-)
Don't expect older kit to conform to the more usual these days IEEE488.2
command structures, or SCPI for example. Modern more complicated
protocols are often not intuitive to mere mortals, some can even be
downright misleading.
In particular, do not expect some older kit to respond to '*IDN?' (an
identity query) Some will just take for example a command 'ID'.
Do not expect instant results/success! It takes a lot of time and
effort to often "reverse engineer" someone else's code (even simple
stuff) so you "Fully" understand how and why it works. Take the time
needed, it'll pay off in the long term.
Try to first talk to/control a much simpler bit of kit, or only do very
easy predictable stuff with it, if you only have one instrument. The
only "Libraries" you "Need" will be the ones supplied for your
programming language, to talk to and control the GPIB controller.
Do not expect the instruments manual to tell the whole truth, in regards
to it's GPIB functions. Some books are good (older HP for instance)
some are totally useless, written by accountants I think. Understand
how to use the instrument manually first also helps a great deal.
(Something along the lines of know your enemy!) Many manuals have
minor errors, that though experienced programmers and users will spot,
cuss, and carry on, if you do not have that "time served" experience,
they can stop you dead in your tracks. Common misprints, in nth
generation photocopies and scan's for example, commas that look like
periods, semi-colons that look like colons etc...
VB though you can get some versions for free, is probably not the best
choice for instrument control (or anything else some would say) But it
can be very useful. Try to find the exact same version, as
Agilent/HP/NI used in their examples. MS are terrible for changing
small details that often cause show stopping problems when trying to do
things like this, especialy if you're trying to "learn how to" at the
same time.
Despite what all the hype will say, do not expect it to be "Easy" or
"Quick" (whatever programming language you use, and I include LabView in
that respect too!) Programming, and doing it well, in any language, for
whatever reason, takes time and thought to get "Just Right", so that all
circumstances are covered. Something that many programmers seem not to
appreciate. What I mean, is expect errors from the instrument, and the
users input (often you!) and make the program robust enough to catch and
handle them safely.
IF a condition is met (or not)
THEN do something you want
ELSE take care of any unexpected conditions!
As my old college tutor kept trying to drum into us, the programs
purpose and function should be easily read in the comments. The "code"
is the translation from your comments, to get the machine to do your
bidding.
Document what you do, in the source comments, line by line at times!
You'll save a lot of time when you come back to something later, even
only a few days time!
Split your code into logical segments, subroutines, modules whatever.
Add plenty of "white space" in the source code, it makes reading it so
much easier, and also modifying it later too..
One module for example, to handle the GPIB interface.
So if you ever give the code to someone else, or you get another PC with
a different GPIB system, it's only that part that needs re-writing.
Likewise, a separate module for any RS232 IO for example, if/when
needed.
Another to handle IO to/from the instrument, this can be for each
individual instrument, or a common module for several similar
instruments. Most instruments you can query to find out what they are,
reporting back the model number and often any firmware version. Most
useful!
Another to do the "guts" of what you want.
Where eventually you'll spend most of your time and effort.
Processing measurement data, doing the "experiment" in essence...
And finally, one to handle the user interface, all the pretty bits etc.
Where you can "personalise" it to your taste.. This is usually the
first one to be made, in most GUI aware language tools, often much of it
is done for you when you make the on screen form. Again, VB (if that
is what you end up using) will have many worked examples for you to
learn from.
The modular approach, does also make it quicker and easier later to make
a new software tool or experimantal process, using the same IO but with
a different instrument, or the same instrument in a different way.
Take your time, don't overdo it, and eventually you'll have that warm
fuzzy happy feeling, when all of a sudden, the instrument is doing your
beck and call from your software, and doing it reliably!... It's I
think second only to rebuilding a dead engine, and the happy time when
it first bursts back into life again!
If you get "stuck into it"... Expect complaints from partners family
(or a persistant hungry cat) as the time will just fly by...
Keep a pencil and notepad by the bed. You'll wake up in the middle of
the night, knowing exactly what and how to solve some problem you were
working on, write it down, draw a sketch whatever & however strange it
may be, and then you'll remember it in the morning! ;-)
Above all Enjoy! If it's not fun, don't do it, unless someone is
paying you plenty to do so!
Regards to all..
Dave B.
Message: 7
Date: Tue, 13 Oct 2009 16:07:38 -0700
From: Hal Murray hmurray@megapathdsl.net
Subject: Re: [time-nuts] Getting GPIB to work on HP5382B Universal
counter
To: Discussion of precise time and frequency measurement
time-nuts@febo.com
Message-ID: 20091013230739.58C8DBCFC@ip-64-139-1-69.sjc.megapath.net
Content-Type: text/plain; charset=us-ascii
I'd very much appreciate any help that I can get in setting up a
HP5328B to communicate over GPIB. The goal is to log/graph the
frequency over time of various VFO's projects I'm working on.
I am using the Agilent 82357A USB to GPIB Interface, I have
the manual
for the counter, so I know some of the basic GPIB commands. I've
downloaded the Agilent IO Libraries Suite 15.5 and it looks
like I can
send simple commands to the counter, but I am not having any luck
reading from the counter.
I'd like to use Visual Basic to send commands and receive the
frequency measurements... but need some HP5328B specific libraries?
I haven't worked with either the 82357A or HP5328B. I have
worked with
similar gear.
I doubt if you need any HP5328B specific libraries.
Do you have any documentation for the libraries you are using?
There may be some initialization magic that you need to do.
Can you find any examples using the 82357A and the libraries
you have? (even
if they talk to another type of box, they may give you some ideas)
What makes you think you are sending commands? Do lights
blink or such? Or
just that your program doesn't hang?
If I was debugging something like that, I pick the simplest
example I could
find and work on it.
There is probably a reset command. It might blink some
lights but it doesn't
send back any data.
There is probably an ID command to tell you what type of
device you are
talking to. If you can get that to work you are over the hump.
Sometimes things like this are timing sensitive. A delay of
10 or 100 ms
after each send might help.
--
These are my opinions, not necessarily my employer's. I hate spam.
Dave,
I don't remember being your college tutor on this - in fact I never was a
college teacher, but what you've laid out below is pretty much what I taught
all the trainee programmers I had. You've done a very good job of putting
it "in a nutshell".
The objective of the whole is to achieve understandability so that the next
poor sap (this might be you two years later) who comes along to work on this
thing (whatever it is) can get stuck in to fix it without having to reverse
engineer the thought processes of the original author.
Dave
-----Original Message-----
From: time-nuts-bounces@febo.com [mailto:time-nuts-bounces@febo.com] On
Behalf Of Dave Baxter
Sent: 14 October 2009 10:15
To: time-nuts@febo.com
Subject: Re: [time-nuts] Getting GPIB to work on HP5382B Universal counter
Hi...
I use mostly NI GPIB cards & adapters, but from the little work I've done
with the HP/Agilent stuff, I think the same overall principle applies, re
software development for instrument control.
First step...
Install the USB<>GPIB adapter drivers, tools and utilities "Exactly" as the
instruction say to for whatever OS you are running. Run and verify any
diagnostics they supply too. If anything does not work as expected, find
out what and why.
Then, in the folder tree all that will probably create somewhere on your
system, there will be some documentation, and probably some worked examples
in various languages, VB, C, Delphi etc, as to how to do the basic (as in
simple) IO communication stuff. NI is particularly good in that respect,
it's been a while since I hand hands on, of any Agilent kit like this.
Look around the web. You will not be the only, or first person to be doing
this! ;-)
Don't expect older kit to conform to the more usual these days IEEE488.2
command structures, or SCPI for example. Modern more complicated protocols
are often not intuitive to mere mortals, some can even be downright
misleading.
In particular, do not expect some older kit to respond to '*IDN?' (an
identity query) Some will just take for example a command 'ID'.
Do not expect instant results/success! It takes a lot of time and
effort to often "reverse engineer" someone else's code (even simple
stuff) so you "Fully" understand how and why it works. Take the time
needed, it'll pay off in the long term.
Try to first talk to/control a much simpler bit of kit, or only do very
easy predictable stuff with it, if you only have one instrument. The
only "Libraries" you "Need" will be the ones supplied for your programming
language, to talk to and control the GPIB controller.
Do not expect the instruments manual to tell the whole truth, in regards to
it's GPIB functions. Some books are good (older HP for instance)
some are totally useless, written by accountants I think. Understand
how to use the instrument manually first also helps a great deal.
(Something along the lines of know your enemy!) Many manuals have
minor errors, that though experienced programmers and users will spot, cuss,
and carry on, if you do not have that "time served" experience,
they can stop you dead in your tracks. Common misprints, in nth
generation photocopies and scan's for example, commas that look like
periods, semi-colons that look like colons etc...
VB though you can get some versions for free, is probably not the best
choice for instrument control (or anything else some would say) But it
can be very useful. Try to find the exact same version, as
Agilent/HP/NI used in their examples. MS are terrible for changing small
details that often cause show stopping problems when trying to do things
like this, especialy if you're trying to "learn how to" at the same time.
Despite what all the hype will say, do not expect it to be "Easy" or "Quick"
(whatever programming language you use, and I include LabView in that
respect too!) Programming, and doing it well, in any language, for whatever
reason, takes time and thought to get "Just Right", so that all
circumstances are covered. Something that many programmers seem not to
appreciate. What I mean, is expect errors from the instrument, and the
users input (often you!) and make the program robust enough to catch and
handle them safely.
IF a condition is met (or not)
THEN do something you want
ELSE take care of any unexpected conditions!
As my old college tutor kept trying to drum into us, the programs purpose
and function should be easily read in the comments. The "code"
is the translation from your comments, to get the machine to do your
bidding.
Document what you do, in the source comments, line by line at times!
You'll save a lot of time when you come back to something later, even only a
few days time!
Split your code into logical segments, subroutines, modules whatever.
Add plenty of "white space" in the source code, it makes reading it so much
easier, and also modifying it later too..
One module for example, to handle the GPIB interface.
So if you ever give the code to someone else, or you get another PC with a
different GPIB system, it's only that part that needs re-writing.
Likewise, a separate module for any RS232 IO for example, if/when needed.
Another to handle IO to/from the instrument, this can be for each individual
instrument, or a common module for several similar instruments. Most
instruments you can query to find out what they are, reporting back the
model number and often any firmware version. Most useful!
Another to do the "guts" of what you want.
Where eventually you'll spend most of your time and effort.
Processing measurement data, doing the "experiment" in essence...
And finally, one to handle the user interface, all the pretty bits etc.
Where you can "personalise" it to your taste.. This is usually the
first one to be made, in most GUI aware language tools, often much of it
is done for you when you make the on screen form. Again, VB (if that
is what you end up using) will have many worked examples for you to learn
from.
The modular approach, does also make it quicker and easier later to make a
new software tool or experimantal process, using the same IO but with a
different instrument, or the same instrument in a different way.
Take your time, don't overdo it, and eventually you'll have that warm fuzzy
happy feeling, when all of a sudden, the instrument is doing your
beck and call from your software, and doing it reliably!... It's I
think second only to rebuilding a dead engine, and the happy time when it
first bursts back into life again!
If you get "stuck into it"... Expect complaints from partners family (or a
persistant hungry cat) as the time will just fly by...
Keep a pencil and notepad by the bed. You'll wake up in the middle of the
night, knowing exactly what and how to solve some problem you were working
on, write it down, draw a sketch whatever & however strange it may be, and
then you'll remember it in the morning! ;-)
Above all Enjoy! If it's not fun, don't do it, unless someone is
paying you plenty to do so!
Regards to all..
Dave B.
Message: 7
Date: Tue, 13 Oct 2009 16:07:38 -0700
From: Hal Murray hmurray@megapathdsl.net
Subject: Re: [time-nuts] Getting GPIB to work on HP5382B Universal
counter
To: Discussion of precise time and frequency measurement
time-nuts@febo.com
Message-ID: 20091013230739.58C8DBCFC@ip-64-139-1-69.sjc.megapath.net
Content-Type: text/plain; charset=us-ascii
I'd very much appreciate any help that I can get in setting up a
HP5328B to communicate over GPIB. The goal is to log/graph the
frequency over time of various VFO's projects I'm working on.
I am using the Agilent 82357A USB to GPIB Interface, I have
the manual
for the counter, so I know some of the basic GPIB commands. I've
downloaded the Agilent IO Libraries Suite 15.5 and it looks
like I can
send simple commands to the counter, but I am not having any luck
reading from the counter.
I'd like to use Visual Basic to send commands and receive the
frequency measurements... but need some HP5328B specific libraries?
I haven't worked with either the 82357A or HP5328B. I have worked with
similar gear.
I doubt if you need any HP5328B specific libraries.
Do you have any documentation for the libraries you are using?
There may be some initialization magic that you need to do.
Can you find any examples using the 82357A and the libraries you have?
(even if they talk to another type of box, they may give you some
ideas)
What makes you think you are sending commands? Do lights blink or
such? Or just that your program doesn't hang?
If I was debugging something like that, I pick the simplest example I
could find and work on it.
There is probably a reset command. It might blink some lights but it
doesn't send back any data.
There is probably an ID command to tell you what type of device you
are talking to. If you can get that to work you are over the hump.
Sometimes things like this are timing sensitive. A delay of 10 or 100
ms after each send might help.
--
These are my opinions, not necessarily my employer's. I hate spam.
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
I have not yet met with success, but I have a little more experience ;)
Since so many people have made helpful suggestions, I thought I'd include the current status.
Just downloaded the most recent version of NI-488.2 version 2.5 off the NI website. It downloaded/unzipped/installed without any apparent issue.
The "Devices and Interfaces - Measurement & Automation Explorer shows several different applications in the software tree, but does not recognize either of the two HP-IB interfaces that are installed/attached:
- USB to HPIB (Agilent 82357A)
- PCI to HPIB (HP 82350)
I did go back to the Agilent Connection Expert (it still sees the two devices) I did check the "Enable Agilent GPIB cards for 488 programs"
The MS Win XP Device Manager sees both of them.
I did learn that you cannot just re-install NI-488.2 from the downloaded zip file, but have to use the MS software uninstall process first.
Still no joy in recognizing the interface card(s)
Thanks again & Regards,
Jerome
KC6ENE
-----Original Message-----
From: time-nuts-bounces@febo.com [mailto:time-nuts-bounces@febo.com] On Behalf Of David C. Partridge
Sent: Wednesday, October 14, 2009 2:27 AM
To: 'Discussion of precise time and frequency measurement'
Subject: Re: [time-nuts] Getting GPIB to work on HP5382B Universal counter
Dave,
I don't remember being your college tutor on this - in fact I never was a
college teacher, but what you've laid out below is pretty much what I taught
all the trainee programmers I had. You've done a very good job of putting
it "in a nutshell".
The objective of the whole is to achieve understandability so that the next
poor sap (this might be you two years later) who comes along to work on this
thing (whatever it is) can get stuck in to fix it without having to reverse
engineer the thought processes of the original author.
Dave
-----Original Message-----
From: time-nuts-bounces@febo.com [mailto:time-nuts-bounces@febo.com] On
Behalf Of Dave Baxter
Sent: 14 October 2009 10:15
To: time-nuts@febo.com
Subject: Re: [time-nuts] Getting GPIB to work on HP5382B Universal counter
Hi...
I use mostly NI GPIB cards & adapters, but from the little work I've done
with the HP/Agilent stuff, I think the same overall principle applies, re
software development for instrument control.
First step...
Install the USB<>GPIB adapter drivers, tools and utilities "Exactly" as the
instruction say to for whatever OS you are running. Run and verify any
diagnostics they supply too. If anything does not work as expected, find
out what and why.
Then, in the folder tree all that will probably create somewhere on your
system, there will be some documentation, and probably some worked examples
in various languages, VB, C, Delphi etc, as to how to do the basic (as in
simple) IO communication stuff. NI is particularly good in that respect,
it's been a while since I hand hands on, of any Agilent kit like this.
Look around the web. You will not be the only, or first person to be doing
this! ;-)
Don't expect older kit to conform to the more usual these days IEEE488.2
command structures, or SCPI for example. Modern more complicated protocols
are often not intuitive to mere mortals, some can even be downright
misleading.
In particular, do not expect some older kit to respond to '*IDN?' (an
identity query) Some will just take for example a command 'ID'.
Do not expect instant results/success! It takes a lot of time and
effort to often "reverse engineer" someone else's code (even simple
stuff) so you "Fully" understand how and why it works. Take the time
needed, it'll pay off in the long term.
Try to first talk to/control a much simpler bit of kit, or only do very
easy predictable stuff with it, if you only have one instrument. The
only "Libraries" you "Need" will be the ones supplied for your programming
language, to talk to and control the GPIB controller.
Do not expect the instruments manual to tell the whole truth, in regards to
it's GPIB functions. Some books are good (older HP for instance)
some are totally useless, written by accountants I think. Understand
how to use the instrument manually first also helps a great deal.
(Something along the lines of know your enemy!) Many manuals have
minor errors, that though experienced programmers and users will spot, cuss,
and carry on, if you do not have that "time served" experience,
they can stop you dead in your tracks. Common misprints, in nth
generation photocopies and scan's for example, commas that look like
periods, semi-colons that look like colons etc...
VB though you can get some versions for free, is probably not the best
choice for instrument control (or anything else some would say) But it
can be very useful. Try to find the exact same version, as
Agilent/HP/NI used in their examples. MS are terrible for changing small
details that often cause show stopping problems when trying to do things
like this, especialy if you're trying to "learn how to" at the same time.
Despite what all the hype will say, do not expect it to be "Easy" or "Quick"
(whatever programming language you use, and I include LabView in that
respect too!) Programming, and doing it well, in any language, for whatever
reason, takes time and thought to get "Just Right", so that all
circumstances are covered. Something that many programmers seem not to
appreciate. What I mean, is expect errors from the instrument, and the
users input (often you!) and make the program robust enough to catch and
handle them safely.
IF a condition is met (or not)
THEN do something you want
ELSE take care of any unexpected conditions!
As my old college tutor kept trying to drum into us, the programs purpose
and function should be easily read in the comments. The "code"
is the translation from your comments, to get the machine to do your
bidding.
Document what you do, in the source comments, line by line at times!
You'll save a lot of time when you come back to something later, even only a
few days time!
Split your code into logical segments, subroutines, modules whatever.
Add plenty of "white space" in the source code, it makes reading it so much
easier, and also modifying it later too..
One module for example, to handle the GPIB interface.
So if you ever give the code to someone else, or you get another PC with a
different GPIB system, it's only that part that needs re-writing.
Likewise, a separate module for any RS232 IO for example, if/when needed.
Another to handle IO to/from the instrument, this can be for each individual
instrument, or a common module for several similar instruments. Most
instruments you can query to find out what they are, reporting back the
model number and often any firmware version. Most useful!
Another to do the "guts" of what you want.
Where eventually you'll spend most of your time and effort.
Processing measurement data, doing the "experiment" in essence...
And finally, one to handle the user interface, all the pretty bits etc.
Where you can "personalise" it to your taste.. This is usually the
first one to be made, in most GUI aware language tools, often much of it
is done for you when you make the on screen form. Again, VB (if that
is what you end up using) will have many worked examples for you to learn
from.
The modular approach, does also make it quicker and easier later to make a
new software tool or experimantal process, using the same IO but with a
different instrument, or the same instrument in a different way.
Take your time, don't overdo it, and eventually you'll have that warm fuzzy
happy feeling, when all of a sudden, the instrument is doing your
beck and call from your software, and doing it reliably!... It's I
think second only to rebuilding a dead engine, and the happy time when it
first bursts back into life again!
If you get "stuck into it"... Expect complaints from partners family (or a
persistant hungry cat) as the time will just fly by...
Keep a pencil and notepad by the bed. You'll wake up in the middle of the
night, knowing exactly what and how to solve some problem you were working
on, write it down, draw a sketch whatever & however strange it may be, and
then you'll remember it in the morning! ;-)
Above all Enjoy! If it's not fun, don't do it, unless someone is
paying you plenty to do so!
Regards to all..
Dave B.
Message: 7
Date: Tue, 13 Oct 2009 16:07:38 -0700
From: Hal Murray hmurray@megapathdsl.net
Subject: Re: [time-nuts] Getting GPIB to work on HP5382B Universal
counter
To: Discussion of precise time and frequency measurement
time-nuts@febo.com
Message-ID: 20091013230739.58C8DBCFC@ip-64-139-1-69.sjc.megapath.net
Content-Type: text/plain; charset=us-ascii
I'd very much appreciate any help that I can get in setting up a
HP5328B to communicate over GPIB. The goal is to log/graph the
frequency over time of various VFO's projects I'm working on.
I am using the Agilent 82357A USB to GPIB Interface, I have
the manual
for the counter, so I know some of the basic GPIB commands. I've
downloaded the Agilent IO Libraries Suite 15.5 and it looks
like I can
send simple commands to the counter, but I am not having any luck
reading from the counter.
I'd like to use Visual Basic to send commands and receive the
frequency measurements... but need some HP5328B specific libraries?
I haven't worked with either the 82357A or HP5328B. I have worked with
similar gear.
I doubt if you need any HP5328B specific libraries.
Do you have any documentation for the libraries you are using?
There may be some initialization magic that you need to do.
Can you find any examples using the 82357A and the libraries you have?
(even if they talk to another type of box, they may give you some
ideas)
What makes you think you are sending commands? Do lights blink or
such? Or just that your program doesn't hang?
If I was debugging something like that, I pick the simplest example I
could find and work on it.
There is probably a reset command. It might blink some lights but it
doesn't send back any data.
There is probably an ID command to tell you what type of device you
are talking to. If you can get that to work you are over the hump.
Sometimes things like this are timing sensitive. A delay of 10 or 100
ms after each send might help.
--
These are my opinions, not necessarily my employer's. I hate spam.
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
This email message is for the sole use of the intended recipient(s) and may contain
confidential information. Any unauthorized review, use, disclosure or distribution
is prohibited. If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
Dave Baxter wrote:
As my old college tutor kept trying to drum into us, the programs
purpose and function should be easily read in the comments. The "code"
is the translation from your comments, to get the machine to do your
bidding.
Document what you do, in the source comments, line by line at times!
You'll save a lot of time when you come back to something later, even
only a few days time!
While the general advice is sound, comments are a mixed blessing. The main problem with them is that they're in no way checked for their correctness, as the compiler or interpreter ignores them.
Quite often that leads to comment rot: When bugs get fixed and features added, the comments don't get updated and get out of sync with the code. Eventually you get conflicting information from code and comments and have to figure out which one's right. An old programmer's saying is: If code and comment disagree, they're probably both wrong.
Comments are important, but even more important in my opinion is to try to write code in a way that is understandable without a comment. Try to say it in code, and put in comments where that fails. Don't try to duplicate what the code says in a comment. Rather, explain the general idea or method.
Anyway, just my 0.02€
Cheers
Stefan
I'd be (happily) surprised if the NI libraries recognized Agilent
devices. I think they only support their own cards though.
There could also be a problem if you have both Agilent and NI support
libraries installed. I ran into this on Linux when I tried to install
the NI-provided drivers and libraries on a system where the linux-gpib
stuff was already installed; the result was that neither one worked!
John
Jerome Peters wrote:
I have not yet met with success, but I have a little more experience ;)
Since so many people have made helpful suggestions, I thought I'd include the current status.
Just downloaded the most recent version of NI-488.2 version 2.5 off the NI website. It downloaded/unzipped/installed without any apparent issue.
The "Devices and Interfaces - Measurement & Automation Explorer shows several different applications in the software tree, but does not recognize either of the two HP-IB interfaces that are installed/attached:
- USB to HPIB (Agilent 82357A)
- PCI to HPIB (HP 82350)
I did go back to the Agilent Connection Expert (it still sees the two devices) I did check the "Enable Agilent GPIB cards for 488 programs"
The MS Win XP Device Manager sees both of them.
I did learn that you cannot just re-install NI-488.2 from the downloaded zip file, but have to use the MS software uninstall process first.
Still no joy in recognizing the interface card(s)
Thanks again & Regards,
Jerome
KC6ENE
The standard I used in my department was that
when anyone changed code, they commented out
the original code and then entered their new
code with a date and explanation of the change.
That way you have the what and why the previous
developer originally thought he was doing and
what, when, and why you changed it.
This is also very useful for the times you
discover why it was originally done that way
and you have to remove your modification. :)
Maintaining comments and change history requires
self-discipline, but reflect the skill level of
the developer. Accuracy and note-taking are
certainly something that time-nuts are good at.
Respectfully,
Mike - AA8K
Even COBOL needed comments
Heinzmann, Stefan (ALC NetworX GmbH) wrote:
While the general advice is sound, comments are a mixed blessing. The main problem with them is that they're in no way checked for their correctness, as the compiler or interpreter ignores them.
Quite often that leads to comment rot: When bugs get fixed and features added, the comments don't get updated and get out of sync with the code. Eventually you get conflicting information from code and comments and have to figure out which one's right. An old programmer's saying is: If code and comment disagree, they're probably both wrong.
Comments are important, but even more important in my opinion is to try to write code in a way that is understandable without a comment. Try to say it in code, and put in comments where that fails. Don't try to duplicate what the code says in a comment. Rather, explain the general idea or method.
Anyway, just my 0.02€
Cheers
Stefan
On 10/14/09 5:46 AM, "Mike Naruta AA8K" aa8k@comcast.net wrote:
The standard I used in my department was that
when anyone changed code, they commented out
the original code and then entered their new
code with a date and explanation of the change.
That way you have the what and why the previous
developer originally thought he was doing and
what, when, and why you changed it.
These days, with versioning source code repositories (like SVN) and code
browsers that understand the repository, it's a simple matter to get a diff,
highlighted in color even. The "commit" comment to the repo should say who
why what, etc.
Now.. If you check out, spend 6 months tinkering in 500 modules, and then do
the commit, you're probably going to regret it. But if you do small changes
and commits, it works pretty well.
Jerome...
I can appreciate the frustration you are experiencing with this. I don't
like to do much programming anymore because of so many undocumented rules
and procedures needed to make things work that ought to be simple. However,
in your case, I think I can be of some help.
The Agilent IO Libraries will load and peacefully coexist with the NI libs,
as they are designed that way. You can even specify one or the other as
primary. Personally, I'd make the Agilent version primary, as you are using
their hardware. I believe that NI's can only function as primary.
Interestingly, Agilent's IO Libs make an effort to support most NI hardware
and work with LabView, and NI reciprocates a little. So in many cases, you
can get by with just one installed.
Agilent's Connection Expert should not only see the 82357A and 83250, but
you should also be able to see or add the 5382B as being connected to one of
those. Personally, I'd go with the USB/GPIB adapter, if only for
convenience.
Once you can see the counter in the Agilent CE, you can send commands to it.
As one writer mentioned, you need to enter the correct commands for your
box, as the ones listed in CE are to the newer standards, such as SCPI. If
you enter a command that requires reading back data, there is a command that
both sends and reads. Even a data array can be read back through CE and
displayed in the window.
If you are able to make that work satisfactorily, then your program should
just need to point to the name of the IO device, usually gpib0, or in some
cases, to the name of the instrument once you have it defined in your
program. VEE does this very nicely, and I'm sure that LabView has similar
capability. VB may require a more explicit identification in each IO
command.
Hope this helps. If you still have trouble, ping the list again.
Regards,
Tom Holmes, N8ZM
Tipp City, OH
EM79xx
-----Original Message-----
From: time-nuts-bounces@febo.com [mailto:time-nuts-bounces@febo.com] On
Behalf Of Jerome Peters
Sent: Wednesday, October 14, 2009 6:16 AM
To: 'Discussion of precise time and frequency measurement'
Subject: Re: [time-nuts] Getting GPIB to work on HP5382B Universal counter
I have not yet met with success, but I have a little more experience ;)
Since so many people have made helpful suggestions, I thought I'd include
the current status.
Just downloaded the most recent version of NI-488.2 version 2.5 off the NI
website. It downloaded/unzipped/installed without any apparent issue.
The "Devices and Interfaces - Measurement & Automation Explorer shows
several different applications in the software tree, but does not recognize
either of the two HP-IB interfaces that are installed/attached:
- USB to HPIB (Agilent 82357A)
- PCI to HPIB (HP 82350)
I did go back to the Agilent Connection Expert (it still sees the two
devices) I did check the "Enable Agilent GPIB cards for 488 programs"
The MS Win XP Device Manager sees both of them.
I did learn that you cannot just re-install NI-488.2 from the downloaded zip
file, but have to use the MS software uninstall process first.
Still no joy in recognizing the interface card(s)
Thanks again & Regards,
Jerome
KC6ENE
-----Original Message-----
From: time-nuts-bounces@febo.com [mailto:time-nuts-bounces@febo.com] On
Behalf Of David C. Partridge
Sent: Wednesday, October 14, 2009 2:27 AM
To: 'Discussion of precise time and frequency measurement'
Subject: Re: [time-nuts] Getting GPIB to work on HP5382B Universal counter
Dave,
I don't remember being your college tutor on this - in fact I never was a
college teacher, but what you've laid out below is pretty much what I taught
all the trainee programmers I had. You've done a very good job of putting
it "in a nutshell".
The objective of the whole is to achieve understandability so that the next
poor sap (this might be you two years later) who comes along to work on this
thing (whatever it is) can get stuck in to fix it without having to reverse
engineer the thought processes of the original author.
Dave
-----Original Message-----
From: time-nuts-bounces@febo.com [mailto:time-nuts-bounces@febo.com] On
Behalf Of Dave Baxter
Sent: 14 October 2009 10:15
To: time-nuts@febo.com
Subject: Re: [time-nuts] Getting GPIB to work on HP5382B Universal counter
Hi...
I use mostly NI GPIB cards & adapters, but from the little work I've done
with the HP/Agilent stuff, I think the same overall principle applies, re
software development for instrument control.
First step...
Install the USB<>GPIB adapter drivers, tools and utilities "Exactly" as the
instruction say to for whatever OS you are running. Run and verify any
diagnostics they supply too. If anything does not work as expected, find
out what and why.
Then, in the folder tree all that will probably create somewhere on your
system, there will be some documentation, and probably some worked examples
in various languages, VB, C, Delphi etc, as to how to do the basic (as in
simple) IO communication stuff. NI is particularly good in that respect,
it's been a while since I hand hands on, of any Agilent kit like this.
Look around the web. You will not be the only, or first person to be doing
this! ;-)
Don't expect older kit to conform to the more usual these days IEEE488.2
command structures, or SCPI for example. Modern more complicated protocols
are often not intuitive to mere mortals, some can even be downright
misleading.
In particular, do not expect some older kit to respond to '*IDN?' (an
identity query) Some will just take for example a command 'ID'.
Do not expect instant results/success! It takes a lot of time and
effort to often "reverse engineer" someone else's code (even simple
stuff) so you "Fully" understand how and why it works. Take the time
needed, it'll pay off in the long term.
Try to first talk to/control a much simpler bit of kit, or only do very
easy predictable stuff with it, if you only have one instrument. The
only "Libraries" you "Need" will be the ones supplied for your programming
language, to talk to and control the GPIB controller.
Do not expect the instruments manual to tell the whole truth, in regards to
it's GPIB functions. Some books are good (older HP for instance)
some are totally useless, written by accountants I think. Understand
how to use the instrument manually first also helps a great deal.
(Something along the lines of know your enemy!) Many manuals have
minor errors, that though experienced programmers and users will spot, cuss,
and carry on, if you do not have that "time served" experience,
they can stop you dead in your tracks. Common misprints, in nth
generation photocopies and scan's for example, commas that look like
periods, semi-colons that look like colons etc...
VB though you can get some versions for free, is probably not the best
choice for instrument control (or anything else some would say) But it
can be very useful. Try to find the exact same version, as
Agilent/HP/NI used in their examples. MS are terrible for changing small
details that often cause show stopping problems when trying to do things
like this, especialy if you're trying to "learn how to" at the same time.
Despite what all the hype will say, do not expect it to be "Easy" or "Quick"
(whatever programming language you use, and I include LabView in that
respect too!) Programming, and doing it well, in any language, for whatever
reason, takes time and thought to get "Just Right", so that all
circumstances are covered. Something that many programmers seem not to
appreciate. What I mean, is expect errors from the instrument, and the
users input (often you!) and make the program robust enough to catch and
handle them safely.
IF a condition is met (or not)
THEN do something you want
ELSE take care of any unexpected conditions!
As my old college tutor kept trying to drum into us, the programs purpose
and function should be easily read in the comments. The "code"
is the translation from your comments, to get the machine to do your
bidding.
Document what you do, in the source comments, line by line at times!
You'll save a lot of time when you come back to something later, even only a
few days time!
Split your code into logical segments, subroutines, modules whatever.
Add plenty of "white space" in the source code, it makes reading it so much
easier, and also modifying it later too..
One module for example, to handle the GPIB interface.
So if you ever give the code to someone else, or you get another PC with a
different GPIB system, it's only that part that needs re-writing.
Likewise, a separate module for any RS232 IO for example, if/when needed.
Another to handle IO to/from the instrument, this can be for each individual
instrument, or a common module for several similar instruments. Most
instruments you can query to find out what they are, reporting back the
model number and often any firmware version. Most useful!
Another to do the "guts" of what you want.
Where eventually you'll spend most of your time and effort.
Processing measurement data, doing the "experiment" in essence...
And finally, one to handle the user interface, all the pretty bits etc.
Where you can "personalise" it to your taste.. This is usually the
first one to be made, in most GUI aware language tools, often much of it
is done for you when you make the on screen form. Again, VB (if that
is what you end up using) will have many worked examples for you to learn
from.
The modular approach, does also make it quicker and easier later to make a
new software tool or experimantal process, using the same IO but with a
different instrument, or the same instrument in a different way.
Take your time, don't overdo it, and eventually you'll have that warm fuzzy
happy feeling, when all of a sudden, the instrument is doing your
beck and call from your software, and doing it reliably!... It's I
think second only to rebuilding a dead engine, and the happy time when it
first bursts back into life again!
If you get "stuck into it"... Expect complaints from partners family (or a
persistant hungry cat) as the time will just fly by...
Keep a pencil and notepad by the bed. You'll wake up in the middle of the
night, knowing exactly what and how to solve some problem you were working
on, write it down, draw a sketch whatever & however strange it may be, and
then you'll remember it in the morning! ;-)
Above all Enjoy! If it's not fun, don't do it, unless someone is
paying you plenty to do so!
Regards to all..
Dave B.
Message: 7
Date: Tue, 13 Oct 2009 16:07:38 -0700
From: Hal Murray hmurray@megapathdsl.net
Subject: Re: [time-nuts] Getting GPIB to work on HP5382B Universal
counter
To: Discussion of precise time and frequency measurement
time-nuts@febo.com
Message-ID: 20091013230739.58C8DBCFC@ip-64-139-1-69.sjc.megapath.net
Content-Type: text/plain; charset=us-ascii
I'd very much appreciate any help that I can get in setting up a
HP5328B to communicate over GPIB. The goal is to log/graph the
frequency over time of various VFO's projects I'm working on.
I am using the Agilent 82357A USB to GPIB Interface, I have
the manual
for the counter, so I know some of the basic GPIB commands. I've
downloaded the Agilent IO Libraries Suite 15.5 and it looks
like I can
send simple commands to the counter, but I am not having any luck
reading from the counter.
I'd like to use Visual Basic to send commands and receive the
frequency measurements... but need some HP5328B specific libraries?
I haven't worked with either the 82357A or HP5328B. I have worked with
similar gear.
I doubt if you need any HP5328B specific libraries.
Do you have any documentation for the libraries you are using?
There may be some initialization magic that you need to do.
Can you find any examples using the 82357A and the libraries you have?
(even if they talk to another type of box, they may give you some
ideas)
What makes you think you are sending commands? Do lights blink or
such? Or just that your program doesn't hang?
If I was debugging something like that, I pick the simplest example I
could find and work on it.
There is probably a reset command. It might blink some lights but it
doesn't send back any data.
There is probably an ID command to tell you what type of device you
are talking to. If you can get that to work you are over the hump.
Sometimes things like this are timing sensitive. A delay of 10 or 100
ms after each send might help.
--
These are my opinions, not necessarily my employer's. I hate spam.
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
This email message is for the sole use of the intended recipient(s) and may
contain
confidential information. Any unauthorized review, use, disclosure or
distribution
is prohibited. If you are not the intended recipient, please contact the
sender by
reply email and destroy all copies of the original message.
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Despite what all the hype will say, do not expect it to be "Easy" or
"Quick" (whatever programming language you use, and I include LabView in
that respect too!) Programming, and doing it well, in any language, for
whatever reason, takes time and thought to get "Just Right", so that all
circumstances are covered. Something that many programmers seem not to
appreciate. What I mean, is expect errors from the instrument, and the
users input (often you!) and make the program robust enough to catch and
handle them safely.
IF a condition is met (or not)
THEN do something you want
ELSE take care of any unexpected conditions
Great summary, Dave. This is one of the only pieces of advice I'd add a
caveat to -- specifically, that user-friendly error recovery in the GPIB
world can bloat your code at a geometric rate. What does it mean, for
instance, if a write timeout happens on the 12th command in the 4th
iteration of a 20-command loop? Did the timeout happen after the instrument
accepted the command, or before? What is the instrument's state at this
point, anyway? Should your program try to recover gracefully and offer the
user a chance to retry the operation... or is it better to terminate the
whole measurement and let the user recover from whatever unexpected
situation occurred in the outside world?
My own software sometimes fails on the side of recklessness, when a GPIB
error brings up an unhelpful error message and aborts the whole program.
That reveals its origin as a collection of quick and dirty hacks that were
never meant to be seen by the outside world. Still, the code base would be
much larger and harder to maintain if I actually tried to implement good SW
engineering practices when talking to "stateful" hardware.
In newer applications I've at least broken myself of the habit of
terminating the whole .exe when something goes wrong, but I still don't
believe in taking extraordinary steps to handle errors. Kill the current
measurement and let the user do the troubleshooting, IMHO. Make a
distinction between robust, general-purpose code written for end users and
random hacks written to make your own life easier in the here-and-now. They
both have legitimate places in your lab's ecosystem.
As my old college tutor kept trying to drum into us, the programs
purpose and function should be easily read in the comments. The "code"
is the translation from your comments, to get the machine to do your
bidding.
Document what you do, in the source comments, line by line at times!
You'll save a lot of time when you come back to something later, even
only a few days time!
Better, however, to write the code for human consumption in the first
place. Comments age like dead fish. If you find yourself writing a long
comment to explain something, chances are you should go back and find a
simpler way to express it in the code itself.
-- john, KE5FX