RSLinx running changes update rate?

[davidshaner]

Just saw something strange. I'm running my project with RSLinx off (slow refresh) while looking at some code, web browsing. I check back to my project and it's running with the fast, 365ms refresh rate. I looked around and I can't see anything that may have triggered it. Then, without doing anything except watching my application, it goes back to 1800ms. I have a graph running so I can see the fast scan rate lasted 70-80 seconds. I've watched it closely now for the last ten minutes and it hasn't done it again.

[Archie]

The last Wireshark you posted with a bare bones project is showing about 25ms between the last response to the next request. So even with a bare bones project, it is running slow, which eliminates any code that you may have added. This is looking like something in Windows or .NET

Attached is another patch to try. It continues based on a response and not based on the thread completing.

[davidshaner]

That dropped the slow refresh rate from 1800ms down to 920ms.

[Archie]

So that means the bulk of the wait is in the thread not releasing quickly. I'm still seeing 6-10ms between reads, which is about 2ms with the fast capture. Attached is yet another patch. I don't have access to a PLC right now to test this patch. It does have a risk of high CPU usage, so check that to make sure I'm not generating other issues.

Are any of your values non-BOOL, but the same type such as DINT? If so, is it possible to move those into an array, then subscribe to the array? That can really reduce the update rate because the driver will group them into a single read. So let's say 40 of your subscriptions were DINTS. If they were moved to an array in the PLC, then use the array to subscribe to in the HMI, the driver would put those into 2 read packets. Instead of taking 200+ms to read the DINT values, it would only take about 15ms.

[davidshaner]

The patch had no noticeable effect on refresh rate. CPU usage went from 3% to 26%.


I could consolidate REALs and DINTs and cut about 20 reads. I know there are a couple other things I could do to group the data for fewer reads. At this point the fast/slow refresh isn't a showstopper for this project. I am interested in solving it though, since it would affect how I approach future jobs needing faster scan times or more tags.

[Archie]

I didn't forget about this topic. I've been checking around to see if anyone else sees this same behavior.

[Archie]

I finally have been able to reproduce this. The connection with RSLinx was really just a coincidence. There was a background thread going to sleep for an intended 1ms, but it would actually stay asleep for over 10ms, but when RSLinx started up, for some reason this would then sleep for it's 1ms. When I finally reproduced it, it was intermittent. I reworked the code to eliminate the sleep and now it appears the problem has gone away. An update with the fix should be posted within a week.

As part of the update are some additions to the CLX driver that drastically improves performance on mixed tags (non-array). My testing is showing as much as a 20x performance gain.

[Archie]

Version 3.98j is now available that seems to fix this problem. That version also drastically increases performance. For example, if you were seeing 800ms updates, that should drop down to as low as 50ms with this latest driver.