LabVIEW
Driver problems Visa
Hi,
I have problems to communicate with a Rigol DL3021
If I use NI Max to send some message to the DL3021 then it works fine
If I use first my labview test program then it doesn`t work
So I think it should some parameters that have to be insert so that I can use the VISA driver
Any infos can help
Hi SLZ,
@SLZ1970 wrote:
I have problems to communicate with a Rigol DL3021
If I use NI Max to send some message to the DL3021 then it works fine
If I use first my labview test program then it doesn`t work
So I think it should some parameters that have to be insert so that I can use the VISA driver
Do you send EXACTLY the same command to your device as you do in MAX testpanel?
("EXACTLY" includes the very same and correct termination char!)
Btw. we cannot edit/run/debug images with LabVIEW…
1. What communication bus are you using (Serial, Ethernet, GPIB)?
2. Are you really sure you are sending the termination character, typically a Carriage Return and/or Line Feed? Unless you expressly add it to your input string, you are not sending it. I tend to cancatenate the End Of Line character in my driver so I don't have to worry about it at the application level.
@SLZ1970 wrote:
1. The communication is via USB
2. Yes, i send the End Character, I send *IDN?;
Most likely you are not! The Programmer Manual for the DL3000 series has examples for various programming languages (including LabVIEW) at the end and they all send: *IDN?\n
Note that the \n is an escaped <new line> character. You need in LabVIEW to right click the control or constant and select '\' Display Mode to enter this like that. In normal display mode you would send the \ and n character as separate bytes instead of the '\n' new line character.
MAX works, because it appends by default a "\r\n" at the end, and while this is to much for this device, the important part is that there is a "\n". The "\r" is simply discarded by the device as uninteresting character.
Theoretically the semicolon should work too as termination element if the device was truly SCPI compliant, but I guess the Rigol firmware takes a few shortcuts in that regard.
@rolfk wrote:Theoretically the semicolon should work too as termination element if the device was truly SCPI compliant, but I guess the Rigol firmware takes a few shortcuts in that regard.
I find most instruments need that Line Feed character to know when a message has ended. Messages will just sit in the buffer until that Line Feed has been read and then it gets passed on to the actual application. I have noticed this especially on serial and Ethernet busses. Not so much with GPIB because the bus protocol actually has a signal (hard wire signal) stating when a message is done. I try to avoid USB communications.
I have not dug through the SCPI standard enough to see if a simicolon is a valid message termination. My understanding is that it is meant to separate commands in a single message.
@crossrulz wrote:
I have not dug through the SCPI standard enough to see if a simicolon is a valid message termination. My understanding is that it is meant to separate commands in a single message.
It's indeed used for that. And it SHOULD indicate to the command parser to evaluate the command string now. You can daisy chain commands in a single write through that and the different commands are normally guaranteed to be evaluated and have caused any related state changes at the time the processor starts evaluating the next command.
But only Tektronix and HP/Agilent/Keysight (and to some extend Audio Precision) devices seem to honor this properly. And maybe they have stopped with that in the meantime too.
And there certainly is room for interface dependant behaviour. It doesn't surprise me at all if a device does operate differently over GPIB than over Ethernet for instance. It makes not much sense but the related parts were probably often programmed by very different people.
