WC8 back-to-back emails - 1st gets dropped

If I send two emails, one right after the other, I only get the second one.  Here's a simple example that I found illustrates this:
 

START
SET VAR1 CTS
LOOP:
SUB CTS VAR1 VAR2
TSTEQ VAR2 30
CALLSUB MAILTIME
GOTO LOOP
END

MAILTIME:
DELAY 2000
EMAIL EM2
EMAIL EM1
RET

 
In that case I get just EM1.  (I have switched them and it's always the one that's sent first which gets dropped.)
Is there a delay needed between sending emails? 
 
Thanks,
Ben

I'll leave it to CAI support for the definitive answer but that has also been my experience, noticed once when I had a SW bug quickly trying to send multiple message most of the emails were never sent. BTW the other thing I've noticed is if it cannot send an email due to DNS or networking problems it seems to try forever. I've received mail delayed for hours due to failed SMTP server at my ISP.
 
The way the FW appears to work is it attempts to log into the SMTP server, once that is successful it builds the email body and away it goes. I assume WC uses this strategy due to limited storage space
 
So just be sure to build a little delay between emails. My measurements indicate it takes a second or two to send an email. I assume most  of that is due to authentication delays. My systems have sent dozens of email per minute as a test.
 
/tom

What if you increase delay to a longer time?
There are limited four queues for sending out email. When more incoming email to the queue then actually sent, the earlier one got pushed out without sending.  If the server is slow, it will take longer time for email getting through, so that their more chance the later email pushed out earlier ones from the queue.
 
We suppose the later emails are more urgent than earlier one. 
 
Another way to speed up sending emails is by configuring it only send partial result that you must receive.  
 
WC32 send email a lot faster, also with larger sending queue. 

Thanks Tom and CAI_Support.  I thought it was probably something like what Tom said, but wasn't sure since I can't find any mention of a delay between emails, aside from the queue that holds up to 4 emails. 
CAI_Support, I do understand that sending more than 4 emails too quickly will cause the earlier ones to be dropped.  However, the test code in my first post sends only two emails, so it shouldn't be overrunning that queue.  If it works like Tom suggests, where the email sits in a "staging area" while logging into the SMTP server before being moved to the 4-slot queue then that would explain it. 
 
I can easily space the emails out when there happens to be more than one (which isn't often).  My code queues up emails and then sends them from one place in the code.  Making it send them one at a time won't be hard. 
 
Thanks,
-Ben

Please try to increase the delay to 5 seconds and even 10 seconds, just to see if that still happening.  Or put a delay in between.
WC8 board has very limited RAM. Each time sending email will require the firmware gather enough RAM then start sending.
If the sending queue has an odd number, it may be better so that it would not always fall on the first of two pushed out.

CAI_Support said:

Please try to increase the delay to 5 seconds and even 10 seconds, just to see if that still happening.  Or put a delay in between.
WC8 board has very limited RAM. Each time sending email will require the firmware gather enough RAM then start sending.
If the sending queue has an odd number, it may be better so that it would not always fall on the first of two pushed out.

Click to expand...

 
 
Now I had a unmotivated email from the WC32- both would deserve a status page- indicating the status of the stack..... Or even a command EMSTACK delivering the emails in the queue and WGSTACK delivering the webgets in the queue... So we could find bugs easier...

Efried,  Did you have problem with WC32 email?  What they talked is WC8 email. WC32 email is a lot faster, normally send immediately because WC32 has a lot more RAM.  If you have problem with WC32 email, please provide details, not just speculate

CAI_Support said:

Efried,  Did you have problem with WC32 email?  What they talked is WC8 email. WC32 email is a lot faster, normally send immediately because WC32 has a lot more RAM.  If you have problem with WC32 email, please provide details, not just speculate

Click to expand...

 
for both problems having a counter for the number of stacked mails would be helpful for finding the error.

When there is short of RAM, you want to take away RAM for counters, that can only make things worse.  The less RAM left, the slower the email sending will be.  The best practice is to put a delay between emails, so that TCP stack has chance to finish sending.  When earlier email being missed, it is an indication that email sending queued too fast compared to email actually be sent.  It is best to look the logic to reduce emails pushed into the queue.
 
Understand how email queue works will help to best use email.  There are a queue of four emails pending. Each second, it will check if email pending. If there is an email pending, it will try to get RAM and send out.  When more emails coming, if the queue is full already, the earlier email will be pushed out from queue.  Those pushed out email is lost forever. Because RAM limitation, email sending can be longer than one second, depends on how busy the board is working on other things, available TCP socket, and how busy the email server is.  When we deigned it, we suppose the later email is more important to user than earlier email, so that instead of not allow new email append to the queue, we let new email pushed out older email.
 
For example, your board maybe monitoring temperature and reporting them periodically, once a burglar alarm triggered, it will send alarm email.  That later email will pushed out older email from the queue, so that temperature monitoring email could get lost, but alarm email send out.

really? we have seen the use of longer variable types than bits for TTL Output Bits, you could save there. But may be you are talking about program memory.
 

CAI_Support said:

When there is short of RAM,

Click to expand...

VAR and RAM are reserved memory for PLC to use. kernel inside WC can not touch those memory locations. Please do not be confused between memory for system use and memory for user use. All variables in PLC are user memory that already reserved for PLC, system can not use them for itself. 

I also noticed that sending a very short emails via a local smtp server to two email addresses   (em1 em2)  (subject: Wood, message: Needed)
Short and simple enough message. The first always failed until I had a delay of at least 2 seconds, then it was not certain to send both until a 5 second delay.
All in all not a terrible problem, for me at least.

wolvenar said:

I also noticed that sending a very short emails via a local smtp server to two email addresses   (em1 em2)  (subject: Wood, message: Needed)
Short and simple enough message. The first always failed until I had a delay of at least 2 seconds, then it was not certain to send both until a 5 second delay.
All in all not a terrible problem, for me at least.

Click to expand...

 
using the WC as burglar alarm, some instant messaging would be fine...

Efried said:

using the WC as burglar alarm, some instant messaging would be fine...

Click to expand...

 
For "instant" stuff, I use webset. It's lightweight, it's fast, it lets me check that the server has ACKNOWLEDGED its receipt actually within the WC code, and to retry as required. It lets me hammer away commands consecutively in well under a second (I currently fire off up to 8 consecutive websets in a total elapsed time of a little under 2 seconds, and KNOW that they've all been processed at the other end.