asynchronous vs. synchronous gpib read/write

[Brian_Beal]

I have read the material for this subject on this site, but I still don't have a good idea of the advantages of one verses the other. Can anyone explain it simply?

[ndiamond]

If your needs are met equally well by either version, then you don't have to worry about this at all.

If the synchronous versions meet your needs, then surely they're easier to understand and easier to use. But if you find sometimes you need more detailed control of the interface or operations, then you have to switch to the asynchronous versions. For example, I want to allow the user to click a button to abort an operation which might be in progress or might only be waiting for it to start, etc. ibstop() can abort an asynchronous operation but cannot abort a synchronous one.

If you predict that you might need the asynchronous versions someday, then it is better to start with the asynchronous functions in the first place. To switch from synchronous to as
ynchronous later will require some redesign and a lot of nuisance.

[Brian_Beal]

Thanks for the answer. My GPIB communications run better using synchronous operation. Are you saying that synchronous operation ties up the entire processor, and nothing else can happen?

[Alan_L]

Brian,

Please follow this link to a discussion containing a very thorough explaination of synchronous / asynchronous communications. This should be very helpful to you.

Regards,
Alan
Applications Engineer
National Instruments

[GPIB_Guru]

No. A synchronous operation will tie up GPIB communication, but it does not cause any additional processor usage. In fact, it is frequently more efficient with the processor since you don't have to poll to find out if the I/O is completed.