Legacy TLServer Email Functions

1. Introduction

Before the Ethernet port was integrated into the newer Super PLCs such as the Nano-10, FMD and F-series, TRi PLCs could only use the TLServer as TCP/IP gateway to perform network related functions, including sending of emails.

Legacy Email Method - Using TLServer as Email Master

The TLServer supports a legacy email feature (carried over since version 1.0) where the TLServer act as a master to a bunch of PLCs connected together via their RS485 port. TLServer can be configured to scan the internal variables of any of the up to 256 PLCs ID connected to it to determine if any of these PLCs has a request for the TLServer to send out email. If so the TLServer will then retrieve the email data from the relevant PLC, constructs a complete email and send it out.  

3. Setting Up TLServer As Email Master For Multiple PLCs on RS485 

A PLC program raises an email request flag by setting the variable emEVENT[1] to a non negative value (see explanation on "Writing i-TRiLOGI Programs that Can Send  Emails") whenever it needs to send an email. The TLServer, upon sensing that an email request flag has been raised, will extract the sender, recipient and message strings from the PLC's internal variables and send them out using the pre-defined SMTP outgoing mail server.

A single TLServer can service the email requests for one or more (max. = 256) PLCs connected to it via RS232 (single PLC only)  or RS485.

The second half of the Email Setup screen with the title "Legacy EMail Feature (from TLServer 1.0)"  are related to this email method. The setup is as follow:

  • PLC ID# column:   For you to select PLCs with ID from 00-FF (256 in total) to set the email service period.
  • Check Every (seconds) - this allows you to define how often the TLServer should check the PLC (the email service period) for the state   of the outgoing email request flag.

    Simply click on field next to the PLC ID# of interest to open up a text entry field (as shown in the figure for ID=02). Enter a non-zero value (in seconds) to define its email servicing period.

Note: Both SMTP Server and email service period definitions will be saved to the hard disk when you exit TLServer program. They will be reloaded when you start TLServer again.

Inactive PLC

TLServer attempts to communicate with every PLC that has a non-zero email service period. However, if the PLC is inactive (e.g. It has not been turned ON or has been disconnected from the server) the communication will fail. Since communication failure takes considerable amount of CPU waiting time and could affect the normal communication with other active PLCs, inactive PLCs are internally marked  by the TLServer (shown as emailsetup3.gif (234 bytes) message in the email setup dialog) and will not be checked according to their defined service period to avoid repeated communication failure. However,  TLServer will re-scan these inactive PLCs every two minutes to check whether they have come on-line.  If an inactive PLC is found to respond to command it will be unmarked and put back in service for its email request.

You can also manually force the re-scanning of all PLCs by clicking on the emailsetup2.jpg (1951 bytes)  button once. Then scroll to the PLC of  interest to check if there is a emailsetup3.gif (234 bytes) message. Check the PLC communication port wiring if there is an error.

This email service period does not determine how often the PLC will send email, since email will only be sent when the email request flag is set even if you had set a very short email service period. It only affects how quickly the email will be sent whenever a PLC raises its email flag. You should set a short service period (say every 10 seconds) for urgent email (such as alarm condition). For non urgent email such as hourly or daily production report you can set a much longer servicing period to reduce the communication loads on the PLCs.

3.1 Writing i-TRiLOGI Programs that Can Send Emails via TLServer as Email Master

In order to send an email, the i-TRiLOGI program needs to use the string variables A$, B$, C$ to store the headers and D$ to Z$ to store the messages.  (not all strings need to be used, unused strings are still available for normal program use) The special variable emEVENT[1] is used as an email request flag which should be initialized to -1 when the program is not requesting email service. When the i-TRiLOGI program wants to send an email, it first stores the sender, recipient and subject into the following variables:

A$ Sender email address - which can be used to identify the source of the email.
B$ Recipient email address - this one must be accurate
C$ Subject of the message.
D$ First line of Message
E$ Second line of email message
...    .....
Z$ The 23rd line of the email message
emEvent[1] -1 =    NOT sending any email.
0  to 23 = number of lines in the email message body which are contained in D$ to Z$.

The maximum number of lines in your email is limited by the number of string variables D$ to Z$ (23 in total) available in the M-series and F-Series PLCs.

For example,  if the PLC needs to send email to trilogi@yahoo.com with a 1-line greeting, then the program needs to activate a custom function that contains the following statements:

A$ = "Demo1@PLC"              ' sender
B$="trilogi@yahoo.com"       ' recipient
C$ = "This is an email demonstration"          ' subject
D$ = "The time is"+STR$(TIME[1])+":"+STR$(TIME[2])+". How are you doing?"   ' Message body
emEvent[1] = 1

You must also setup the email service period (say every 10 second) in the "Setup Emails" screen for this PLC. When the TLServer scans the PLC and found that its emEvent[1] is set to 1, it will extract the headers and message body from the PLC's string variables. Only A$ to D$  will be extracted in this example since the message contains one line of body text only, as indicated in emEvent[1]).

TLServer will then contact the SMTP server to send out the email. In addition, after processing the email request, the TLServer will set the emEvent[1] variable to a value of "-1" (no email). Hence there is no need for the i-TRiLOGI program to worry about clearing the email request flag after the email has been sent. In addition, this provides a way for the PLC program to know whether the TLServer is functioning properly and whether the email request has already been processed. However, do take note that even if the emEvent[1] has been reset it does not guarantee that the email has been correctly dispatched to the recipient. Success of emailing is subject to the proper configuration of the TLServer, the network quality and availability of the SMTP server at the moment when TLServer tries to send out the email. For urgent situations you may consider sending out multiple emails periodically until the user has attended to the machine.