Protocole gpib

Bonjour,
je suis actuellement à la recherche du protocole GPIB au complet. En effet je n'arrive à trouver que des brides.
Voici mon problème:
Je souhaiterais récupérer les données passant sur un câble GPIB afin de les modifier (transformer un "a" en "b" par exemple). Pour cela j'utilise un microcontrôleur afin de détourner les 8 fils de données. Mais je me suis vite rendu compte que j'aurais besoin de plus (ATN, SRQ, etc ...) que j'avais relier directement sans passer par le micro.
Le problème reste au niveau de la reconnaissance de l'appareil. Quand avec MAX on lance un scan de reconnaissance le protocole a l'air bien spécifique (NDAC passe à l'état bas, etc ....) et je ne trouve pas beaucoup d'information sur le sujet.
Ma question est donc : Quelqu'un a t'il un lien vers un endroit ou est expliqué toutes les subtilités du protocole ?

Bonjour,
Vous trouverez plus d'informations sur Internet en general, GPIB etant une norme et non un standart uniquement National Instument.
Je vous conseille d'effectuer des recherches sur Internet avec la référence de la norme "IEEE 488" ou de voir directement sur le site IEEE.
Cordialement
Paolo_P
National Instruments France
#adMrkt{text-align: center;font-size:11px; font-weight: bold;} #adMrkt a {text-decoration: none;} #adMrkt a:hover{font-size: 9px;} #adMrkt a span{display: none;} #adMrkt a:hover span{display: block;}
Travaux Pratiques d'initiation à LabVIEW et à la mesure
Du 2 au 23 octobre, partout en France

Similar Messages

LabVIEW opening @ Bangalore, INDIA

Hi,
I have two labVIEW developer opening
* Experience: Minimum of 4+ years
* Should be able to handle the projects individually with minimal assistance.
* Engineering Degree is must
Position open for : Freelancers / Consultants / Full time employees.
Mail me your profile to [email protected]
Best regards,
Raja

Hello Friends,
Moog Aircraft Group, Bangalore is looking for LabVIEW and TestStand Engineers with 1 to 8 years of experience in test automation field. Please find the job description as mentioned below. If interested, please send the resumes to [email protected] or [email protected]
For more information regarding company and its product profile, please visit us at www.moog.com\aircraft
Job Location: Bangalore, India
Job Profile:
Design, Development and Configuration of Automated Test Equipment (ATE) for complex systems\sub-systems, simulation and control system environments.
LabVIEW and LabVIEW RT\FPGA proficiency (Desirable certifications include CLAD, CLD, CLA).
Familiarity with National Instruments Hardware Platforms. General Communication Protocols (GPIB, RS-232/485, EtherCat).
Exposure to Avionic Communication Protocols is an added advantage (ARINC, MIL1553) dSPACE®, Python, Matlab® \ Simulink® knowledge is an added advantage.
Aircraft systems/sub-system testing verification and validation environments.
Knowledge of Aircraft Actuation systems is an added advantage Process Standards (D0-178\CMMI) is an added advantage.
Note: 1) Please do not send the resumes, if you have attended the interview at Moog in last 6 months.
Regards,
Karthik SP

LabVIEW openings at Noida for Sankalp Semiconductor

JOB Description :
Technical Requirements: (in order of importance)
· Mandatory
o Prior Experience : 2-4 yrs
o Experience with labview and teststand
o Experience of GUI programming through labview for encoding the measurement procedures for atleast one analog interface (ADC/PLL/Power blocks)
o Experience of performing automation of measurement instruments like signal generators, oscilloscopes, power supplies etc.
o Familiarity with programming of NI hardware DAQs/protocols (GPIB, PCI, PXI)
· Good to have
o Block level understanding of circuits like LDOs, DC-DC converters etc.
o Experience of board bringup and debug.

Hello Sir/ Madam,
I am interested in doing work at Sankalp Semiconductor as a LabVIEW engineer.
I am CLAD (Certified LabVIEW Associate Developer) and have relevant experience..!!
Attached my Resume..!!
Attachments:
Aman Singhla Resume.pdf ‏445 KB

New Emerging Small Business - NI Alliance Partner - Servicing All of Florida

New National Instruments Systems Integrator now servicing the state of Florida. Our employees hold various NI certifications and come with several years of experience in LabVIEW and TestStand. No project too small. Look to us to outsource an entire test automation solution or simply use our associates during temporary times of increased capacity. Familiarity with custom protocols, GPIB, Ethernet, Serial, PXI, CRio, etc..
Check us out at www.mainlinetest.com and contact us via the following:
T: (321) 775-5866
E: [email protected]
Cheers!

HiWe are using Data ONTAP 8.2.3p3 on our FAS8020 in 7-mode and we have 2 aggregates, a SATA and SAS aggregate. I want to decommission the SATA aggregate as I want to move that tray to another site. If I have a flexvol containing 3 qtrees CIFS shares can I use data motion (vol copy) to move the flex vol on the same controller but to a different aggregate without major downtime? I know this article is old and it says here that CIFS are not supported however I am reading mix message that on the version of data ONTAP we are now on does support CIFS and data motion however there will be a small downtime with the CIFS share terminating. Is this correct? Thanks

Do we have driver available for Lake Shore Model 128 temperature sensor?

Do we have driver available for Lake Shore Model 128 temperature sensor? I want to make sure before we start writting our own drivers to communicate with this hardware.
Thanks,
Marivell Baez

Hi Marivell,
Take a look at ni.com/idnet. A quick browse found Lake Shore Cryotonics Temperature meters here: http://sine.ni.com/idnetwork/main/p/sn/n25:LM/sb/navsRel?q=lake+shore+temperature&x=0&y=0
This may not be what you are looking for though and consulting with your user manual for the appropriate commands to be sent would get you in the right direction for creating a complete set of Sub-VIs. Is this device a sensor or a meter controlled via an instrument protocol (GPIB, Serial, LAN, etc.)
PBear
NI RF

GPIB-VXI communication protocol

Hi:
I met a problem when i set up communication with GPIB-VXI machine. i don't konw which protocol it use when the computer talk to
VXI machine. And I know they connect each other with GPIB. But i wonder which protocol? And is it the same as one in the condition
that computer directly talk to instrucment with GPIB. Thanks very much if some one tell me!

Xiaoyiyi wrote: I think it is clear this time! Thanks!
Nope. You added absolutely no new information. Again, what is the instrument (make and model)? Do you have the manual?
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines

Instrument not recognized - computer too fast for AT-GPIB/TNT board

I have a problem with a potentiostat (PAR 283) connected to ISA AT-GPIB/TNT (not pnp) board. I recently upgraded to a motherboard with 1.8GHz AMD processor. Potentiostat is recognized by other software as "28PD", "28PE" or sometimes just some garbage characters, instead of "283". I'm using driver version 1.6 (1.7 could not recognize the board). In "Measurement&Automation" potentiostat doesn't respond to *IDN? query (error EAB0). FRA analyzer connected to the same board is recognized without a problem. None of the Windows programs can control potentiostat (it's not recognized as "283). One DOS program, however, is able to recognize and control the potentiostat. I tested the whole system with 166MHz compu
ter, and everything worked fine.
My operating system is Win98
Does anyone have idea what could solve the problem?
Thanks
Darko

I don't necessarily have an answer to your problem, but I want to assure you those usually these problems are with the instrument. The IEEE 488.1 standard defines a 3-wire interlocked handshake to prevent any problems due to computer/device speeds.
However, some devices violate this protocol. They rely on internal timing to determine when things should occur on the bus. For example, the talker asserts the DAV hardware line to indicate that data is valid on the bus. Following that, the listener is supposed to latch the data from the bus and then assert NDAC to indicate that it has taken the data from the bus. At the moment that NDAC has been asserted, the talker is allowed to modify the data lines since they have already been latched. However, some devices have noted in the past that their is usually X amount of time that passes from when NDAC is asserted until the data is removed from the wire. In order to improve peformance, they actually assert NDAC sometime before the data has been latched, assuming that the data will be there when they are actually ready to receive this data. In the case of moving to a faster computer, this data is actually staying on the bus for a shorter period of time than expected and the device receives garbage data.
A similar phenomenon can occur when the device is the talker where is violates the proper 3-wire handshake.
Note that not all failures are intential on the side of the device, it could be a legitimate bug.
Now that I have given a somewhat long-winded description of how problems like this can manifest, I can give you a few recommendations.
1) Obtain a GPIB bus analyzer and examine the handshake sequence to determine where the failure is.
2) Talk to the equipment manufacturer to see if they have any updates
3) Modify the bus timing in NI-488.2 from 500ns to 2ms. This is not likely to work since you are on the receiving end.
4) Try to procure a GPIB-PCII/IIA board. This is a slower board that overall responds to handshaking slower than the AT-GPIB/TNT board and may mask the problem.
5) Increase your cable length (including to "illegal" lengths such as 8m). This can add propegation delays that can mask this problem. I have seen work in teh past with troubled instruments.
Good luck.

Communicating between GPIB IEEE 488-1978 Instrument and LabView

Hi,
I'm currently trying to convert some old BBC BASIC Code into Labview 6.1.
The BBC Computer has a GPIB Comms Unit attached to it to communicate with an old Marconi Instruments Microwave Counter 2440 using GPIB IEEE 488-1978.
I am currently trying to get Labview to communicate with the Counter using GPIB 488 vis and a NI GPIB 488.2 Card but I'm not able to get anything out of the Counter or get MAX to even acknowledge the equipment exists.
I was wondering if anyone out there knows if it is possible to communicate with a GPIB IEEE 488-1978 instrument in Labview 6.1 (or any other LV Versions) and if it is, does anyone have a driver for the instrument (Marconi Instruments Microwave Counter 2440 circa 19
84) or having any helpful tips on the protocol for talking to a IEEE 488-1978 instrument.(I have some previous experience using VISA.)
Many Thanks in Advance for your help.
Sammy Mason

I have done this with several instruments. It is best to get a hold of the manual for this instrument and see what commands it uses.
MAX will not find this using the *IDN? query. In MAX, open the "Communicate With Instrument" window and type "ID?" (without the quotes), and hit query. You should get some basic information back from your instrument.
I use GPIB Read and GPIB Write most often. Your instrument probably doesn't support much else. Maybe Clear and Poll.
Be careful if you are using a newer, faster computer. There are Knowledge Bases and Discussion Forum topics that discuss the problems that can arise. To prevent these problems, I created my own Read and Write VIs. They just have a few milliseconds delay before the read or writ
e takes place
Attachments:
GPIB_Read_with_Delay.vi ‏37 KB
GPIB_Write_with_Delay.vi ‏35 KB

GPIB Data Transfer Rate

The maximum data rate in the original GPIB standard is about 1MByte/s. I have a microcontroller connected to a NAT9914 but I don't know what the transfer data rate is. For RS232 protocol, I could specify the baudrate, say 9600. Is it possible to specify the data rate for the NAT9914; say for example 500kByte/s? I read about the T1 delay, but not sure how to apply it if I need 500kByte/s data rate for example.
Any suggestion or comment would be greatly appreciated. Thank you.

Hello GPIB.user,
The speed of the data transfers will depend on two things.
1. The speed that the talker is placing data onto the bus.
2. The speed that the slowest listener is accepting data.
GPIB was made to be extremely robust. I'm sure you've read something about the handshaking lines (NRFD, DAV, NDAC) that make sure that all instruments get the data. These do not toggle until all listeners have entered the correct states. So if you have a very slow GPIB instrument on the bus that is actively listening (accepting data and toggling the listener handshaking lines NRFD and NDAC) it will slow down the entire communication process.
The T1 delay that you mentioned controls the minimum time that the talker will wait before placing data on the bus. Even if all listeners are ready for more data, it will wait T1 before sending another byte. However if one instrument is taking a long time to accept the data, the talker must wait until all instruments are ready for more data before sending another byte.
So, there is no way to specify the data rate except with the T1 delay, but it only controls part of the total picture.
I hope this helps,
Steven T.

How can a I solve and GPIB/VISA compatibility problem?

My Labview (version 5.1 on a Macintosh) application talks to a variety of instruments over GPIB. In one mode it communicates with both 1) a LakeShore 340 temperature controler (LS340) using VISA-based drivers and 2) a Linear Research LR-700 AC resistance bridge using low-level GPIB functions. My application can query these instruments a couple of times per second, usually without trouble. However, periodically (about once an hour) the GPIB Read will cease to work with the LR700 or any of the other instruments on the same bus, returning error 6 (I/O operation aborted). GPIB Write still works fine. Querying the LS340 when the system is in this state produces the VISA error Hex 0xBFFF003C (Insufficient system reso
urces to perform necssary memory allocation). Querying the LS340 a second time is successful, and thereafter GPIB Reads are also successful.
I think somehow the GPIB and VISA protocols are interfering with each other. (Although the data dependency requires that the VISA Write/Read be complete before the GPIB Write/Read begins, I am not opening/closing the VISA session with every iteration. The VISA session is opened on the first iteration and stored in a shift register.) However, the maddening infrequency of this problem makes it very difficult to troubleshoot. Any suggestions?

Hi Chris,
One suggestion;
Write two seperate test routines that each use only one method or the other.
Test the H*&#$ out of each to attempt to determine if the issue is associated with the high level or the the low.
Ben
Ben Rayner
I am currently active on.. MainStream Preppers
Rayner's Ridge is under construction

PMC-GPIB, what memory is accessable by the customer

I need to know what memory is on the PMC-GPIB. Size and if it is volatile or NV. If some memory is user accessable, if so how can memory be cleared, power down?

Hello,
Are you talking about FIFOs that buffer received data before it is transferred across the PCI bus? I believe what you will eventually care about are data transfer rates; it should allow for maximum GPIB transfer rates (whether using the high speed or standard protocol). The information on NI's website for this product is at (also see links to manuals, etc. at this page):
http://sine.ni.com/apps/we/nioc.vp?cid=1254〈=US
Best Regards,
JLS
Best,
JLS
Sixclear

How can I solve a GPIB/VISA compatibility problem?

My Labview (version 5.1 on a Macintosh) application talks to a variety of instruments over GPIB. In one mode it communicates with both 1) a LakeShore 340 temperature controler (LS340) using VISA-based drivers and 2) a Linear Research LR-700 AC resistance bridge using low-level GPIB functions. My application can query these instruments a couple of times per second, usually without trouble. However, periodically (about once an hour) the GPIB Read will cease to work with the LR700 or any of the other instruments on the same bus, returning error 6 (I/O operation aborted). GPIB Write still works fine. Querying the LS340 when the system is in this state produces the VISA error Hex 0xBFFF003C (Insufficient system resource
s to perform necssary memory allocation). Querying the LS340 a second time is successful, and thereafter GPIB Reads are also successful.
I think somehow the GPIB and VISA protocols are interfering with each other. (Although the data dependency requires that the VISA Write/Read be complete before the GPIB Write/Read begins, I am not opening/closing the VISA session with every iteration. The VISA session is opened on the first iteration and stored in a shift register.) However, the maddening infrequency of this problem makes it very difficult to troubleshoot. Any suggestions?

Hi Dan,
I'm trying to follow your suggestion, but I can't get the VISA upgrade to function. I downloaded the NI-VISA 2.6 full development installer, which recommends uninstalling the prior version first. I couldn't find a good way to do this (the documentation is no help), so I ended up just reinstalling the entire Labview 5.1 without the VISA package. But even this approach (I tried several others) doesn't work - when I run VISA commands from within Labview after the VISA 2.6 install, I get 'unknown system error'. Any suggestions?
Chris

GPIB-ENET

We have a GPIB-ENET box and are trying to interface with it on WinXP. I've downloaded and installed the latest drivers (2.2) but when I setup the device in MAX it sees three but only successfully identifies 1 of them (the first one). I even set it up as a GPIB-ENET/100 device and got the same results. I thought that maybe the driver was incorrect so I came back and checked and found this note for the GPIB-ENET interface:
Note 4: The IP Assign Utility for the GPIB-ENET must be performed on Windows 98/Me or Windows 2000. After the IP address is successfully assigned, the GPIB-ENET can be accessed on Windows XP.
How can I assign the IP address in another system when XP is all that is on the comp? Am I reading this wrong or does this basically say you have to setup and install the device then upgrade you computer to XP to get it working in XP. Obviously this creates some problems. One other thing, I've setup the IPAssign Protocol on my network settings but when I try to run the application I get a message telling me I need to setup the IPAssign protocol and instructions on how to do it.

Gary,
The GPIB-ENET assign utility can only be performed on those operating systems. You would have to go to a machine with one of those OSs installed to set the IP address.
GPIB-ENET on WinXP
Craig H.

Can you mix VISA drivers & GPIB functions?

Can you mix VISA instrument drivers & GPIB I/O functions on the same block diagram? I am using VISA drivers to control a LeCroy LT344L oscilloscope - they are working fine, but I need to perform a query of some specific scope parameters and the VISA drivers cannot provide the exact command that I need. I used the GPIB send and receive for these query commands, but now am getting an error message:
"Error -1073807265 occured at VISA Write in LCDSO Utility Default Instrument Setup.vi->LCDSO Initialize.vi->ReadMeas.vi Possible reasons: VISA: (Hex 0xBFFF005F) No listeners condition is detected (both NRFD and NDAC are deasserted).
Is there a possible confict when both these protocols are used together? Thanks fo
r any help or insight.
Mike Selecky

I just want to clarify a few things about mixing VISA and GPIB.
If all your I/O is done on the diagram with VISA functions and GPIB
functions, you should be okay. LabVIEW has code that tries to keep the two
from stomping on each other. You have to know what you're doing--you can't
have two VIs trying to control the instrument at once, for example.
This is _not_ true for C-based instrument drivers (aka, VXIPNP,
including IVI). We have no protection between the VISA calls inside those
drivers and the builtin functions. If one is in progress and you try to use
the other, you'll get an error. One way to demonstrate this would be to
start a GPIB Read (which is asynchronous by default, meaning that LabVIEW
starts the Read and then looks for other stuff to do),
then use an
instrument driver for a device on the same bus. The instrument driver will
return an error. You just have to be using the same bus--it doesn't matter
if you use the same device.
Fortunately, this doesn't come up that often in practice. When needed,
there are workarounds--e.g., keeping all GPIB I/O in a single thread (at
least per bus) and using synchronous VISA and GPIB Reads/Writes. Yes, we're
working on ways to make this less of an issue, but I won't go into details
yet.
Brian Powell
Sr. Group Manager
LabVIEW R&D
[email protected]

GPIB Configuration

Bonjour,
J'ai un problème pour connecter mon appareil(SOLARTRON 1250) à mon PC à l'aide d'un GPIB. En effet, sur MAX j'arrive à detecter l'appareil mais lorsque j'essaye de communiquer avec lui cela ne marche pas. De plus, d'autres anomalies me perturbe: -MAX detecte 2 appareils alors que j'en est connecté que un
-"Identification" : Apparament il y a un problème d'identification???
-Problème de communication voila ce que me dis MAX quand j'appui sur "query":
"iberr = EABO
EABO indicates that an I/O operation has been canceled, usually due to a timeout condition after a GPIB read. Before reading from the instrument, verify that the GPIB command you are sending is understood by your device and instructs it to place data in its output buffer. For information on your device's command syntax, consult the instrument manufacturer's user documentation."
Je pense que l'un des facteurs de ces problèmes sont l'état des boutons du gpib(definissant l'adresse de l'appareil et son mode read, write ....) vous pouvez voir ces boutons en pièces jointes.
Merci d'avance pour toutes aides
Attachments:
Probleme configuration GPIB.JPG ‏121 KB
Boutons.JPG ‏12 KB

C'est etrange qu'il y a deux ports GPIB sur l'instrument. Cependant, il semble que l'instrument supporte IEEE 488.1 ou plus vieux.
Parfois, lorqu'on envoie une commade a l'instrument, elle necessite pas une reponse. Donc si tu essais d'obtenir une reponse pour une commande de configuration, tu receveras un message d'erreur.
Le SCPI est un protocol provenant des annees 1990, alors seuls les intruments plutot recent supportent les nouvelles commandes (standard). Voici une petite description (ci-dessous). Malheureusement en anglais.
Essais d'envoyer une commande de configuration sans point d'interrogation (?) et verifie si l'instrument a changer de configuration selon la commande envoyer.
RayR
SCPI standard:
IEEE 488.2 instruments are easier to program because they respond to common commands and queries and use standard message exchange protocols and data formats. It defines precisely the format of commands sent to instruments and the format and coding of responses sent by instruments. Before SCPI, each instrument manufacturer developed its own command sets for its programmable instruments.

Protocole gpib

Similar Messages

Maybe you are looking for