Serial Communication

Introduction

The softMC has RS-232 ports, which can be used for user communication. COM1 is reserved for maintenance purposes and not available for the application.

Open Serial Port

Configurate the serial port with OPEN. Set the following port properties:

BaudRate - baud rate of the device set to a specified value.

Parity – enable/disable parity detection. When enabled, parity is odd or even.

DataBits - number of data bits.

StopBit - number of stop bits.

Xonoff – sets raw mode or ^S/^Q flow control protocol mode (optional parameter disabled by default).

For example:

OPEN COM2 BUADRATE=9600 PARITY=0 DATABITS=8 STOPBIT=1 AS #1

Opens COM2 at 9600 bps baud-rate, No parity, 8-bit data, 1 stop bit.

OPEN assigns a device handle to the communication port. Any further references to the communication port uses the device handle number. The device handle range is 1…255. To change the communication parameters, close the serial port and reopen it using the new parameters. For more information, see PRINT # and INPUT$.

Send/Receive Data

Serial and TCP communication use the same commands to send and receive data. After establishing communication over TCP or after configuring the serial port communication parameters, send and receive data regardless the communication type. Data flow differences are communication speed and the size of the input and output buffers. TCP/IP communication uses larger communication buffers.

Receive Data

The input-buffer of the serial ports is a fixed512 bytes size. User communication allows receiving strings using INPUT$. To check if data is ready at the input buffer, use LOC. The following example checks the number of bytes available at the input buffers and reads all the available data:

-->?LOC(1)
11
-->STRING_VAR = INPUT$(11, #1)
-->?STRING_VAR
Hello World

If INPUT$ requests reading a data length larger than available data, the command returns only the available data:

-->?LOC(1)
11
-->STRING_VAR = INPUT$(20, #1)
-->?STRING_VAR
Hello World

LOC can be used within the INPUT$:

STRING_VAR = INPUT$(LOC(1), #1)

A partial read of the input buffer is allowed. This way, several calls to INPUT$ empty the input-buffer:

-->?LOC(1)
11
-->STRING_VAR = INPUT$(3, #1)
-->?STRING_VAR
Hel
-->?LOC(1)
8
-->STRING_VAR = INPUT$(8, #1)
-->?STRING_VAR
lo World

When calling INPUT$, the system does not wait for data. If the input-buffer is empty, the command returns without any return value:

-->?LOC(1)
0
-->STRING_VAR = INPUT$(10, #1)
-->?len(STRING_VAR)
0

Send Data

PRINT # and PRINTUSING # send data over the serial port. Both commands use the same formatting as PRINT and PRINTUSING.

	NOTE
	PRINT # and PRINTUSING # appends a carriage-return (ASCII value 13) and line-feed (ASCII value 10) characters at the end of each message. To print a message without the terminating carriage-return and line-feed characters use a semicolon at the end of the command.

For example, the following uses PRINT # to send data:

-->STRING_MESSAGE = "ERROR"
-->PRINT #1, STRING_MESSAGE,"A1.PCMD=";A1.PCMD;

The output is:

ERRORA1.PCMD=0.000000000000000e+00

The values of the following variables are sent one after the other. The output is (hexadecimal) 0x37 0x28:

I1=55
I2=40
PRINT #1, I1;I2

The output is:

5540

Send Data Block

PRINTTOBUFF # and PRINTUSINGTOBUFF # allows buffering of data before actually being sent. This eliminates inter-character delays.

printtobuff #handle,chr$(0); chr$(message_length); chr$(0);send=false
printtobuff #handle,chr$(request[ii]);send=false
printtobuff #handle,chr$(request[ii]);send=true

Send/Receive NULL Character for Firmware Versions, Not Supporting UTF-8 Format

When using a specific protocol over Serial or TCP/IP ModBus RTU or ModBus TCP), the NULL character is part of the message. The message block cannot be saved in a STRING type variable since the NULL character terminates the string.

In UTF-8 supporting versions 4.5.1 and higher, NULL characters are no longer cut out from strings, resulting in a different behavior:

The string resulting from concatenation is composed from 'A\0B'; that is, there is a NULL character in the MIDDLE of the string:

Len of Chr$(0) is 1:

In previous versions NULL characters could not appear in the middle of strings, since the concatenation process cut these characters from the resulting string. End to send a NULL character in a message, send the data as single bytes instead of a string type message:

COMMON SHARED X[10] AS LONG
X[1]=0x10
X[2]=0
X[3]=0x10
PRINT #1, CHR$(X[1]);CHR$(X[2]);CHR$(X[3]);

The output is the following stream of bytes:

0x10, 0x0, 0x10

When the received data contains a NULL character, read the data from the input buffer as single bytes instead of reading it into a string type variable. Convert the incoming data to a numeric value to get its ASCII value:

DIM SHARED TEMP[10] AS DOUBLE
FOR IDX = 1 TO LOC(1)
TEMP[IDX] = ASC(INPUT$(1,#1))
NEXT IDX

The figure below gives a general description of the TCP/IP communication for both the client and host.

Close Connection

CLOSE closes the connection and releases the device handle:

-->CLOSE #1