Sending 2 E-mails consecutively

[cdenk]

With T100MD+r50, Trilogi V6.43

Trying to send E-mail via serial connection to PC running server to DSL through modem/router. No problems sending to one address, but with 2 codes following quickly, I only get the first E-mail. What's the function of "emEvent[1] = 1", do I need that at the end of each message? Between Messages? Note it is commented out below.
Here's the code:
'This sequence is to our A T & T Cell phone
' Send the E-Mail
   PRINT #1 "<EMAIL xxxxxxxxx@txt.att.net>"
   PRINT #1 "Sender: xxx@xxxxxx.net"
   PRINT #1 "Subject: PLC ALARM"
   PRINT #1 "THE FOOTER TILE SUMP IS HIGH LEVEL"
   PRINT #1 STR$(DATE[2],2) + "/" + STR$(DATE[3],2) + "/" + STR$(DATE[1],4)+ " " + STR$(DM[3984],2) + ":" + STR$(TIME[2],2)
   PRINT #1 "Number " + STR$(CtrPV[6])
   PRINT #1 "</>"
'   emEvent[1] = 1

'This sequence is to our home E-mail
   PRINT #1 "<EMAIL xxx@xxxxx.net>"
   PRINT #1 "Sender: xxx@xxxxx.net"
   PRINT #1 "Subject: PLC ALARM"
   PRINT #1 "THE FOOTER TILE SUMP IS HIGH LEVEL"
   PRINT #1 STR$(DATE[2],2) + "/" + STR$(DATE[3],2) + "/" + STR$(DATE[1],4)+ " " + STR$(DM[3984],2) + ":" + STR$(TIME[2],2)
   PRINT #1 "Number " + STR$(CtrPV[6])
   PRINT #1 "</>"
'   emEvent[1] = 1


Thanks in advance. :)

[support]

When you send out an email via the email server and end it with PRINT #4 "</>" you instruct the CPU to end the client connection with the remote server. However, for efficiency reason the CPU does not wait for the connection to close before allowing the user program to continue execution.

Since there is only one client socket available for doing any client connection from the PLC to the email server, you can only connect to the email server again when the last connection is completely closed. You should be able to test it using the STATUS(3) function to check that the client socket has been closed before sending the "<EMAIL>" tag again.

The best way is to schedule to timer to send out the second email for you a short while later. This allows the program to continue to execute other ladder logic lines without holding up for too long.

Note: The EmEvent[1] is not needed for this command. It was probably a remnant of past codes when using TLServer to send email function using polling method.

[cdenk]

Thanks for the quick reply. I see by the help, that STATUS(3), the output is:
0 - TCP/IP connection closed or last TCP operation failed
1 - TCP/IP connection established or last TCP operation successful

Currently I send both E-mails, 3 times, 5 minutes apart, to ensure that at least one E-mail gets out. With the older system, I was able to check if the send was successful, but as I have started doing, all I can do is check that the operation is closed, and don't know if it was successful.

Timing is not critical here, what might be a guideline for a delay timer between the E-mails? 1 second? 1 minute?

And, I'm assuming there is no way to communicate back to the PLC from a cell phone. Thinking is, there would be a list of priority contacts, the first one to receive the message could stop further contacts.

[support]

Usually closing of a socket should complete within a second unless the other party (email server) did not respond promptly. If you allow 30 seconds between two emails that should cover 99.9% of the chances that the open socket will be closed.

You should also check for the returned string "<OK>" from executing the <EMAIL> tag to know if an email has been conveyed successfully to the email server (it doesn't guarantee that the email has reached the recipient though).

Accessing PLC from cellphone

You could configure a webpage such that when you click on a button (link to a relay) the ladder logic will reset the alarm status. This of course requires the PLC to be exposed to the Internet (port forwarding from the router) so that your smart phone can access to it.

If you want to send an SMS message to the PLC that is more complicated and require a GSM/GPRS modem to be connected to the PLC's serial port so that the text messages can be delivered to the PLC for actions. There are people who did this previously but probably not the most intuitive way to go. With smart phones and webpage access it is a more modern way to interact with your equipment.

[cdenk]

Thanks again for the quick reply. I'll go the delay and check the sent flag route. Our phone is only feature, and not smart at this time, and my web page programing has been zero to this point, so, looks like this will suffice, which should work well. The odds of the system not working at the needed time and damage resulting is very, very small.