GPIB guide and samples

[JÞB]

---

@smercurio_fc wrote:

The guidelines show using VISA for good reason: that's what's recommended for new designs. You should not use the lower-level GPIB functions unless you are dealing with very old instruments or very old GPIB cards. Many instrument these days come with multiple interfaces. VISA provide a level of abstraction that allows you to design an instrument driver so that you can communicate with the instrument using any of the supported interfaces. One driver, multiple interfaces. Learn VISA.

---

Actually,  I'm going to debate the Knight here on this point.  The low level GPIB functionallity (IEEE488.2 functions) are there for a reason but NOT for communicating with an instrument.  VISA does provide access to anything you need to do with a GPIB instrument although, you need to use properties of the session to handle unusual functions like unaddressing. 

WAY BACK WHEN the occaissional engineer put a collection of instruments on a bus as a system where control of the bus passed from one piece of gear to another depending on the state of the system.  They didn't have really powerful computers so they used external triggers and handshaking lines of the GPIB Bus itself as system logic components for process automation.  The bus is still capable of that functionallity but the model proved difficult to troubleshoot and was a maintainence nightmare.  With the advent of modern compuing it became common practice to treat each instrument as an indiviual entity from a single main program residing on the bus master.  VISA leverages this model by abstracting the concept of an instrument regaurdless of the communications physical layer.

In point use VISA to control any instrument

If you need to controll a GPIB system you may be able to take advantage of the lower level GPIB functions- but you should probably re-think the system archietecture- since you've moved into a 1960's model for automation

[smercurio_fc]

I don't disagree with the premise of what you're saying. I've had 2 occasions in the past when I was trying to talk to some really old equipment, and VISA didn't work. The lower-level GPIB functions did. Don't know if it was an issue with the driver, or what.

[JÞB]

---

@smercurio_fc wrote:

I don't disagree with the premise of what you're saying. I've had 2 occasions in the past when I was trying to talk to some really old equipment, and VISA didn't work. The lower-level GPIB functions did. Don't know if it was an issue with the driver, or what.

---

I've seen some whacky GPIB instruments myself so they do happen- (Had one once that interperated *IFC as "Quit Controlling" and couldn't use a legacy version of NI VISA on the same BUS since that VISA version issued *IFC on VISA Open)  VISA has improved since those days.

That being said - I have seen some instruments since then that you MUST use VISA session class "GPIB:servant" that I could not use the generic VISA class "Instr" to control.  Arguably, these devices are not "Instruments" and they are not truely "GPIB" as they are not compliant with a IEEE-488 standard

[g_Ricky]

---

Dennis Knutson ha scritto:

VISA is a GPIB interface! Don't make such assertions about GPIB when you don't know anything about it or VISA. We all read your first post and are perfectly aware of your requirements.

---

Thanks for the clarification! I thought that VISA wasn't the right way to talk with a GPIB instrument. Yes you are right I actually don't know the GPIB and IEEE488 protocol as well as I should known tem but I'm looking at some information about that. So, after the discussion above, what is the best way, in term of functions to use that are exposed by labview, to develop the drivers that have to implement the comunication protocol to talk with a very old instrument via GPIB interface?

[smercurio_fc]

The best way is to read the articles that have already been linked so you get an understanding of the basic architecture. Then you need to sit down with the instrument manual and see what commands you need to implement. Create a VI for each command and put it in your instrument driver project. As noted, there are tons of examples in the Instrument Driver network, and the instrument driver for the 34401 even ships with LabVIEW.

[JÞB]

---

@g_Ricky wrote:

---

Yes you are right I actually don't know the GPIB and IEEE488 protocol as well as I should known them but I'm looking at some information about that.

---

Exactly why VISA was developed-  You need to know you can Write to the "instrument" Read from the instrument and (sometimes) Wait on events.  VISA knows how to run the bus, or wires or backplane or--- you get the idea.  You don't need to be a 488 guru to run the instrument you just need to read the manual, format the command strings properly and interperate the response strings.

---

So, after the discussion above, what is the best way, in term of functions to use that are exposed by labview, to develop the drivers that have to implement the comunication protocol to talk with a very old instrument via GPIB interface

---

Hints: some of us have probably used the instrument or one simillar to it and some of us write instrument drivers for a living.  Make and model?

[g_Ricky]

Thank you for the clarification. The instrument is made by Rohde&Schwarz and it is a SMHU 100kHz - 4320MHz. But you don't worry about the driver I'm able to make them, I read the article you've suggeted me and I've understood what I have to do, I simply thought that VISA wasn't the best method to apply to build the drivers for an instrument that has got only a GPIB port as interface!

[JÞB]

R&S will likely work very well with VISA.  They have a good history of engineering their gear with a good 488 implementation.  Command structure on the other hand-  Well just say SCPI is not high on their list. You'll really need the manual, ( and lots of post-it notes, a highlighter and a pencil.)

[g_Ricky]

Fortunately I have got the manual where are explained all the functions of the instrument. However, thank you a lot for the support in this matter....

I think the topic can be considered closed!