You've Got m@il!

This TLServer Email capability is first implemented in TLServer 1.0 and is carried forward to Version 2.0. This method depends on the TLServer to periodically scan each configured PLC for the state of their email request flags and hence require that the TLServer be constantly connected to the PLC(s) via the serial port. (Another email support function available only to TLServer version 2.0 is described in the document for "File and Email Services")

A PLC program raises an email request flag by setting the variable emEVENT[1] to a non negative value (see explanation on "Writing 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 or RS485. To setup the server to handle email requests, click on the "Setup Emails" button on the TLServer to open the following dialog box:

SMTP Mail Server: This will be the same Outgoing Mail Server that you use in your email program such as the Eudora or Outlook Express. If in doubt, ask your ISP or System Adminstrator for help. This server must be setup properly before the TLServer can send any email. If your SMTP server requires authentication via POP3 you will have to use your email program to check your email once prior to using it to send emails. 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.

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.

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 message in the email setup dialog) and will not be checked according to their defined service period to avoid repeated communcation 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   button once. Then scroll to the PLC of  interest to check if there is a message. Check the PLC communcation port wiring if there is an error.

 

Writing TRiLOGI Programs that Can Send Emails

In order to send an email, the 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 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 PLC.

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