Intermittent Communications issue to two PLCs at the same time

[Ken Roach]

>I also clear the DN and ER bits at the end of every pass to keep things clear.

Waterboy and I differ strongly on this topic to the point where it's practically a religious dispute !

I always set up my MSG instructions so they are triggered by a one-shot, and I make sure I don't re-trigger them when they're still in the message queue (the .EN or .EW bits are still set).

The only status bit I manipulate in logic is the .TO bit.

Setting the Timeout bit has the same low-level operating system effect as the message receiving no response within the connected or unconnected timeout period; it completes with .ER and a timeout code.

 

[Drewster1123]

I did something similar with my email triggers. they only trigger a single message when condition to send the email is triggered. That would make a lot of sense to use for alarms.

That's a lot to take in though, definitely need to keep learning about networking and best practices.

 

[TheWaterboy]

Waterboy and I differ strongly on this topic to the point where it's practically a religious dispute !

Yea right, like I'm gonna argue with YOU about anything! I just say it because every document says you don't need to.... but no harm comes from it and I've done it as well, just not in my Telemetry sequencing as it messes with my diagnostics

Oh ... and I have had trouble with the .TO bit in PLC-5's that never got explained so that is a hill I will argue over. With later processors its simple to change the timeout and that essentially does the same thing but works every time.

 

[drbitboy]

would it be worth it to split into msg that need to be triggered ASAP and have a cascade for those messages and then another cascade with messages that trigger every 30 seconds or something? just curious. not sure if I would need to do that for this application but there are many other machines here that I may need to do that with.

A simple way to have batting rates for different messages without conflict is to have an integer or counter that increments for each completed or failed message, and resets after say 30 messages to 0, and have the logic examine the count to decide which message to send at each value, e.g. the 1Hz (every 1s) message is triggered when the value is less than 29, and the 1/30Hz (every 30s) message is triggered when the value is 29. One 1Hz message is missed every 30s, but maybe that is acceptable.

 

[JankyPLC]

The fact that all cascaded you end up with 800ms time slice to get through them is a good indication that the 250ms of your original setup definitely had the potential to cause issues.

As for splitting up the ASAP messages vs the longer cycling ones, you could keep your single message chain, put all the ASAP ones first, and then the delay timer with the rest after it and if timer isnt done, skip those and cycle back to first ASAP. If timer is done, send those and come back around.

Can vouch for checking data and only sending what you need. Had a system with an array of 100 ints all needing to be messaged individually in sequence at once. Took almost 2 seconds every time. Started storing array ->array last every time messages sent and comparing before sending, so only sent the parts of the array that changed, and cut msg time down to 300ms on average because most values didn't change most of the time.

Thank you for your insight Waterboy, I'm learning from this thread too!