Ways to configure VISA properties associated with the EOS character in LabVIEW

Question

I am having a great deal of trouble reading consistently from an instrument (HP5328A Universal Counter) and am investigating the EOS character. In ibic, there are 6 properties of interest accessed through the ibconfig command. The following are the properties and their default settings:
Board level
- IbcEOSchar EOS character is 0 (zero)
- IbcEOSrd EOS is ignored during read operations
- IbcEOSwrt EOI not asserted when EOS sent
Device level
- IbcEOSchar EOS character is 0x0A (set in ibdev)
- IbcEOSrd EOS ignored during read operations
- IbcEOSwrt EOS not asserted when EOS sent
I would like to be able to programmatically set these at the beginning of my LabVIEW
program. The only relevant VISA properties in the INSTR or GPIB BoardInterface classes I can find are:
- Send End Enable
- Suppress End Enable
- Termination Character
- Termination Character Enable
The defaults in my LabVIEW program for both VISA classes mentioned are: Send End Enable is true; Suppress End Enable is false; Termination Character is \10 (Line Feed); and Termination Character Enable is false.
The only property I change is setting the Termination Character Enable to true for both classes. Is there anything else I can do with properties associated with the EOS char? Is there a property like the IbcEOSwrt that may have a part in generating a service request?
Just to confirm, the last two bytes of the instrument's ouput are \CR and \LF. I am using \LF as the EOS. Is this correct or should I be incorporating the \CR in the EOS somehow?
ANY input is appreciated,
Chris

Answer 1

Chris:
VISA "Termination Character" = NI-488 "IbcEOSchar"
VISA "Termination Character Enable" = NI-488 "IbcEOSrd"
VISA "Instr" or "GPIB Instr" = NI-488 "Device level"
VISA "GPIB BoardInterface" = NI-488 "Board level"
VISA cannot automatically add the termchar to the end of the written data (like IbcEOSwrt).
Unless you specifically need to do board-level communication, which is considered advanced, I suggest ignoring that, and sticking to the device-level calls.
If the instrument's ASCII data responses always end in \LF, then yes, just using \LF as the termchar is the correct thing. In fact, with most 488.2 devices you don't need to worry about the termchar, because the final byte of a response also contains EOI. EOI causes the driver to s
top reading from the instrument because it knows that is the end of the response.
You say you're having trouble, but you don't say what the symptom is. Is the read timing out? You might also want to use NI Spy to get a snapshot of what is going wrong.
I hope this helps some.
Dan Mondrik
Senior Software Engineer, NI-VISA
National Instruments