Mode meaning in GPIB write

Hi, All,
I have a question when I wanna use GPIB write function. I am not clear about what those modes meaning like EOI, CR or LF in the help.
0
Send EOI with the last character of the string.
1
Append CR to the string and send EOI with CR.
2
Append LF to the string and send EOI with LF.
3
Append CR LF to the string and send EOI with LF.
4
Append CR to the string but do not send EOI.
5
Append LF to the string but do not send EOI.
6
Append CR LF to the string but do not send EOI.
7
Do not send EOI.
In fact, I wanna increase voltage supply by 5V every 5s. I wrote a program in the attached files. Pls help me to see if it is logical.
Thanks.
Solved!
Go to Solution.
Attachments:
3631A power supply.vi ‏6 KB

The mode has to do with how a GPIB write is terminated. The standard for quite a few years has been to assert the EOI (End or Identify) management line when the last data byte has been sent. The other modes are there to support old instruments before the current standard was adopted. Some of them required a CR (carriage return), LF (line feed), both, etc. Your instrument manual should explain what, if any additional termination is required. The current standard was adopted in 1987 so your instrument would have to older than you is my guess if you need those special modes.
Your VI should work okay with the addition of the wait and wiring up the N terminal of the for loop but is not the most elegant. First, instead of the GPIB primitives, you should use the VISA functions. Instead of wiring the iteration terminal, you can use a shift register and a add function with an increment. You can use a while loop and stop it when it reaches a final value. Instead of the concantanate string function, I prefer to use the Format Into String function.
If you keep this code, get rid of the second GPIB address string control. Thetimeout function of the GPIB write is not related to a trigger and you can leave it unwired and just use the default.
Attachments:
3631A power supply_mod.vi ‏10 KB

Similar Messages

Gpib write or read sometimes hogs cpu

I have written a simple vi to communicate and
control a Stanford Research SR640 programmable filter. It does a
series of gpib writes and reads to get and set various controls on the
instrument, and it works very well. The problem comes when I try to
call it from a more complex vi that controls the entire experiment.
Once the sr640 vi is linked into the big vi, it takes 10-20 seconds for
the sr640 vi to return and it hogs the cpu, making even the mouse
unresponsive, Windows task manager stops updating, etc. This happens
even when running the simple sr640 vi directly from its front panel
with no other vi's executing. In "lightbulb" mode, I can see that
occassionally, the gpib write or read icons (from traditional gpib
pallette) take a long time to return, and the cpu goes to 100%.
If
I remove the complex calling vi from memory, the problem goes away, ie
the sr640 vi runs fine. If I load the big vi back into memory, I
reproducibly get the bad behavior when running the sr640 vi. Note that the big vi does not need to be running to cause trouble, only be loaded in memory. If I
delete the sr640 vi from the big vi, i.e. it is no longer called from
the big vi, the sr640 vi again runs fine.
Any idea what might be happening and how to go about debugging this?
Thanks,
Bob Shelby

Thanks for the reply.
Attached is the SR640 vi and a calling vi that works just fine.
Bob
Attachments:
srs_filter_setparms.vi ‏42 KB
test_sr640.vi ‏17 KB

Keithley 6517B GPIB Write Error 7

Hello,
I have a Keithley 6517B running and communicating with PC through GPIB. The program was initially running fine, and giving the current-noise signal against applied voltage (as programmed). But now when I run the program , it is giving an error that arises at the 6517 Reset/Preset.vi -
Error 7 occurred at GPIB Write in Keithley 6517A Reset / Preset.vi
How do I get rid of this error. I don't understand how suddenly an error arised when I changed nothing in the program or settings of the keithley. The keithley is configured at GPIB address 27.
I am attaching the main program and the sub.VI llb file .
Now when I run the main program, the graph does not show any current or noise signal, but it shows a straight line plotted along '0' along the x-axis (that is, against time or voltage)
Please help.
Best Regards,
Poulomi Das.
Institute for Microsystems Engineering.
University of Freiburg.
Freiburg, Germany.
Attachments:
VI Measurements_v4.vi ‏45 KB
kei6517v6.llb ‏1213 KB

Hello Mike,
I was on leave hence the late reply. I have attached the entire LV main vi with the sub VIs llb file to the very first message on this post. I have attached them again to this message.Do you mean something else?
Best Regards,
Poulomi Das.
Institute for Microsystems Engineering.
University of Freiburg.
Freiburg, Germany.
Attachments:
VI Measurements_v4.vi ‏45 KB
kei6517v6.llb ‏1213 KB

GPIB write error code 6, how to do proper wait in GPIB comm

Hi!
I use a Keithley MUX and a DVM to measure different values in my system, including 4 wire resistance. My project runs for several hours without any problem, but last night I have got an error after approx. 8 hours runtime. My error out in the main vi shows the following error:
GPIB Write in A_4Wire_resMUX_2!1,2!3,2!5_new.vi Error code 6.
I have attached this subvi, as you can see, I have put a while loop in the subvi, to give enough time for the 4Wire measurement to be done. But of course maybe another GPIB write function crashes in the subvi, not the one after the while loop.
I have 2 questions:
1. what is the best way to do error handling in GPIB comm., so I could see on my final error out what element caused the problem in this certain subvi?
2. Can someone show me what I could do better in this subvi, to avoid possible GPIB errors?
Its just guessing, but I think the error comes from that I may not give enough time to the GPIB device to perform an action, so the next GPIB write crashes?
plus info: WindowsXP, LabView 2010 Full version
Thanks very much for advice and help!
Solved!
Go to Solution.
Attachments:
A_4Wire_resMUX_2!1,2!3,2!5_new.vi ‏35 KB

2001 driver
7001 driver
Now that you have a modern version of LabVIEW why are you not taking advantage of the instrument driver network? VISA is wonderful and the raw 488.2 primitives should be considered "obsolete".
Since you did not use the specific instrument driver vi's we can't tell which write to what device generates the error you are seeing.
So to specifically answer Q1. Use the Driver's found on the instrument driver network- they are tested and structured in ways that assist in debugging your application and take advantage of powerful features in VISA..
And 2) (see #1) and change the stacked sequence into a state machine
Jeff

PNA Guided Calibration: GPIB write error in for loop

Hi,
I have a LabVIEW program that creates a Guided Power Calibration on a PNA.
After initializing everything properly, I have a for loop that loops through all the manual steps that the user must go through (ex: Connect Channel A of Power meter to Port 1" "Connect male Short to port 1" etc).
The problem is, the program displays an error at the first command: sens:corr:coll:guid:acq STAN1
I says there is an error with the GPIB Write function.
Here are the commands I send:
SYSTRES
DISPlay:WINDow2TATE ON
CALCulate2ARameterEFine:EXT 'MyMeas',S21
DISPlay:WINDow2:TRACe1:FEED 'MyMeas'
CALC1AREL 'CH1_S11_1'
SENS:FREQTAR 2e9
SENS:FREQTOP 4e9
SENSWEOINTS 3
SENS:CORR:COLL:GUID:CONNORT1 'APC 2.4 male'
SENS:CORR:COLL:GUID:CONNORT2 'APC 2.4 male'
SENS:CORR:COLL:GUID:CKITORT1 '85056D'
SENS:CORR:COLL:GUID:CKITORT2 '85056D'
SENSe:CORRection:COLLect:GUIDedSENsor1 ON
SYSTem:COMMunicateSENsor gpib, "13"
SENSe:CORRection:COLLect:GUIDedSENsor1OWer:LEVel -20
sens:corr:coll:guid:init
sens:corr:coll:guid:steps?
//for loop from 1 to total_number_of_steps
sens:corr:coll:guid:desc? <step#>
sens:corr:coll:guid:acq STAN<step#>
The program quits right at the first step, when I send "sens:corr:coll:guid:acq STAN1", although the command is executed.
Also, the VBScript with the same commands works fine.
Can anybody help me? I've been stuck for a while now.
I attached the block diagram of the for loop.
Thanks in advance,
Nicolas
Attachments:
Guided cal for loop.vi ‏27 KB

Sending SENS:corr:coll:guid:acq STAN1 \n gives me a different error: -101 "Invalid Character".
From my different attempts at figuring this out, I thought the problem would come from LabVIEW, since the vbscript with the same commands works on the PNA.
I also modified the for loop because I thought each iteration should be linked to the previous one with the error wire (see attached).
I still have the same issue, only the first iteration is executed, then the program quits.
Attachments:
Guided cal for loop.vi ‏28 KB

GPIB Write to multiple address

How do you write commands to multiple instruments? I get Error 6-GPIB
Controller not in charge when I use GPIB Write consecutively in block
diagram. Is there an easy way?
Attachments:
Multiple IO.llb ‏25 KB

Hi Rig
see attached llb
Its quick and 'dirty' it assumes you already know instrument addresess's!
Note use of sequence -this can be improved by either state machine or
simply by connecting vi in series using error connection as link.
No error detection coding has been added. This could cause problem with regard to time out etc.
Basically it should give you inspiration.
xseadog
Attachments:
Basicinstr.llb ‏204 KB

Error 6 in GPIB Write

Hi
I have a LabVIEW code acting as a driver for an EG&G 5210 lock-in amplifier. Essentially I am using the GPIB write vi to send a string to the amplifier.
I have been trying to de-bug my code for a while.
The problem is, I have split the code into each constituent control and each separate part (e.g. changing phase or filter type etc.) works absolutely fine on its own. Also, when I combine several of these into one string it also works fine, apart from the addition of the very last part.
At this point I get error 6 "LabVIEW: Generic file I/O error. NI-488: I/O operation aborted."
I cannot then check any of the others parts work after this point since I only get the same error, even just testing one constiuent part (which had been working well beforehand)
I am using Labview 2011 with an NI GPIB-USB-HS with the previously mentioned EG&G 5210 amplifier.
Any help is greatly appreciated.
Please find attached my LabVIEW if required.
Jordan B
Attachments:
test 3.2.vi ‏28 KB

My guess is that when you are stringing the commands together, you aren't waiting long enough for at least one command to complete. I can't see the VI because of the ancient version of LV that I have at work, but if the instrument is SCPI compliant, consider appending ;*OPC? to each command that isn't already a query. This will turn that command into a query, so you execute a read (of a couple of bytes) and it will wait until the instrument has completed the command.
Read the instrument manual to make sure that the commands you are going to modify in this fashion are compatible with the *OPC? command.
Bill
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.

L'erreur 3 s'est produite à : GPIB Write

Bonjour,
Je suis actuellement en stage et je viens, comme indiqué dans le titre, de rencontrer cette erreur : L'erreur 3 s'est produite à : GPIB Write.
Cette erreur apparaît dans un sous VI de mon programme principal. J'ai fait tourner un grand nombre de fois le sous VI en question seul avant de l'incorporer à mon programme principal et je n'ai jamais rencontré cette erreur auparavant.
Elle n'apparaît que depuis que j'ai couplé ce sous VI à mon programme principal.
L'appareil que je pilote et qui pose problème est un multimètre HP 3458A. J'ai bien vérifié l'adresse que je lui associe elle est correcte. Si vous jetez un coup d'oeil aux pièces jointes, l'erreur se produit lors de la dernière Visa session write ou j'envoie la commande MEM FIFO.
Encore une fois l'erreur ne se produit que dans mon programme principal, je pense qu'il est question de rapidité d'accès à la mémoire de l'instrument mais je ne suis pas sûr et je n'ai aucune idée de solution possible étant novice.
Si je n'ai pas été clair ou assez précis je m'en excuse d'avance et je tacherais de l'être davantage si vous prenez le temps de m'aider!
Merci d'avance.
Benjamin.
Pièces jointes :
Sous_VI.vi ‏161 KB
VI_Principal.vi ‏536 KB

Merci à toi de prendre le temps de me répondre
Je pense avoir trouver la cause du problème, je travaillais sur réseau (grosse entreprise etc.) au final j'ai copié tous mes fichiers sur disque et bizarrement il n'y a plus de temps de chargement du programme tout se fait instantanément... Et l'erreur ne se produit plus. Sachant que le réseau rame depuis 3-4 jours est ce que le problème pourrait venir de là?
Sinon oui je me suis effectivement donné beaucoup de mal ^^ et je sais que mon programme est loin d'être optimal c'est sur quoi il me reste à travailler =D
Je te renvoie les deux VI au cas ou, les deux sont indépendants l'un de l'autre.
Pièces jointes :
TEST_RELAIS_TEMPERATURE_CYCLE.vi ‏536 KB
Sous_VI.vi ‏161 KB

What it means to me "WRITE 'sivanantham'(001).

Hi There,
See below. What it means to me "WRITE 'sivanantham'(001)." ?. Please explain.
<begin>
REPORT ZDEMO_SUBS_USING_EXIT.
WRITE 'sivanantham'(001).
"WRITE 'sivanantham'(01).
"WRITE 'sivanantham'(1).
</end>
thanks
siva

>1. Is it a variable.
>If so, why I am unable to see it in debugger like
>any other variable ?
>You might say, It is an ID to an a Text element with no variable name.
yes it is not a variable, this number pointing to a Textelement.
>If so,
>What is the purpose of having Text ID ?
>How do I refer this text ID from some other statement of the program to find what is in there
check these you get clear picture..
http://help.sap.com/saphelp_nw70/helpdata/en/e3/9609f6eb0711d194d100a0c94260a5/content.htm
http://help.sap.com/saphelp_nw70/helpdata/en/1e/401ad6ee3c11d1951d0000e8353423/frameset.htm
http://help.sap.com/saphelp_nw04/helpdata/en/e3/9609f6eb0711d194d100a0c94260a5/content.htm

Error 6 @ GPIB Write

Hello!
I'm currently working on a flash photolysis instrument using labview. Recently I have upgraded the computer and now have error 6 occuring randomly throughout the program. I've tracked the errors down to the GPIBwrite command which happens to be used throughout the program. After doing some reading and asking a few questions, I'm pretty sure its due to race conditions but have been unable to fix the problem (Probably due to me being a novice with Labview). Just wondering if any pros out there could lend some assistance, I've attached a jpeg of the problem area!
Thanks!
Attachments:
Helpme.jpg ‏63 KB

Updated my NI-488 driver and I've narrowed down this error a little more, but it is beyond my understanding. If I probe the Write error in, and Write error out the program will run fine for an indefinate amount of time(Pic1) but as soon as I remove the probes I'll be lucky to get 30 repetitions without Error6 coming back into my life(pic2). Really don't know what to make of this...
Attachments:
Error_1.jpg ‏202 KB
Error_2.jpg ‏193 KB

Error 14 ocurred at GPIB write, labview cant add resource

I am using LabView 2009 to control a research system contains Lakeshore 331S and Keithely 2425, it was work probably , but recently I am receivng an error message:
Error 14 ocurred at GBIB write, LabView cant add resource

Hello baalbiss,
Which version of the 488.2 driver do you have installed? Just to confirm, you are able to communicate with the instrument through MAX, but not through LabVIEW? Did you recently upgrade to LabVIEW 2009?
Thanks
Ryan T
National Instruments
Applications Engineer

IPod Classic - 80GB - What does Recovery Mode mean?

Every time I connect my new iPod Classic to my computer I get the message "iTunes has detected an iPod in recovery mode. You must restore this iPod before it can be used with iTunes." I've restored the iPod several times and no luck. I welcome advice. Thank you.

I may have found the answer to my question in another thread.

HT201412 what unknown error occurred (-18) in recovery mode mean?

I restored my phone after i saw the apple logo constantly flashing on and off my screen. It worked for another 3 hrs then back to the same process and will not restore but the unknown msg keeps popping up on iTunes.

Please Get the iPhone User Manual for iOS 5
iPhone and iPod touch- Unable to update or restore
iTunes 10 for Mac- Update and restore software on iPod, iPhone, or iPad

CD WRITING MODES-DISC AT ONCE?

Hi, listen I need your help guys; HOW DO I WRITE A CD IN A "DISC-AT-ONCE" MODE ON A MAC OR IN WAVEBURNER FOR THAT MATTER?
I know how to do it on a PC but I can't seem to find this option on my G5?
You see the thing is I just spoke to a CD distribution factory and they told me that I must resend them the master due to the fact that the CD is written on a track to track basis and that i need to write it as in a "disc-at-once" mode, meaning the laser writes the audio never removing the laser fromt he disc, can ayone help? thanks

Apostol, Waveburner is a separate application that comes with Logic and will be in your applications folder.
From your Waveburner manual:
"What Is WaveBurner?
WaveBurner is an application that lets you assemble, master, and burn audio CDs using a SuperDrive or CD burner supported by Mac OS X. Audio CDs created with WaveBurner can be played back on any audio CD player, and can be used as premasters to produce CDs in quantity. WaveBurner supports all Red Book options for CD audio data storage. You can add up to the maximum 99 tracks and 99 subindexes per track allowable by the Red Book standard, include ISRC codes for each track, set copy prevention and pre-emphasis flags for each track, and add UPC/EAN codes for the CD.
WaveBurner also supports the CD TEXT standard, allowing you to add text information readable on any CD TEXTcompatible CD player. You create a CD by adding audio files to a WaveBurner project. The audio files appear as regions in the project window, where you can edit and arrange them graphically or numerically. You can add effects to both individual regions and the overall project using the included plug-ins or using Audio Units plug-ins you install on your computer. You can edit pauses between tracks and add fade-ins, fade-outs, and crossfades. When your project is complete, you can burn the project to a CD."

Failure modes in TCP WRITE?

I need help diagnosing an issue where TCP communications breaks down between my host (Windows) and a PXI (LabVIEW RT 2010).
The bottom-line questions are these:
1...Are there circumstances in which TCP WRITE, given a string of say, 10 characters, will write more than zero and fewer than 10 characters to the connection? If so, what are those circumstances?
2...Is it risky to use a timeout value of 1 mSec? Further thought seems to say that I won't get a 1000 uSec timeout if we're using a 1-mSec timebase, but I don't know if that's true in the PXI.
Background:
On the PXI, I'm running a 100-Hz PID loop, controlling an engine. I measure the speed and torque, and control the speed and throttle. Along the way, I'm measuring 200 channels of misc stuff (analog, CAN, TCP instruments) at 10 Hz and sending gobs of info to the host (200 chans * 8 = 1600 bytes every 0.1 sec)
The host sends commands, the PXI responds.
The message protocol is a fixed-header, variable payload type: a message is a fixed 3-byte header, consisting of a U8 OpCode, and a U16 PAYLOAD SIZE field. I flatten some structure to a string, measure its size, and prepend the header and send it as one TCP WRITE. I receive in two TCP READs: one for the header, then I unflatten the header, read the PAYLOAD SIZE and then another read for that many more bytes.
The payload can thus be zero bytes: a TCP READ with a byte count of zero is legal and will succeed without error.
A test starts with establishing a connection, some configuration stuff, and then sampling starts. The 10-Hz data stream is shown on the host screen at 2-Hz as numeric indicators, or maybe selected channels in a chart.
At some point the user starts RECORDING, and the 10-Hz data goes into a queue for later writing to a file. This is while the engine is being driven thru a prescribed cycle of speed/torque target points.
The recording lasts for 20 or in some cases 40 minutes (24000 samples) and then recording stops, but sampling doesn't. Data is still coming in and charted. The user can then do some special operations, related to calibration checks and leak checks, and those results are remembered. Finally, they hit the DONE button, and the whole mess gets written to a file.
All of this has worked fine for several years, but as the system is growing (more devices, more channels, more code), a problem has cropped up: the two ends are occasionally getting out of synch.
The test itself, and all the configuration stuff before, is working perfectly. The measurement immediately after the test is good. At some point after that, it goes south. The log shows the PXI sending results for operations that were not requested. The data in those results is garbage; 1.92648920e-299 and such numbers, resulting from interpreting random stuff as a DBL.
After I write the file, the connection is broken, the next test re-establishes it, and all is well again.
In chasing all this, I've triple-checked that all my SENDs are MEASURING the size of the payload before sending it. Two possibilities have come up:
1... There is a message with a payload over 64k. If my sender were presented with a string of length 65537, it would convert that to a U16 of value 1, and the receiver would expect 1 byte. The receiver would then expect another header, but this data comes instead, and we're off the rails.
I don't believe that's happening. Most of the messages are fewer than 20 bytes payload, the data block is 1600 or so, I see no evidence for such a thing to happen.
2... The PXI is failing, under certain circumstances, to send the whole message given to TCP WRITE. If it sent out a header promising 20 more bytes, but only delivered 10, then the receiver would see the header and expect 20 more. 10 would come immediately, but whatever the NEXT message was, it's header would be construed as part of the payload of the first message, and we're off the rails.
Unfortunately, I am not checking the error return from TCP write, since it never failed in my testing here (I know, twenty lashes for me).
It also occurs to me that I am giving it a 1-mSec timeout value, since I'm in a 100-Hz loop. Perhaps I should have separated the TCP stuff into a separate thread. In any case, maybe I don't get a full 1000 uSec, due to clock resolution issues.
That means that TCP WRITE cannot get the data written before the TIMEOUT expires, but it has written part of it.
I suspect, but the logs don't prove, that the point of failure is when they hit the DONE button. The general CPU usage on the PXI is 2-5% but at that point there are 12-15 DAQ domain managers to be shutting down, so the instantaneous CPU load is high. If that happens to coincide with a message going out, well, maybe the problem crops up. It doesn't happen every time.
So I repeat the two questions:
1...Are there circumstances in which TCP WRITE, given a string of say, 10 characters, will write more than zero and fewer than 10 characters to the connection? If so, what are those circumstances?
2...Is it risky to use a timeout value of 1 mSec? Further thought seems to say that I won't get a 1000 uSec timeout if we're using a 1-mSec timebase, but I don't know if that's true in the PXI.
Thanks,
Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com
Blog for (mostly LabVIEW) programmers: Tips And Tricks
Solved!
Go to Solution.

There are a couple of issues at play here, and both are working together to cause your issue(s).
1) LV RT will suspend the TCP thread when your CPU utilization goes up to 100%. When this happens, your connection to the outside world simply goes away and your communications can get pretty screwed up. (More here)
Unless you create some form of very robust resend and timeout strategy your only other solution would be to find a way to keep your CPU from maxing out. This may be through the use of some scheduler to limit how many processes are running at a particular time or other code optimization. Any way you look at it, 100% CPU = Loss of TCP comms.
2) The standard method of TCP communication shown in all examples I have seen to date uses a similar method to transfer data where a header is sent with the data payload size to follow.
<packet 1 payload size (2 bytes)><packet 1 payload..........><packet 2 payload size (2 bytes)><packet 2 payload.......................>
On the Rx side, the header is read, the payload size extracted then a TCP read is set with the desired size. Under normal circumstances this works very well and is a particularly efficent method of transferring data. When you suspend the TCP thread during a Rx operation, this header can get corrupted and pass the TCP Read a bad payload size due to a timeout on the previous read. As an example the header read expects 20 bytes but due to the TCP thread suspension only gets 10 before the timeout. The TCP Read returns only those 10 bytes, leaving the other 10 bytes in the Rx buffer for the next read operation. The subsequent TCP Read now gets the first 2 bytes from the remaining data payload (10 bytes) still in the buffer. This gives you a further bad payload read size and the process continues OR if you happen to get a huge number back, when you try to allocate a gigantic TCP receive buffer, you get an out of memory error.
The issue now is that your communications are out of sync. The Rx end is not interpeting the correct bytes as the header thus this timeout or bad data payload behavior can continue for quite a long time. I have found that occasionally (although very rare) the system will fall back into sync however it really is a crap shoot at this point.
I more robust way of dealing with the communication issue is to change your TCP read to terminate on a CRLF as opposed to the number of bytes or timeout (The TCP Read has an enum selctor for switching the mode. In this instance, whenever a CRLF is seen, the TCP Read will immediately terminate and return data. If the payload is corrupted, then it will fail to be parsed correctly or would encounter a checksum failure and be discarded or a resend request issued. In either case, the communications link will automatically fall back into sync between the Tx and Rx side. The one other thing that you must do is to encode your data to ensure that no CRLF characters exist in the payload. Base64 encode/decode works well. You do give up some bandwith due to the B64 strings being longer, however the fact that the comm link is now self syncing is normally a worthwhile sacrifice.
When running on any other platform other than RT, the <header><payload> method of transmitting data works fine as TCP guarantees transmission of the data, however on RT platforms due to the suspension of the TCP thread on high CPU excursions this method fails miserably.

Mode meaning in GPIB write

Similar Messages

Maybe you are looking for