How to send commands and data upon request

[paw510]

---

These commands you listed what library they are from? 

Currently i am working with C# libraries, and couldnt find a "SendDataBytes" command that doesnt send "UNL" before sending  the data.

I put the reference manual where you will find these functions in attached file.  This is for C/C++ and  the NET version differs slightly, you will find the corresponding docs on NET 488.2 implementation here :
https://documentation.help/NI-488.2/NETProgInstructions.html
https://zone.ni.com/reference/en-XX/help/370628F-01/mstudiowebhelp/html/f81efe43/

The low-level functions are in the NationalInstruments.NI4882.Board class :

SendCommands is equivalent to SendCmds, and there are overloaded versions of Write and ReadByteArray equivalent respectively to SendDataBytes and RcvRespMsg. But I never used those, in fact, since as you might have noticed the standard C library is much better documented I often prefer to directly call the unmanaged functions (via Dllimport) from my C# code rather than to try the incompletely documented NET wrapper.  (This also allows me to use non-NI cheaper gpib boards). 

---

Also the device i am trying to communicate with  doesnt use the EOI line, it sends me back data until i rise the ATN line with a "UNT" command to stop it.

This is not the best way to do it because you don't know how many characters your device wants to send. If you issue an UNT before the transfer is done there will be some data remaining in the device's IO buffer so that it can behave badly on subsequent commands (unless you follow UNT by a low level DCL command to prevent this by flushing the buffer). If your device cannot set EOI it means it uses some termination character, you should configure the RcvRespMsg function call so as to stop after a termination character is received.

after the MTA 18 am i pulling the data or the device is pushing the data towards me?.

---

You are pulling the data : it is still the PC that controls the bus and gives timing signals, only the write/read direction is reversed.  This is why it is possible to interrupt the incoming data transfer at any time with UNT.  Incidentally,  a "Read" or equivalent function will always interrupt the data transfer when the buffer you allocated for the incoming data gets full. Your code should check for this condition from the received status and, if this is the case, repeat calling Read to get the next part of the message.  For short messages people usually don't bother with it, just reserving enough buffer, however when reading e.g. long scope traces it may become necessary to handle incomplete transmissions correctly.

[paw510]

These are not libraries, but the actual hexadecimal coding for IEEE-488 (prior to SCPI). 

---

To make things more clear : these codes have nothing to do with SCPI which acts at a different protocol level: you can do SCPI with low-level gpib or, inversely, communicate with non-SCPI devices using high-level gpib functions.

[Minions]

---

@paw510 wrote:

These are not libraries, but the actual hexadecimal coding for IEEE-488 (prior to SCPI). 

---

To make things more clear : these codes have nothing to do with SCPI which acts at a different protocol level: you can do SCPI with low-level gpib or, inversely, communicate with non-SCPI devices using high-level gpib functions.

---

Actually, that is not correct.  The command set that the OP is dealing with is based upon the original IEEE-488.2 while the Standard Commands for Programmable Instruments (SCPI) was defined as an additional layer on top of the IEEE 488.2-1987 specification.  Not all controllers allow usage at both levels.

[paw510]

---

---

Actually, that is not correct.  The command set that the OP is dealing with is based upon IEEE-488.1 while the Standard Commands for Programmable Instruments (SCPI) was defined as an additional layer on top of the IEEE 488.2-1987 specification.  Not all controllers allow usage at both levels.

---

I don't quite understand what you are saying : I said "a different protocol level" and you "an additional layer on top...", for me it's the same.    And I still believe all controllers can be used for SCPI, the only difference might be the level at which the driver software can be programmed.

[Minions]

I can tell you from experience that all controllers do not allow for control at the lower level.  They still may perform the same and appear to send and receive the same commands, but that doesn't mean that the full base command set is available.  We had to change up one of our systems to use the HS+ to allow for this control with an old DPI 520 pressure calibrator.  Not sure what was previously being used that worked for SCPI commands/queries with other instruments, but not for the non-SCPI compliant instruments.

[Gdpro7]

Hello, thank you for the replies and excuse me for taking so long to reply.

We still couldn't get the desired result using some of the functions you mentioned, but it was long time ago. We will try again based on what you wrote.

Today we use a development board (Stm32f4 discovery) to control gpib - controller - TMS9914ANL.

Now we have a full control over the bus sending any command and data sequence we desire, and yet we still can't receive an answer from the pc we are trying to communicate with this way.

However, we managed to communicate with this pc in an interesting conditions.

Since we are using Gpib-usb-hs+ we have the Analyzer feature which let's us capture everything that is happen on the bus, and we use it to check our code with tms9914 and it's result.

The combination of Gpib-usb-hs+ (in capture mode) and the tms9914anl being a bus controller sending all the data to the pc gave us the desired results, we received an answer from The pc. And this works as long as the Gpib-usb-hs+ is in CAPTURE mode, others nothing happens. 

These behavior brought us to isolate the Gpib-usb-hs+ pins until we found what is required to be to tell us read the pc. The result was NDAC, NRFD, DAV - handshake flags. Overall legit because of the capture mode. 

Have you ever experienced such behavior? And what could be the solution to move only to tms9914 or the Gpib-usb-hs+? 

P. S.

The length of the received datafrom the pc  is defined by the controlled using ATN flag, as long as its in data mode the pc sends data when moved to command the pc stops and then I send UNT to terminate the bus.