Difference between revisions of "Communication"

From SoftMC-Wiki
Jump to: navigation, search
m (Introduction)
m (Introduction)
Line 2: Line 2:
  
 
== Introduction ==
 
== Introduction ==
<!-- This documentation covers all the commands and properties associated with the EtherCAT module in the softMC. The syntax and related properties and variables are shown for each command. Examples are also shown to illustrate the use of the functions and subroutines. It is recommended that you review this manual and refer to it when you are using these functions. -->
 
 
<!-- Various versions of the firmware adds many new features, and in many instances, significantly changes the syntax or behavior of functions (commands, properties). Therefore, the attribute Availability is included in the format to denote the applicability of each function (command, property) to the specified version of the firmware. -->
 
 
 
 
* [[:Category:Axystems:EtherCAT:SETUP-EC|Setup EtherCAT]] - How to setup EtherCAT
 
* [[:Category:Axystems:EtherCAT:SETUP-EC|Setup EtherCAT]] - How to setup EtherCAT
 
* [[:Category:Axystems:EtherCAT:Functions|EtherCAT Functions Reference]] - A list of basic EtherCAT functions
 
* [[:Category:Axystems:EtherCAT:Functions|EtherCAT Functions Reference]] - A list of basic EtherCAT functions

Revision as of 06:26, 11 May 2014

EtherCAT

Introduction

Command Reference Format

Each command or property description is clearly separated from adjacent command and property topics so that you can easily find the item that you are looking for. Each description contains sufficient information required to use the command or property correctly. All commands and properties contain the following items:

  • Description
  • Input
  • Output
  • Return Value
  • Declaration
  • Syntax
  • Availability
  • Type
  • Range
  • Units
  • Default
  • Scope
  • Limitations
  • Example
  • See Also

Notation

In describing the syntax of an instruction, a field to be filled by user is marked with < >.
For example, ABS ( <expression> ) indicates that <expression> is the user’s data.



TCP/IP Communication

Use TCP/IP communication with other computers and intelligent I/O devices over the Ethernet network. MC-BASIC uses TCP/IP API (sockets).

TCP/IP provides multi-thread communications. The same physical link (Ethernet) is shared between several applications. This way, the softMC can connect to BASIC Moves and one or more intelligent I/O devices.

The softMC supports both client and server roles for TCP/IP communications. The TCP/IP client connects to a remote system, which waits for a connection while the TCP/IP server accepts a connection from a remote system. Usually, the softMC serves as client while interfacing to an intelligent I/O connected to the LAN, and as a server when working toward remote host like a software PLC. The softMC uses Realtek RTL8019AS Ethernet NIC at a bit rate of 10 M bps.

Setup

TCP communication starts by opening a socket either to connect to a remote computer (remote host) or accept a connection from a remote host. Use CONNECT or ACCEPT, depending on the softMC functionality (client or server).

OPENSOCKET creates a TCP socket and assigns the socket descriptor to the specified device handle. The socket is created with OPTIONS NO_DELAY (send data immediately= 1). Otherwise, the data is buffered in the protocol stack until the buffer is full or a time-out is reached. This improves responsiveness when small amounts of data are sent. This option is recommended for interactive applications with relatively small data transfer. Otherwise, OPTIONS = 0.

OPENSOCKET OPTIONS=1 AS #1

OPENSOCKET
assigns a device handle to the communication port (as OPEN). Any further reference to the communication port uses the device handle number. The device handle range is 1…255.

There are several ways to set the IP address of the controller. By default, the softMC boots without a valid IP address. The following options are available to set the IP address of the controller:

Static IP address setting
Use SYS.IPADDRESSMASK in the Config.prg file to assign the IP address and Subnet mask:

SYS.IPADDRESSMASK=”212.25.84.109:255.255.255.128”

Dynamic address setting by Windows API
API assigns an IP address to the softMC when it establishes TCP communication with the controller. The IP address and Subnet mask are taken out of a pre-defined address pool. BASIC Moves uses this address assigning method. Refer to the BASIC Moves Development Studio® User Manual and MC Reference Manual for detailed information.

DHCPIP address is assigned by the DHCP server. If your network does not support DHCP, the controller tries to get the address from the DHCP server and times out after few minutes. During that time, communication with the controller is not possible.

SYS.IPADDRESSMASK=”dhcp”

If DHCP is used, select Automatic connection method as shown below:

caption

Get the controller’s IP address
Use SYS.IPADDRESSMASK to query the IP address and Subnet mask of the softMC.

-->?SYS.IPADDRESSMASK
172.30.3.11:255.255.0.0
NOTE-Info.svgNOTE
The softMC has several IP interfaces: Ethernet and IP over serial. However SYS.IPADDRESSMASK is only valid for Ethernet interfaces. Others have fixed IP addresses, which cannot be changed.

PING tests that a remote host is reachable. The remote host must support ICMP echo request.

?PING(”212.25.84.109”)

softMC as TCP Client

When acting as a client, the softMC tries to connect to a remote server until a time out value expires or the connection is rejected. Use CONNECT when the softMC acts as a client.

The softMC requests a connection from a remote host, according to a specific IP address and port. CONNECT blocks task execution until the connection is established or until the command fails. To unblock a task waiting in CONNECT, close the corresponding socket using CLOSE. In addition, killing a task (KILLTASK) blocked by CONNECT closes the socket to release the task. CONNECT may fail due to the following reasons:

  1. Invalid socket descriptor
  2. Remote host has no application attached to specified port.
  3. Destination address is not reachable

The following example illustrates a typical procedure of establishing a connection to a remote host, and sending and receiving data:

OPENSOCKET OPTIONS=0 AS #1
CONNECT (#1,”212.25.84.100”,6002)
PRINT #1,”HELLO”
?INPUT$(LOC(1),#1)
CLOSE #1

softMC as TCP Server

When acting as a server. the softMC endlessly waits for a connection from the remote host. Use ACCEPT when the softMC acts as server. ACCEPT binds a socket to a specified port and waits for a connection. Simultaneous ACCEPTs on the same port are not allowed. ACCEPT blocks the execution of the calling task until a connection is established. To unblock the task waiting in ACCEPT, close the corresponding socket with CLOSE. In addition, killing a task (KILLTASK) blocked in ACCEPT closes the socket and releases the task. The following example illustrates a typical procedure of waiting for a connection from a remote host, and sending and receiving data:

OPENSOCKET OPTIONS=0 AS #1
ACCEPT (#1,20000)
PRINT #1,”HELLO”
?INPUT$(LOC(1),#1)
CLOSE #1


Serial Communication

The softMC has two RS-232 ports, which can be used for user communication. When COM1 is used for communication with BASIC Moves over API, tasks cannot access it to eliminate interference with ControlStudio communications. Use DIPswitch bit #8 to configure this port:


DIP Switch bit #8 state
ON (default) COM1 is reserved for communication with the host and cannot be used by any other application
OFF COM1 is available for user communication

When DIPswitch bit # 8 is ON, the softMC firmware prints boot status messages from COM1 using the following serial communication parameters:


Baudrate
9600 bps
Parity
none
Stopbits
1
Databits
8
NOTE-Info.svgNOTE
State ON of DIPswitch read as 0.

For example:

Switches 6 & 8 are OFF. All others are ON.

-->?sys.dipswitch bin
0b10100000
-->

With Host

When DIP switch #8 is ON, the softMC can communicate with the host via serial port. This mode of communication requires Virtual Miniport driver, which is installed during setup of ControlStudio. The driver simulates Ethernet connection over serial interface using following fixed parameters:


Baudrate
115200 bps
Parity
None
Stopbits
1
Databits
8
IP address
192.1.1.101
Subnet mask
255.255.255.0

All the parameters are fixed and cannot be modified.

If the driver is installed correctly and ControlSudio is running, it appears in the list of Ethernet adapters as shown below:

C:\>ipconfig /all
Ethernet adapter Local Area Connection 5:
Connection-specific DNS Suffix . . . . :
Description . . . . . . . . . . . . . . : Giant Steps Virtual miniport
Physical Address. . . . . . . . . . . . : 00-02-1B-D1-A5-FC
DHCP Enabled. . . . . . . . . . . . . . : No
IP Address. . . . . . . . . . . . . . . : 192.1.1.1
Subnet Mask . . . . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . . . . :
DNS Servers . . . . . . . . . . . . . . :

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-Info.svgNOTE
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.

caption

Close Connection

CLOSE closes the connection and releases the device handle:

-->CLOSE #1