Using Assert EOI vs EOI on EOS

[ceetee]

given the ability to enable all the various EOS/EOI options in my application...

If I'm allowing assert EOI on matching EOS for ibeos, should I also still allow Assert EOI through ibeot?

Are the two ever used together as a 'fallback' measure or does the EOI on EOS 'overwrite' EOI through EOT?

[GPIB_Guru]

---

@ceetee wrote:
given the ability to enable all the various EOS/EOI options in my application...

If I'm allowing assert EOI on matching EOS for ibeos, should I also still allow Assert EOI through ibeot?

Are the two ever used together as a 'fallback' measure or does the EOI on EOS 'overwrite' EOI through EOT?

---

They are separate.

ibeot tells NI-488.2 to assert the EOI line with the last byte in the buffer.
ibeos (with your options) tells NI-488.2 to assert the EOI line whenever it is sending a byte across the bus that matches the EOS character.

If the last byte is the EOS character, both mechanisms will assert EOI. I generally recommend using ibeot and make sure that the EOS character is the last byte in the buffer. The times that ibeos is good if you need to send a string like "abc\ndef\nghi\n" where abc, def, and ghi are all commands to the device and you need them to be different messages, each with EOI asserted. Then, ibeos will assert EOI with the \n and the device will not know that you did all three in one ibwrt call (vs. ibwrt "abc\n", ibwrt "def\n", and ibwrt "ghi\n"). This is not typically a use case. It is more likely a use case for a non-controller application that was originally serial based and you are porting it to GPIB and don't want to change the host app that did terminate read requests on \n. However, as a controller app it has limited functionally. However, it it fits your use case, feel free to use it!

[ceetee]

Great. Thanks again for the input. It's been extremely helpful.