Communicating with third-party instrument through RS-485 Half Duplex mode in ASCII format

[Mr_Engineer]

Hello everyone,

I'm developing a graphical user interface in LabVIEW to communicate with a third-party instrument through serial port in RS-485 half duplex mode, using NI-VISA drivers.

The third-party instrument only accepts commands in ASCII characters format with "<" less than character (hex code 60) as the start of the packet for command and "{CR}" carriage return character (hex code 13) at the end of the packet for command sending. 

                Example format of the command :  <0135/UAT=12.25{CR}

Here,  0135 is the hardware address of third-party instrument, UAT is the instruction code, the parameter of the instrument  which is being assigned a value of 12.25 with carriage return character in the end.

Similarly, the instrument will respond to this command in the following format.

              Example format of the response to the command:  >0135/UAT=12.25{CR}{LF}

So, the problem is:  how can I send commands in ASCII format with special characters?  and how can I receive the response from the instrument in ASCII format with some special characters? 

I'm using NI-VISA drivers to control and communicate with the third-party instrument.

Screenshots of the user manual of the third-party instrument describing packet structure for command to the instrument and response from the instrument are attached for reference please.

[Minions · Accepted solution]

To verify that your instrument will communicate properly, test it out through NI-Max

• Once opened, click on Devices and Interfaces
• Then click on the hardware that you are trying to communicate with (probably listed as an ASRL#::INSTR "COM#")
• Define the connection criteria
• Click Validate
• Select Open VISA Test Panel
• Select Input/Output
• Enter your command 
  • <0135/UAT=12.25\r
  • Click Query as you expect a response from the instrument
• Check for the response below
  • >0135/UAT=12.25
  • Note that the {CR} & {LF} will not be notably seen on the screen

If this works, then it is a simple process to run in LabVIEW.

[Mr_Engineer]

Thanks for the kind feedback. The  instrument has responded to the ASCII commands sent out through NI MAX app.

Now, I have started working on developing the user interface where I have to send a command and receive a response from the instrument.

On user Interface, I have to display multiple controls for different commands,  hence I'm using combo box control to send commands in ASCII format as mentioned below. 

• <0135/UAT=12.25\r
• <0135/DAT=10.25\r
• <0135/UFQ=1900\r
• <0135/DFQ=1500\r

Now, the problem is that I want to send one command at a time and then send the next command only when I want to, or at least wait for 100 milliseconds before sending out the next command.

I do not want all the commands prescribed into the combo box control to be sent out to the instrument in simultaneous fashion, or one by one in serial fashion.

Could anyone suggest a suitable solution to this problem?  

Thanks and regards.

[Albert.Geven · Accepted solution]

Hi

I wrote 3 subvi's and one Test vi.

All with "unknown" in the title.

You can fill in the instrument name that you have instead of the "unknown"

The test vi stops when an error occurs and displays that.

Before running you should fill in the VISA resource name, because the program immediately tries to open the VISA connection. Also check the baudrate.

Before pressing Run you should fill in a correct address and command, and depending on the state of the checkbox you should get a reply when selecting Query.

[Mr_Engineer]

Hi,

Thanks for your kind response. 

For below mentioned 4x commands, I want to use a separate string/combo box control to send each command to the instrument in a separate fashion. So how can I separately send below mentioned 4x commands through a separate string/combo box control for each command? 

• <0135/UAT=12.25\r
• <0135/DAT=10.25\r
• <0135/UFQ=1900\r
• <0135/DFQ=1500\r

Also, for the response to each command sent to the instrument, I want to use a separate string/numeric indicator to read response of the instrument against each command sent. Response from the instrument is mentioned below.

• >0135/UAT=12.25\r\n
• >0135/DAT=10.25\r\n
• >0135/UFQ=1900\r\n
• >0135/DFQ=1500\r\n

So, how to read response from the instrument into a separate string/numeric indicator?

Also note that response from the instrument contains carriage return and line feed characters in ASCII format.

Thanks, and regards 

[Albert.Geven]

Hi

Did you try the testvi to see that it works?

If the test vi works you can call the subvi with the correct parameters for each of the 4 commands, even with different addresses when needed.

If you want more info on how to select one of the four commands I can write an example, but first does the test vi work?

[Mr_Engineer]

Hi,

Yes, the Test VI worked. 

I just want to use a separate control and indicator box for each command and display the response to the command. 

I want to input multiple string controls for each instruction code and multiple string indicators for the response to the instruction code.

Thanks, and regards

[Albert.Geven · Accepted solution]

You can do this in several ways.

Build an  array of a special cluster that calls the subvi that works.

And couple the index of that array to an enum that selects the specific function.

I can make an example, but maybe you can give me a few examples of the functions you need. Next to the few you gave me in the first question.

[Mr_Engineer]

Hello Albert,

Thanks for your kind feedback.

Below are 4x commands " UAT, DAT, UFQ and DFQ" to be sent through 4x separate/different string controls.

And below are the 4x responses to the above 4x commands, to be displayed into 4x separate/different string indicators.

Could you please give an example of: 

" Build an array of a special cluster that calls the subvi that works. And couple the index of that array to an enum that selects the specific function".

Thanks and regards

[Mr_Engineer]

Hello everyone.

Thanks for the feedback. The problem has been resolved as suggested by Mr. Albert in his last thread.

Regards