I have a Flexy 205 polling an Allen Bradley PLC across ~30 tags. When an alarm ends I have the Flexy trigger an email with an export block to report 3 hours of data. Occasionally, when the alarm ends and I would normally receive the email report the Flexy instead loses connection and I never receive the email. When this occurs the events log shows no events. Please advise.
Hello,
Can you send me a backup of the device with the support files included?
Can you also check the settings in the picture below
Also can you check the Scheduled actions below and tell me if there’s any sendmail info there
Hi Tim,
I just PM’d you a backup of the device.
The settings highlighted in your post match what is shown in your post. In the scheduled actions log, there is only a [successful] NTP synchronization shown.
Thanks,
Connor
Hey Conner,
Do you have any tags the hazard symbol seen below?
Can you go here and hit disable tags in error?
Hi Tim,
No I do not. As I mentioned above, all of the CIP error codes in the log are due to the PLC going offline when I am uploading a new program to it. When I click ‘disable tags in error’ no tags are disabled as all tags are healthy.
–Connor
It might be helpful if you change it to port 443 with TCP instead of 1194 UDP it would be useful because of the packet correction.
Hi Tim,
Thanks for the reply. Where do I change this? How will that help fix the system?
Thanks,
Connor
Hi Conner,
You can change that by going here:
I’ve seen some PLCs run into issues in the pas where the data wasn’t being transmitted correctly and it would cause issues. So with the packet correction of TCP I’m hoping that might stop the reboots
Tim,
I spent a good chunk of the day testing this out and it did not fix it. What else can I do to troubleshoot? This is an urgent client request so would it be possible to set up some type of call or something to get this resolved?
Thanks,
Connor
I can try and jump on a teamviewer if you’d like, it’s just kind of hard to diagnose because the logs are flooded with the CIP errors. As of right now the only other thing I can think to try would be to upgrade to fw 13.2s1
Yeah, I understand. I’m going to clear the log file and try to replicate the error so you have a clean set of logs to work with. I’ll send you a clean backup once I do–does that work? And if there’s nothing in there, maybe we can jump on a call? Thanks for the help!
–Connor
Ok that sounds good to me, Let me know if there’s a good time for you go be available for teamviewer or a call
Just sent you a PM with the backup with clean logs and the time of the disconnect. I am free before 230PM ET to get on teamviewer or a call. Let me know what works best for you.
How about 130 EST
Great, sounds good. What’s the best way to connect?
Preferably through teamviewer if possible
Sounds good. I’ll get on chat at that time and give you the credentials?
That sounds good to me
Tim,
Thanks again for your help with this. One more quick follow-up question. I know the eWON usually connects over UDP. Are there any adverse impacts to forcing it to connect over TCP?
Thanks,
Connor
Hi Conner,
So the big difference between UDP and TCP are that TCP sends packet corrections to make sure that the correct data is being sent. However, because of this it, is a little slower than UDP which just sends out data without any checks to see if the information is correct