A) This is a configuration parameter which allows you to poll different tables in different RTU. It must be set in configuration file.

Q) Section 5.9.2 - Generic Parameter Name - NoPollPeriod - how can this be a driver specific parameter when it is individual tables within a MOSCAD RTU that could possible have a no poll period?

A) This is a INI parameter. This setting will gurantee that during the NoPollPeriod there is no polling request sent to RTU on each channel.

Q) Device Scope Name - NoPollPeriod (use in [NameOfDevice] section of INI - refer to 5.5.2) - What is meant by this, when all that exists in section 5.5.2 is an address of an RTU between 1 and 32767?

A) In 5.5.2 Address section, there are two parts, one is "a" which is the RTU address between 1 and 32767. Another part is NameOfDevice which is used to associate this unit with the parameter defined in the Citect INI file defined by the section [NameOfDevice]. This means when this field is defined, driver will read all parameters setting from Citect INI file [NameOfDevice] section.

Q) Section 5.10 - Configuration File - Why does the structure of the tables within the RTUs have to be redefined in ASCII files for Citect? The MOSCAD IPGateway API gets information based on table#,row#,column#. This data is entered in the Address field of the Variable Tags form in the Citect Project Editor. What's the point of retyping the information as an ASCII text file? At the very least, if the table structure needs to be known, couldn't the binary file generated by the MOSCAD Programming Toolbox be parsed in order to obtain the information? The requirement to duplicate the same information is a vulnerable source of errors, as well as very user unfriendly.

A) Driver needs this information to build the cache. As far as I know, there is no utility we can use to generate the configuration file automatically.

Q) Section 5.10.2 - Table 4 - If only 1 column is defined, shouldn't the text command be either "discrete" or "real' and not "discrete real real"? - See last comment of previous paragraph.

A) That should be three columns in table 4.

Q) Section 5.10.3 - Sample of an INI file.

Station=SIMON - What's the point of this? Nothing mentioned about this parameter in section 5.9.

A) The name of the master station. The Master station is the one responsible for polling the moscad gateways. It is only useful in the INI file.

"SIMON" is the station name.

Q) Channel=7 - What's the point of this? Nothing mentioned about this parameter in section 5.9.

A) Channel = 7 sets the mode of the channel.

Since it follows the station name definition and preceeds any specific channel. (e.g. SIMON) It is the default channel mode for any following channel definitions:

Channel modes are a combination of 1,2,4,5,and 7

0: Normal (No burst)

1: Send

2: Receive

4: Burst

It is possible to sum them : 1 + 2 + 4 = 7

Q) Multiplexed =1 (or 0 as for in [SIMON1]) - What's the point of this?

Nothing mentioned about this parameter in section 5.9.

A) This permits multiple requests on a single channel.

Q) 1) What's the need for [SIMON0] [SIMON1] [SIMON2]?\

2) Can't all the RTUs be defined in the one .cfg file?

3) Why are the polling definitions defined in the .cfg file?

4) Why aren't the Cache or Scheduling sections of the I/O Device form in the Citect Project Editor not used?

5) In different tables or sections of the same table were to be obtained on different poll frequencies within the one RTU, why not define a 2nd I/O device with the same RTU address?

A) 1) Polling definitions are defined in cfg. The cfg captures the MOSCAD unit definitions and table definitions. This parameter format is not supported by "ini" style data entry where a parameter occupies one line.

To have different tables on the same unit polled at different frequencies is not supported. The Full (integrity) poll, Change of State (COS) Poll and burst modes allow for optimising through put.

2) Yes all RTU can be in one .cfg file as specified by the MOSCAD(user spec).doc. You only need use different setup files (*.cfg) if you need to have multiple channels eg

[MOSCAD]

station = BASE

setup = "...defaultChannel.cfg"

[BASE0]

setup = "... firstChannel.cfg"

[BASE1]

setup = "... secondChannel.cfg"

where the intention is to use firstChannel to get to data for units, UNIT1 - UNIT20 say, and also use secondChannel to get to data for units, UNIT21 through UNIT30 say. So the idea is flexibility. However you can use one one default configuration file, as for defaultChannel.cfg in the above example.

3). & 4.) Cache and scheduling sections in the IO Device form apply only to IOServer caching. Not the drivers. Please be aware that the MOSCAD driver is a Front End / Back End (FE/BE) driver. Which means that there is an internal driver cache - separate from the IOServer cache.

Note: The parameters in the .cfg file pertain to the BE of the driver. I.e. the driver has a back end polling engine which will perform the regular polling tasks and processing of burst data regardless of data demand from the IOServer.

5) The channel will transmit data in one of the following means. Full (Integrity) Poll, COS Poll and burst modes. The combination of these will allow the engineer to optimise the bandwidth/throughput for the channel.

Q) How do I utilise a 'C_Bit'? Should I put in 8 consecutive "discrete" entries in the .cfg file, or is a single "C_Bit" valid?

A) Single "C_Bit" is valid. You can use "cbits" in the cfg file.

Q) I know that all columns need to be defined in the tables section of the .cfg file, even if they are not being used.

What would happen if a column that was not being used had the incorrect type?

A) It will fail during initialization.

Q) Would the driver be able to get the correct information for those columns that did have variable tags defined?

A) NO

Q) Page 20 of the Driver Spec, section 2.10.2 gives an example of a .cfg file. This file shows that both the table and RTU have a "Polled" parameter. If tables that are designated to be polled are allocated to an RTU that is NOT designated as "Polled", will the tables still be polled?

A) We think so, when a manual poll request is made, the driver will attempt to poll the gateway for the tables alone.

Q) Conversly, if an RTU is designated as "Polled", but of all the tables assigned to it, NONE are designated as being "Polled", what happens?

A) The RTU will be polled using IP and EP.

Q) Page 20 of the Driver Spec, section 2.10.2 gives an example of a .cfg file. This file shows the RTU Ratio parameter set to 2 (2 event polls between integrity polls). I guess that an event poll results in the retreival of tag data from an RTU. What is looked for with an integrity poll?

A) Integrity poll will request all configured data in the device.

Q) Can the integrity poll be switched off?

A) Yes, remove the 'polled' parameter from the unit definition.

Q) If the driver has successfully retreived data in an event poll, why can't the integrity of the RTU be considered as OK? Why then generate the extra radio traffic for an integrity poll?

A) Can you guarentee that there has been NO changes to RTU data that were not reported in an event poll or burst data? Can you guarentee that your analogue points will not drift in such a way that they will not be detected and hence not reported in either event poll (EP) or burst data. The purpose of integrity poll (IP) is to resynch. So that any drift etc which is not captured by the event poll or burst data is corrected. Typically if your event poll and burst data are configured well you can wind out the interval of the Integrity Poll

eg Aa good system with little drift could last a whole week between Integrity Polls.

Q) In the .cfg file, an RTU can have a poll Period defined. In the [MOSCAD] section of the Citect.ini file, a NoPollPeriod can be defined. What's the difference?

A) The Period in the *.cfg specifies the time between polls, (IP and EP). The [MOSCAD] NoPollPeriod, is there to free up a channel from over crowded transmission (eg a radio where there are excessive polls happening). The NoPollPeriod is the minimum spacing of polls on a channel.

eg There are a dozen gateways on the one channel say, when we issue polls to the different gateways (say all have an IP configured at similar poll periods) we want them to be separated by a small amount to let any burst data to be received. If not you could get 12 polls(one for each gateway) going out one after the other clogging the channel and preventing either controls or burst data from being sent/received.

Q) If no persistant cache path and filename is given for an RTU, what is the consequence?

A) If you do not specify a path and filename there will be no persistent cache written. Hence on consequent start up the persistant cache will not be loaded. You will not benefit from having the data available (even if it is old) prior to connecting and must wait for integrity polls to be completed.

Q) Page 11 of the Driver Spec, section 2.7.1. A number of options are available for use with the RTUStatus IODevice Type, of which I guess 1 must be selected. I guess that "STALE" indicates that the data from the RTU is stale. What timespan defines it as stale? What is the meaning of the other options?

A) The timespan would be defined in the RTU itself, you will need to consult your RTU spec/configuration manual. For the definition of the other status bits will also be in the manual.

Q) Page 12 of the Driver Spec, section 2.7.1. What is the meaning of the Tag Status? What's the point when the RTU Status is already available?

A) The tag status gives point quality. Eg. a series of points(tags) may come from other devices that are further in the field, ie an RTU is operating as a data concentrator as well as collecting local data, in this situation the RTU status only reflects the local RTU's status, if you give quality on a point by point basis you then are able to determin if the remote/upstream RTU is going OK. (There are countless other examples)