Improvement for scan_rate

[PeterChristen577]

Using ethernet-ip in Node-RED, I did some analysis of the realtime behaviour using Wireshark. There I have seen the real scan rate (320 ms) does not match the setup in the project (200 ms). Before the scan rate set up as the time delay between the last resonse of the PLC and the next request. In case of longer tag list (up to 30 tags), there are two tag groups exchanged.
Now there is a timer used that triggers the start of the request more precise.

Description, Motivation, and Context

The use of "delay" does no provide a scan_rate who meets the value setup, even if the tag list is longer as e.g. 30 tags.

How Has This Been Tested?

PLC: CompactLogix L32E
Host 1: PC with Windows 10 and Node.js 12.16.2 (x64)
Host 2: Raspberry PI with Raspian and Node-RED v1.0.5
Ethernet packet captured with Wireshark.

Screenshots (if appropriate):

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.
• This is a work in progress, and I want some feedback (If yes, please mark it in the title -> e.g. [WIP] Some awesome PR title)

Related Issue

[alex-controlx]

scan_rate designed to create a safe delay between the scan requests. Also setting an interval on external communications is bad practice. On a poor network it can end up with number of sent requests without responses. Also if I have 1000 tags to scan then request/response time might take longer that setInterval delay which will cause sending another request of 1000 tags without receiving response for the first batch.
Also timer variable is created locally. What if I want to pause the scan out of the scan method.

If you need to get the responses faster, I would suggest just to reduce the delay: the scan_rate.

[coveralls]

Pull Request Test Coverage Report for Build 152

• 4 of 4 (100.0%) changed or added relevant lines in 1 file are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.1%) to 51.14%

---

Totals
Change from base Build 141:	0.1%
Covered Lines:	475
Relevant Lines:	886

---

💛 - Coveralls