Giving commands on Labview which are carried out on RealTerm

[CCloggie]

Hi All,

I'm working on automating the primary testing on our controllers. Currently all the tests are carried out manually by issuing commands and reading/verifying responses manually on RealTerm.

I was wondering if it is possible to create a LabVIEW program that allows the user to be able issue the commands for RealTerm, but from a LabVIEW interface? and then have the answer to the commands verified/read automatically.

Any advice on how to go about setting up the link between LabVIEW and RealTerm would be greatly appreciated.

[MaxJoseph]

I am not familiar with RealTerm, but it appears to be a Serial/TCP exposer that can be used to send and read data going through these interfaces. LabVIEW contains functions that will do a similar thing. You could write the serial command into a vi and then send it with a button press. The returned serial message could then be interpreted using read functions that come with LabVIEW and the test assessed for success.

This approach would effectively cut RealTerm out of the loop. I suspect that you have a body of routines programmed in RealTerm that you don't want to have to rewrite, and so want to interface with it directly. You could seek to expose the RealTerm functions in a DLL Function Call, but this might be tough. It depends a lot on how RealTerm is written. It might be handy to ask the RealTerm developers how you can call its functions from a 3rd party program, like LabVIEW.

[crossrulz]

Just use VISA to send your serial commands.  If you need SSH you are in for a lot of fun (I used an open source .NET interface).

[CCloggie]

I have been trying to communicate with the controller using LabVIEW but haven been able to get a response to any commands I have been issuing, instead I have been getting the command issued in the write buffer as an output in the read buffer instead of the response to the command.

eg - issuing TOD as a command should return the Time of Day, instead issuing TOD returns TOD.

I have attached an example of the code I have written to test this, any help or suggestions to fix this would be great.

[pincpanter]

Your serial port is probably an RS-485 without echo filtering. Every sent string will be received as an echo in input.

Now if this is the case, there are two possibilities: disable echoing by properly configuring the port (usually there is an option to do that), otherwise do two reads, the first giving as byte count input the length of the sent string.

To read the response, don't use Bytes at Port. The response message has probably a termination character (carriage return is a common choice, whose value is 13). In  VISA Configure Serial Port, input the right value for the termination char (default is the line feed character whose decimal value is 10) and define a proper timeout - 10000 milliseconds seems too much.

Furthermore, the termination character should also be appended to the answer message. Usually, this is done by program instead of direct input.

I would reconsider the way you send the command. Directly typing commands is very rough. You may prepare an array of allowed commands (perhaps in a text ring of combo box), then select the right command from the prepared list.

[pincpanter]

This is an example, assuming that carriage return is the term char (seems that snippet creation was faulty, see the attached vi to view unbroken code).

I'm also assuming that the response is no more than 100 characters long.