Instrument Control (GPIB, Serial, VISA, IVI)

cancel
Showing results for 
Search instead for 
Did you mean: 

How to send commands and data upon request


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.

0 Kudos
Message 11 of 15
(95 Views)

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.

 

 

 

 

 

0 Kudos
Message 12 of 15
(94 Views)

@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.

Help the Community (and future reviewers) by marking posts as follows:
If it helped - KUDOS
If it answers the issue - SOLUTION
0 Kudos
Message 13 of 15
(87 Views)


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.

0 Kudos
Message 14 of 15
(85 Views)

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.

Help the Community (and future reviewers) by marking posts as follows:
If it helped - KUDOS
If it answers the issue - SOLUTION
0 Kudos
Message 15 of 15
(79 Views)