Issue
The object information received from a MicroNet and IAC controller is based on a request for information from the Xenta.
If the local area network receives too many requests, the system will not operate as quickly as expected.
It is important to configure the objects with a realistic poll time to avoid issues with slow system response.
Product Line
Satchwell MicroNet
Environment
- Xenta 500
- Xenta 700
- Satchwell MicroNet
Cause
Slow graphic, alarm, updates
Resolution
Updated June 2019
The MicroNet 50 series range MN350, 450, 550, 650 LCD and Touchscreen have been withdrawn from sale.
The IAC 420, 600 and Touchscreen have now also been withdrawn from sale.
No direct replacement is offered.
Further information on these changes can be found in PA-00495 - Notice of Withdrawal - Satchwell Sigma and PA-00528 - End of Commercialization - Satchwell Sigma.
----------------------------------------------------------------------------------------------------------------------------------------------------------
Network Architecture
The size of a MicroNet/Satchnet network within XBuilder is not limited. It is quite possible to have 80 Unifact Pro controllers directly connected on an NCP RS485 network; ARCNET and Satchnet networks with routers can be much larger than this. With such large networks, to achieve acceptable system performance, the number of signals requested and their poll rate must be considered when engineering the Xenta 555.
Note that Satchnet networks run four times slower than MicroNet NCP networks.
Bandwidth and Performance
Because both MicroNet and Satchnet networks are polled, there is a limited bandwidth available in which to obtain all signal data. This means that it is necessary for the Xenta 555 to request each programmed signal (point) in turn from each controller. There are many factors which deter-mine the performance of a network, however it is generally accepted that certain signal parameters should update more frequently than others. The Xenta 555 has a special dynamic poll scheme that is inherent in the controller and needs no configuration. The polling of any signal depends on the signal type and its poll frequency. Priority is given to signals with the fastest poll rate; therefore some mea-sure of control can be applied to the prioritization of signals. The most important signals should be configured with the fastest poll rate. In the event that a particular signal is referenced more than once, for example, in an alarm, log and web page, that signal appears in the poll scheme once only and is polled at the fastest rate (that is, the fastest of the alarm rate, log rate or web page rate).
Typically, the order of engineering priority should be:
1 Alarms
2 Web pages
3 Logs
Tip
Connection objects should be kept to a minimum because each connection comprises a read signal and a write signal (that is, two operations).
Performance example
Consider a Xenta 555 ARCNET or NCP network with three web clients showing three web pages (two alarm pages and one values page with 50 signals).
The Xenta 555 configuration comprises a total of 480 signals: .
100 alarm signals set with a scan time of four seconds. .
300 logs at a logging interval of one hour. .
30 connection objects at a period of 10 seconds.
50 point signals on a values page with a fixed refresh time of 10 seconds.
In this network, the signals will arrive in the alarm pages typically within 60 seconds. Connection objects and signals in values pages will update within 60 seconds.
The Xenta 555 polling algorithm computes the optimum poll rate for each signal, therefore if the sum of the poll frequencies exceeds the available bandwidth at any particular time, the lower frequency polls will be delayed. This has the effect of spreading the polls out over the available bandwidth and therefore optimizing performance. Signals on graphics pages and values pages are only polled when the page is being displayed in a web browser, however when a signal is required for logging, alarming or for a connection object, the signals are continuously polled at the configured poll time
Web Page Updates
Some examples of expected polling rates follow: -
In addition to MicroNet network updates, web pages are updated at regularly intervals and this should be considered when analyzing the over-all performance; ten seconds should be considered typical for a web page update. However, polling performance is affected by the number of web clients and the number of web pages. If each web client simultaneously requests a different web page, each with a set of signals not currently being polled (for example, alarms), then the number of polled signals will increase substantially and therefore slow down the rate of web page updates. For this reason it is recommended that the number of web clients is restricted to three for a typical Xenta 555 network as described in the example given earlier.
Due to a slightly enhanced Native Communications Protocol (NCP) and Attached Resource Computer Network (ARCnet) employed by the 50 series controller a small difference between the 100 series and 50 series controller Packets/Min can be seen, these are indicated below.
Xenta555 - MNMI NCP Polling 50 Objects
10 Polls/Sec
426 to 595 Packets/Min
MN620 526 Packets/Min
MN650 567 Packets/Min
Xenta555 - MNMI ARCnet Polling 50 Objects
10 Polls/Sec
426 to 595 Packets/Min
MN620 484 Packets/Min
MN650 495 Packets/Min
Xenta555 - SNP 1200 Polling 50 Objects
2.5 Polls/Sec
169 to 174 Packets/Min
Xenta555 - SNP 4800 Polling 50 Objects
7.5 Polls/Sec
398 Packets/Min
These times are the averages found during testing, these figures will be affected by the following: -
1. The amount of controllers on the LAN (The Xenta 555/731 carries out some background polling an each controller for online and null output status).
2. The controller type has a small bearing on the polling rate per second.
3. Quality of the communications wiring.(poor wiring or incorrect cable specification can cause errors and re-tries)
4. Quality of the controller wiring, particularly with ARCnet installations. (Unscreened inputs ETC can result in noise reaching communications cable causing errors).
5. With the Xenta 731 particularly a high level of Menta programs ETC can cause time delays if the Xenta processor struggles to process all the information in good time.
Further information can be found in the TAC Xenta 555 Supplement Manual.
