MRX TCP Instruction not following Polling Interval

[Bolt]

I have a simple MRX over TCP.  I added an INC counter to it's success to do some testing.  It flies by at WAAY faster than my polling rate.  It's incremented about 8000 counts just while typing this post.  See attached screenshot of my layout.  I moved the increment to 20 seconds for testing, still no luck.

[BobO]

You are jumping out of the stage at the completion of each comm. This results in the box being reset constantly, which zeroes out the interval. You can use it in a stage in an interval mode, but you need to leave the stage enabled.

[franji1]

Although you are using a timed interval, you are JMPing out of that stage when the first comm completes successfully.

When you Jump out of S10 to S11, that DISables S10 and ENables S11.  Disabling S10 causes the MRX instruction to reset its timer - this is the termination behavior.

When you eventually JMP back to S10, the instruction starts up again immediately.  You do not need a sequence of S10 to S11, all you are trying to do is increment a Success counter.  You can do that in S10 without the need for the JMP to S11 OnSuccess.  Just set a bit, and in the next rung, have that bit as a contact driving the INC with a RST of that bit.

Basically, the MRX is not part of a sequence, but is a "background" process, performing the reads at a variable rate (20 seconds?).  You could do that before your Initial Stage with an enabling contact, along with the INC/RST rung below it, followed by the first SG instruction.

We should have a program check rule for this situation, warning you that the construct (timed power-flow based MRX but with an OnSuccess to do a JMP) isn't going to behave like you think it will.

[Bolt]

Thanks, I fixed it.  I have all my other MRX TCP instructions the way you are describing, but somehow I was in a different mindset here.  Yes, I can see why this is happening now.  However, I thought it was just "magic", and the timer stayed active in the background.  I've always read that the Modbus TCP takes care of all the round robin stuff itself, I figured the interval was also taken care of in the background, even when not powered up.

Now, another question, how does this actually increment the Success Count, even if I never reset C407?

[franji1]

My example explicitly RST the OnSuccess bit (after the INC).  In your implementation, you are utilizing a POSITIVE DIFFERENTIAL CONTACT for the OnSuccess bit.

Since the MRX instruction is now doing the background polling, the next time it is time to do the actual packet, it will AUTOMAGIALLY RESET the OnSuccess (and OnError) bits, then after completion (either successfully or in error), it will SET one of those two.  When it is working, it is so fast, you may never catch the OnSuccess bit being OFF.  The edge trigger on your INC gives you good feedback that at some point that bit IS getting reset since the INC value is incrementing.

If you pull the cable on your Modbus Slave (but not Designer), you should see the OnSuccess (and OnError) bit turn off while the Modbus protocol is retrying.  The Timeout for TCP is pretty long, so you should see them both turn OFF, and then the OnError bit turn ON (since it timed out).

EDIT: I just saw that your OnError is a JMP, so you won't see a bit turn on (but you will see it JMP!) after you pull the cable.

[Bolt]

So I was correct, magic is involved along the way!  I was just expecting the magic to be in the interval timer, turns out the magic is in the set bit 
I prefer changing the IP address vs walking around unplugging cords to test.  both scenarios now work as expected.

Thanks for the guidance!

[franji1]

I prefer changing the IP address vs walking around unplugging cords to test.  both scenarios now work as expected.

Thanks for the guidance!

Doh!

You are welcome!