Flexy Crashes on Export



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.



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.



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.



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?



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



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?



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!



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



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?



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