MSG error at remote site communicating via satelite

[Handcraftedsince87]

Good morning,
We have a remote site that has a Micrologix 1100 that is really only used to send out MSG instructions (Email to a SMTP server) if the power goes out/comes back on. I was out there yesterday troubleshooting why a MSG had been sent that the power had gone out, but not come back on. Part of the problem was that it's on a Battery backup, which had completely drained, so I believe the PLC booted up when the power came back on and either didn't send the MSG out, or it tried but the modem hadn't connected yet. I should add that we are using a fairly slow Hughes net satellite connection.

After toggling the power relay I found that if it happened to quick, the second MSG (Power back on) would get an error. The error was "DD" which I believe is a "General SMTP" error, and the more specific .22 error (where you move the MSG9:0.22 to an integer file) was a "1501" which I understand to be a "communication error with SMTP mail server". I thought this was possibly due to messages getting stacked based on the slow internet connection and causing an error in the second MSG? I started to add some buffer logic to delay the sending of messages to around 90 or 120 seconds if one was already being sent, but ran out of time and had to head home (No overtime).

I'll be heading back out tomorrow to finish my logic and give it a shot, but wanted to see if anyone else might have an opinion on the matter, or other things to look out for.

regards-

 

[widelto]

Maybe you can setup another msg only when plc starts up and disable power back on msg. This new msg must include date/time when power went out and date/time when plc restart ocurred, this way you can be sure that power outage time was greater than what ups can supply.

 

[Firejo]

Why not just use the message instructions error bit to reset the message instruction (unlatch the enable bit)? That way if it errors it will keep trying until it goes done.

 

[widelto]

Why not just use the message instructions error bit to reset the message instruction (unlatch the enable bit)? That way if it errors it will keep trying until it goes done.

Yes, besides my advice, what firejo said is necessary.

 

[Handcraftedsince87]

I didn't think of that Firejo, thank you. I'll give it a shot

 

[Handcraftedsince87]

Why not just use the message instructions error bit to reset the message instruction (unlatch the enable bit)? That way if it errors it will keep trying until it goes done.

I guess I am a little confused on how to do this in rslogix500 as I'm not having any luck with the logic I've tried so far. Could anyone elaborate? I seem to be having a brain ****. Thanks

Edit: We can't say brain f a r t?

 

[Phil Buchanan]

In addition to what Widelto and FireJo said you may be best serverd to change your programming in such as way that messages will not trigger unless a permissive is met such as verified comms to the modem or to your primary site etc.

I would verify power had been on or off for x amount of time and that I had reliable comms PING before I sent any messages. You can still time stamp the exact time the event happened but wait until your modem is back up and talking before you send it.

I like to send a heartbeat every once in a while also. On installations like this every hour or so at least.

 

[Handcraftedsince87]

I should state that waiting for the connection to come back up is not a problem anymore. I've got logic to delay the 1st msg send now. And we have constant monitoring of our connection already through a different platform that uploads a database once an hour. Im just looking for the logic to resend a message again after an error. The error faults seem to be random. It's a 1501 smtp error that I can't tell if it is on our mail server side. But if I can re send the message it eventually goes through. Just can't figure out the msg er re-send logic part.

 

[Firejo]

There are several ways to do this. The picture shows a couple of different ways that I might set it up. The top routine is what I do if I want the message instruction to run continuously. The rung goes true which enables the MSG. When it goes done or errors the enable bit is unlatched and because the rung is still true it fires again. The second example is what I would do if I wanted the MSG to fire once but needs to keep trying until successful. The rung goes true, the MSG is enabled and if it goes done then the bit “B3:0/0” is unlatched and the MSG stops. If the MSG errors the enable bit is unlatched and with “B3:0/0” still closed the MSG re-fires.

 

[bernie_carlton]

I think the ONS in rung 2 is unnecessary and, worse, will actually prevent a re-trigger of the message instruction in case of an error.

 

[Firejo]

I think the ONS in rung 2 is unnecessary and, worse, will actually prevent a re-trigger of the message instruction in case of an error.

Good catch Bernie. Yes the ONS does prevent the MSG from re-firing. Don’t put one in.

 

[Handcraftedsince87]

Thank you Bernie and Fire Jo. That was exactly what I was looking for. I thought I had tried the Unlatch instruction but I could be mistaken, as I tried a number of things that day. It was a busy day and had a lot to get done. The site is actually pretty close to Bernie just outside of Yakima. I'll be back out there sometime this week and I'll give it a shot.

Thanks again guys.