Yaskawa LEGEND-MC - Manual (Page 49)

39
LEGEND-MC User’s Manual
trollers. It is the primary method used by the controller to synchronize communication with external
devices. The controllers do not support software handshaking, and simply using three-wire commu-
nication will result in possible character loss.
6) When sending a command string of any kind to the controller, verify that the echo is active (EO1)
and matches the outgoing string before sending the carriage return. Compare the echo, then either
send the carriage return <cr> (if good) or send the backslash character <\> to flush the buffer in the
controller (if bad) then resend. Depending on the environment, retry the same string up to 3-5 times
before finally determining that there is a serious communication failure.
7) When a message retry is required, send the backslash <\> character to flush the buffer in the SMC so
the next command string can be correctly understood. If the buffer contains a partial message, an
additional message could look like a bad message to the SMC, causing another '?<cr><lf>' .
8) Do not use `VAR=<cr>' to request the SMC to return a variable value. If there was an error in trans-
mission, and the string that the SMC received was not a variable that already exists in the controller,
it creates a new variable. If this happens enough times, the controller will fill its variable space. We
recommend using `MG VAR<cr>' which is more reliable, meaning if a bad transmission occurs, the
SMC will respond with a '?<cr><lf>', and not create an unwanted variable. NOTE: Use the 'LV<cr>'
(List Variables) command to see if there are any erroneous variables in the controller.
9) Use the 'TC<cr>' command to get the error code if a question mark ever appears in a response string.
10) Use of 'MG_TC<cr>' (Tell Code) and 'MG_ED<cr>' (The last line that had an error), which are set
when the #CMDERR routine executes.
Ethernet Configuration
Communication Protocols
The Ethernet is a local area network through which information is transferred in units known as packets.
Communication protocols are necessary to dictate how these packets are sent and received. The
LEGEND-MC supports two industry standard protocols, TCP/IP and UDP/IP. The controller will
automatically respond in the format in which it is contacted.
TCP/IP is a "connection" protocol. The master must be connected to the slave in order to begin
communicating. Each packet sent is acknowledged when received. If no acknowledgement is received,
the information is assumed lost and is resent.
Unlike TCP/IP, UDP/IP does not require a connection. This protocol is similar to communicating via
RS232. If information is lost, the controller does not return a colon or question mark. Because the
protocol does not provide for lost information, the sender must re-send the packet.
Although UDP/IP is more efficient and simple, Yaskawa recommends using the TCP/IP protocol. TCP/
IP insures that if a packet is lost or destroyed while in transit, it will be resent.
Ethernet communication transfers information in ‘packets’. The packets must be limited to 470 data bytes
or less. Larger packets could cause the controller to lose communication.
NOTE: To avoid losing information in transit, Yaskawa recommends that the user wait for an acknowl-
edgement of receipt of a packet before sending the next packet.
NOTE: A command sent over an Ethernet Telnet session must reside in one packet. This means that a Tel-
net emulator must not send a command such as MG_TPX<CR> until the carriage return is present; i.e., do
not send one character at a time as the user enters them.