ModbusRTU driver not closing?

[Archie]

Can you post the file? The only real way of knowing if both drivers are communicating is by looking at the data requested.

[needhmi]

Here is one, attached.

[Archie]

The driver is sending a second request before the first response was received. I will have to setup a test to see if I get this same thing.

Are you using the latest version of 3.99w ?

[needhmi]

I am using 3.99w, that's on the first line of the release notes.  During that log I did manage to change forms just before it crashed.  I can send another one staying on the same form if you want me to.

Thanks!

[Archie]

That capture tells me enough to know what to look for. There is supposed to be a minimum of 100ms in between sends if no response is received. In the capture there are 2 consecutive sends that are only 16ms apart.

[needhmi]

Ok, thanks for your help and work on it as you have time. 

[Archie]

I'm not able to replicate this. Attached is the log file and you can see I am getting alternating Send/Receive.

I'm wondering if your device can handle the 0 poll rate. Try increasing to PollRateOverride to 100 at first, then decrease by increments of 20 to see if the problem starts occurring at any particular rate.

[needhmi]

I set that up with 100 ms for pollrate override and it is still strange it seems, it is sending or receiving faster than 100 ms (see attached) and sends and receives at the same time- which is not the case with yours I see.  A few times I see two sends and two receives.

I may have something fouled up in the datalogger properties, I still have it set up to trigger every sample.  I set Log Interval to 0 and pollrate to 100.   I should confirm - I don't need to worry about the interval or pollrate since the trigger is set to every sample?   It sounds like the pollrate override in the driver properties will override anything else so I was assuming the datalogger properties don't matter in regard to pollrate or interval.

You could be right about the plc, to complicate things more it is getting some of it's data via RS-232.  The actual data stream is much more accurate when the datalogger is only set up on the main form, even so after a close look the data recorded by the basicdatalogger21 tool only changes about every 160 ms even though the HMI stamps the log about every 40 ms (when set up to do so), give or take a few 1000ths of a second...

I also logged the driver with a single form set up and it is also attached.  It looks better in that for the most part it alternates send and receive except for the end but still stamps send and receive at the same time.

I think I'll try a different laptop and see if that helps, the one I am using is old with Vista. 

[Archie]

As I look closer to the data, I can see where the time stamps are the same, the RCVD actually comes before the SEND. If those are switched then the SEND/RCVD will alternate properly. I am unsure why that is happening.

Even with a PollRate of 100, you can see requests coming faster. This is because it may take 2 requests to get all of the data, therefore splitting the PollRate. In other words, the 100ms will be for the same packet to request again. For example, take this packet:

03:41:38.318 Send 1,3,0,7,0,1,53,203,

Looking for the very next time it requests that particular data you will find:

03:41:38.411 Send 1,3,0,7,0,1,53,203,

Which happens to be 93ms later. So it appears it is taking 6 packets to get all of the data, therefore the time between requests should be 16-17ms. Other than the SEND/RCVD being time stamped at the same time, the data otherwise looks normal.

If your device supports large packets, you can potentially reduce that number of request by increasing MaxReadGroupSize to something like 50