Planning

To simplify the use of the communication module, connection elements are provided for all required services.

  • RCOM_INIT block for initializing the communication module.
  • Connection elements for the system services
    • cold start service (RCOM_COLDST)
    • warm start service (RCOM_WARMST)
    • normalization (RCOM_NORMAL)
    • event polling (RCOM_POLL)
    • telephone dialing (RCOM_DIAL)
    • telephone hang-up (RCOM_HANGUP)
  • Connection elements RCOM_TRANSMIT (transmit data set) and RCOM_REC (receive data set) for writing data sets. These connection elements are also used for event-driven transmission. For event polling, the RCOM_POLL connection element has to be used in the master to trigger polling of the slave.
  • The RCOM master uses the RCOM_READ connection element for reading data sets. The addressed slave provides the data to be read in the RCOM_READ_SLV connection element.

Initialization, cold start and normalization

The illustration below shows the application of the connection elements RCOM_INIT, RCOM_COLDST and RCOM_NORMAL. These connection elements have to be used for initializing the communication processors and for starting the RCOM protocol.

Each RCOM user is initialized by the RCOM_INIT connection element, i.e. the transmission parameters, the network address and the timeout times etc. are defined.

The RCOM master then has to perform an RCOM cold start service (RCOM_COLDST) and data transmission has to be enabled by normalization (RCOM_NORMAL). In the example, cold start and normalization are implemented by broadcast telegrams (NODE = 255) so that all slaves are addressed simultaneously.

The RCOM network is ready for data transfer after the procedure above has been performed.

../_images/6f9dbc68d01e9d540a33139001beccc0

In the application shown above, the connection elements for initialization and for the RCOM services cold start and normalization are displayed in simplified form.

Data transmission

The illustration below shows an example of transmission of data sets. It illustrates the relationship between connection elements and the significance of address and data set number (“ID”).

../_images/5a083a24d03dbb430a33139001a9b0a3

In the application shown above, the connection elements for data transmission are shown in simplified form.

The following transmissions can be performed in this example:

  • Data set 1 is transmitted from the master to slave 1.
  • Data set 22 is read by slave 2.
  • Data set 19 is sent from slave 3 to the master (event-driven). The master must first poll slave 3 (connection element RCOM_POLL).
  • Data set 78 is sent from the master to slave 4.

The figure above does not show the logic for enabling of the connection elements.

Note

For each connection element in the master, a corresponding partner is available in the slave. These two connection elements have the same data set number (“ID”).

The data applied to the inputs and outputs of the connection element are not the actual user data but only parameters referencing the storage location of the user data instead.

All data sets in the slave are addressed by zero (“NODE”) because jobs can be initiated only by the master.

A specific sequence of system services has to be observed for starting an RCOM network. This sequence ensures the correct initialization of the RCOM protocol.

All system services are triggered by the master using the corresponding connection elements. Nothing needs to be planned in the slaves for the system services. The CM574-RCOM configured as slave handles all system services independently.

Note

:strong:Terms

Do not confuse the RCOM services cold start / warm start and the corresponding PLC commands referring to the hardware state. In this section, the terms “cold start” and “warm start” always refer to the RCOM system services and therefore only affect the protocol state.

Cold start

A cold start service has to be performed after the initialization of the RCOM master. The cold start can be transmitted either by broadcast to all slaves simultaneously or to each slave individually.

A cold start requires reinitialization of the entire protocol mechanism and clearing of the event queue contents. For this, a special cold start event is triggered in the addressed RCOM slaves. This event is required when operating ABB MasterPiece systems. In case of pure Advant Controller networks, the event is only indicated when polling.

After a cold start, always normalization has to be performed. Otherwise it is not possible to transmit data sets.

Warm start

By executing a warm start service, it is possible to clear the event queue of a slave (or all slaves). A warm start can be used to resume communication after transmission errors. This permits master and slave to resynchronize.

After a warm start, always normalization has to be performed. Otherwise it is not possible to transmit data sets.

Normalization

A slave has to be normalized after a cold start or a warm start. Normalization enables the transmission of data sets and events. If a slave is not normalized, it cannot trigger events. The RCOM_TRANSMIT connection element then displays a corresponding error message.

If a master polls a non-normalized slave, the RCOM_POLL connection element signals a corresponding error.

Set clock

When the CM574-RCOM is switched on, its software clock is set to 0:00 hours. You can use the RCOM_CLOCK connection element to set the clock of the RCOM master and the clocks of all slaves to the same time. This is important for evaluating time stamps in the case of event-driven data transmission.

Clock setting should always be performed after a cold start and should be repeated cyclically (e.g. every 24 h), if necessary.

The CM574-RCOM contains a software clock for generating time stamps. You can also use this software clock in the PLC program of your CPU module. The time information is made available at the outputs NEW_TIME, HOUR_ACT, MIN_ACT and SEC_ACT of the RCOM_INIT connection element and is updated there approximately every 5 seconds.

The RCOM time starts with 00:00.00 when the Communication Module is set to the RUN state.

The connection element RCOM_CLOCK sets the RCOM clock of the master and sends a set clock telegram to all slaves (“NODE” must be set to 255 for this purpose).

Proceed as follows to set the RCOM time: Read the actual time from the real-time clock and start the RCOM_CLOCK connection element in the RCOM master with this time (NODE = 255 in order to address all slaves). The new time is then transferred to the RCOM clock in the master and in all slaves and output NT is set to “1” for approx. 5 seconds. If individual slaves also use real-time clocks, you can use the edge of NEW_TIME to set these clocks. The master and all slaves use the same time then.

You should use the RCOM_CLOCK connection element even if the RCOM master does not have a real-time clock (e.g. with time 00:00.00 hours). All time stamps in events are then calculated relative to this arbitrary RCOM time.

When planning, you should first precisely analyze the required communication relationships in order to avoid subsequent modifications.

You should consider the following questions:

  • How many slaves are necessary? Determine the slave numbers (“NODE”).
  • How many data words have to be transmitted for each slave? Define the subdivision of the data into data sets. Determine flag ranges for each data set.
  • How do the individual data sets have to be transmitted? Cyclically? At the request of the PLC program? Event-driven? Define the communication sequences. Do not forget the required system services (e.g. cold start and normalization). Chapter Planning examples shows how such sequences can be implemented.
  • How must the PLC program of the CPU module respond to transmission errors? The example program shows a possible solution.

Important planning rules

The following rules have to be observed during planning for the CM574-RCOM:

  • “ID” (data set identifier) can have values between 1 and 255.
  • Only an even number of data words can be transmitted in a data set.
  • Connection elements must not be skipped once they have been started. This would disturb the logic sequence between the connection element and the CM574-RCOM and cause the connection element to block.
  • The connection elements must not be started before the RCOM_INIT connection element has been executed successfully (initialization of the Communication Module). This would cause the connection elements to block.
  • Data transmission with RCOM_READ jobs takes approximately twice as long as event-driven transmission. Consequently, you should prefer event-driven transmission in case of time-critical transmissions.
  • Max. 14 words are permitted per data set for event-driven transmission. The time stamp is included in two data words, directly after the user data. The master must know the number of words transmitted, if it wishes to evaluate the time stamp (plan a fixed length).

Full duplex

In case of full duplex mode, the RTS line of the Communication Module is set to “1” after initialization.

Prior to the transmission of characters, the Communication Module expects a valid CTS line. The modem may set CTS to zero during transmission in order to stop data flow.

Full duplex should be used for transmission links that provide a separate channel for each transmission direction, e.g. modem-zero cables, telephone connections or modem LS-01 of Messrs. Hedin-Tex.

The illustration below shows full-duplex data communication on a CM574-RCOM used as RCOM slave.

../_images/1e57fbc4d01e97d80a331390017288d8
  1. The CM574-RCOM sets RTS to “1” during initialization. The modem responds with CTS = 1.

  2. The CPU starts the job on the CM574-RCOM. The Communication Module waits for TLS.

  3. The Communication Module checks CTS and starts transmission of the job telegram.

  4. The telegram is finished. The Communication Module waits for CDly.

  5. The slave recognizes the job and processes the telegram. TLS is expected before the response is transmitted.

  6. The slave starts transmission of the response telegram.

  7. After the telegram has been transmitted, the slave waits for CDly. This terminates transmission.

Note

TLS is always expected before transmission of a telegram. CDly is expected after the transmission of a telegram. For error-free communication, TLS has to be greater than CDly of the remote station .

Delay times

Delays can increase the transmission reliability and can be planned before and after the telegram in full duplex mode and in half duplex mode.

Parameter TLS (“line stab. time”) indicates the time expected before the transmission of a telegram and after the activation of the modem carrier with CTS = “1” (in case of half duplex only).

Parameter CDLY (“carrier delay”) indicates the delay after the telegram.

The following condition has to be observed for full duplex and half duplex mode in order to guarantee reliable transmission: Own TLS > CDLY of the remote station.

The two delay times are entered as a number of characters (duration of transmission of a character at the given baudrate) so that longer delays result in case of lower baudrates.

Since the internal clock runs with a clock rate of 10 ms, only multiples of 10 ms are practical.

Examples:

  • Baudrate = 9600 baud -> 1 character = approx. 1 ms, practical time values: 10, 20, 30 etc.
  • Baudrate = 4800 baud -> 1 character = approx. 2 ms, practical time values: 5, 10, 15 etc.

Recommended values for TLS and CDLY at 1200 baud:

  • with half duplex: TLS = 3 characters, CDLY = 2 characters
  • with telephone connections: TLS = 2 characters, CDLY = 2 characters
  • with full duplex (multidrop or point-to-point): TLS = 2 characters, CDLY = 0 characters.

Please note that these values depend on the modem used and should be determined experimentally, in particular in case of half-duplex links.

Using dial-up modems

The CM574-RCOM communication processor is able to handle communication via the public switched telephone network. For this purpose, it can control Hayes-compatible modems (controlled by AT commands).

The illustration below shows an example pin assignment between a modem (RS232C interface) and the RCOM interface of the CM574-RCOM:

../_images/aa971433e38bffc70a33139000eba54e

The illustration below shows an example pin assignment between a modem (RS232C interface) and the RCOM interface of the CM574-RCOM:

  • Use only Hayes-compatible modems. Deactivate any MNP options possibly
  • Deactivate any MNP options possibly available on the modem. In case of MNP transmission, the correlation in time between telegrams is lost and transmission is disturbed.
  • For transmission, a physical connection is necessary that allows the transmission of breaks and binary characters without loosing coherence in time (duration of the break signal, intervals of the characters). For most modems, these operating mode is called “direct mode”.
  • In the PLC program of the CPU module, connection has to be established (RCOM_DIAL connection element) prior to the transmission of RCOM services, and has to be terminated again afterwards (RCOM_HANGUP).

During commissioning, you should first attempt to address the modem with the operator command “MOD” (refer to chapter “Operator”). If you enter the command OPERATOR>MOD ATI4<CR>, you should see a table of the most important modem parameters. If this is not the case, modem configuration is probably incorrect (baud rate, parity, etc.).

Communication sequence on the RCOM master

Observe the following sequence in the PLC program of the RCOM master for data transmission:

  • Set modem parameter type to “Hayes compatible dial modem” in the PLC configuration.
  • Initialize the CM574-RCOM using the RCOM_INIT connection element.
  • Call the remote station: RCOM_DIAL. If RCOM_DIAL is completed and no error is signaled:
  • Perform a cold start or warm start at the remote station, if required. Cold start and warm start delete the event queue of the called slave. Do not use broadcast telegrams with these services. Address the slave explicitly instead.
  • Then perform normalization. This service always has to be performed in order to initialize the protocol mechanism for data transmission. Do not use broadcast telegrams with these services. Address the slave explicitly instead.
  • Only if normalization does not signal an error, you may write and read data sets (RCOM_TRANSMIT and RCOM_READ) and poll the slave (RCOM_POLL and RCOM_REC).
  • Then you have to terminate the connection (RCOM_HANGUP).

In case of transmission errors (which may occur particularly during normalization) you should terminate the connection using RCOM_HANGUP and start a new dialing attempt.

Communication sequence on RCOM slaves

No special connection elements need to be planned in the PLC program for regular data transmission (master calls and starts services) in case of RCOM slaves.

The slave “picks up” the telephone when it rings and then expects telegrams from the master. If no further telegrams arrive after the waiting time has expired (RCOM_HANGUP time), the slave “hangs up” automatically.

Event transmission: DIAL in slave

The slave can call the master, if it wants to transmit events to the master.

For this purpose, a DIAL connection element needs to be started in the slave. Communication is performed as follows:

  • The slave calls the master using RCOM_DIAL.
  • The master answers the telephone.
  • After a short waiting time, the master starts to normalize all slaves configured in the telephone directory. Since only one slave can be the caller, only the calling slave will answer correctly.
  • The master now automatically polls the recognized slave until it signals that the event queue is empty or until the number of polls defined by parameter “Maximum polls” set in the PLC configuration is reached. The received data sets are transferred to the RCOM_REC connection elements in the master.
  • The master then “hangs up”.
  • The slave also “hangs up” after a waiting time (“Hang-up time”).

Note

The master automatically attempts to poll all slaves when it is called. No RCOM_POLL connection element is required for this purpose. The RCOM_POLL connection element is only required, if the master calls the slave.

No RCOM_HANGUP connection element needs to be planned in the slave, since the slave does not know when transmission is completed. The slave “hangs up” automatically after expiry of the “hang-up time” (refer to section “Timeouts”).

The master and the slave strictly monitor whether RCOM telegrams are actually transmitted over the established connection (“telephone off hook”).

If no telegrams were received by the slave or if no services were started in the master after expiry of the “hang-up time”, the telephone connection is terminated again.

This prevents “wrong callers” who have dialed the wrong number for instance from blocking the telephone permanently.

Since the RCOM slave is not able to completely monitor the status of the modem (control only with RCOM_DIAL), you should select a short “hang-up time” for the slave, e.g. 10 seconds.

On the master, the timeout should never respond since the modem can be monitored completely by the PLC program of the CPU module (RCOM_DIAL and RCOM_HANGUP). Consequently, you can select a long “hang-up time”, e.g. 30 seconds.

Correct settings for the modem are very important for error-free communication.

Certain parameters can be stored in a non-volatile memory in the modem. All other parameters can be stored on the CM574-RCOM in the Init string of the modem setup. They are then transferred to the modem when the CM574-RCOM is initialized.

To enable the CM574-RCOM to control the modem correctly, the following parameters always have to be configured:

  • Commands are echoed by the modem
  • Acknowledgements from the modem on
  • Acknowledgements in plain text
  • Break does not clear down connection
  • MNP options off
  • Data compression off (direct mode)
  • Dialing with DTR off
  • RTS/CTS handshake between modem and CM574-RCOM
  • Automatic call acceptance off
  • Escape character: &;;+&rsquo;

Special features

In “direct mode” the LGH 9600H1 (in the following called LGH) cannot react on the sequence “+++”. Consequently, switching from online to command mode for hang-up is not possible.

Therefore, the CM574-RCOM provides an operating mode enabling hang-up by means of the DTR signal (S1/108) of the modem. If the DTR signal is switched from active to passive, the modem hangs-up immediately and switches to the command mode.

Call acceptance and establishment of requested connections is only possible while the DTR signal is active.

Because the CM574-RCOM is not able to make an independent DTR signal available, the RTS signal is used (operating mode “RTS as DTR”). So the cable for connecting the LGH to the CM574-RCOM is as follows:

../_images/60b058d9d08b7fa00a3313900095cb1c

Settings at the LGH 9600H1

The following parameters have to be set permanently for the LGH, e.g. via a terminal directly connected to the LGH:

../_images/efb24141d01ea0120a33139001da38ad

After entering the parameter “ATF2”, ensure that the LGH and the terminal are permanently set to 1200 Baud.

Save the parameters in the non-volatile memory of the LGH by entering “AT&W”

The DIL switches at the LGH have to be set in a way that the basic setting “0” is set in the software mode (all switches S5.1 to S5.5 at the front panel of the unit to “OFF”).