Distributed and stand-alone loggers/controllers -- part 2

<< cont. from part 1

G.5 Stand-alone logger/controller firmware

The hardware represented by stand-alone, or distributed loggers/controllers, and used as a part of a data acquisition system, provides the physical interface, which allows the PC to measure data from and control real-world signals. The software that is stored and executed from the ROM or EPROM of the stand-alone device, and known as the firmware, controls the continuous operation of the stand-alone device. However, the firmware does not initiate any data acquisition and control functions by itself. Instead, the firmware can only interpret and execute the commands it receives from the host PC so that it knows what actions to take at any point in time.

The firmware performs many functions including:

•Overseeing the correct operation of all peripheral hardware devices (i.e. memory card, display, keyboard)

•Interpreting, checks for error, then acting on commands received via the communications interface or from memory cards

•Sending responses to the computer via the communications interface, including any errors that occur in the communication of the command and in the device itself

•Performing the necessary data acquisition and control functions as specified by the programming commands received from the host PC. The firmware for a stand-alone device is often upgraded by the manufacturer to provide new features and enhancements, and in some cases, bug fixes. Where remote stand-alone devices are operated within an RS-485 network, it's advisable that each unit runs the same version of firmware.

The revision of the firmware is often shown on the local display upon power-up of the device. Where this is not the case, a system command to determine the firmware revision is usually provided.

Quality manuals provided with remote stand-alone devices will include a firmware change history, with the revision numbers and brief description of the changes made with each revision. This allows the user to identify problems that are consistent with a previous revision of the software.

G.6 Stand-alone logger/controller software design

The power and flexibility provided by stand-alone logger/controllers has generically resulted in the hardware, and consequently the firmware that controls its operation, becoming necessarily complicated. This however, does not mean that the commands used to instruct stand-alone devices, need to be complicated. In fact, from a programming point of view it's beneficial to keep the basic command and data structure simple and readable. To this end, a simple ASCII-based command structure is commonly implemented.

ASCII-based command and data response formats are popular because of their simplicity, especially for stand-alone systems where a serial interface has been added with no major design changes to the existing system. Essentially the additional port is treated like a keypad by the stand-alone device.

Depending on the particular application, some of the tasks stand-alone devices are required to perform are as follows:

•Take measurements from sensors at time intervals determined by the user

•Make the measurements from sensors conditional on certain events or environments

•Adjust the sensor measurement rate so that readings are taken more frequently during conditions of greater interest

•Mathematically combine and manipulate sensor readings

•Apply statistical procedures to reduce the number of readings that need to be stored

G.6.1 ASCII based command formats

•Use different data formats so that the data transmitted to the host PC is suitable for a computer program (i.e. spreadsheet package) or a human operator

•Store sensor measurements within the device or onto memory cards for later transmission to the host PC

•Transmit measurements back to the PC as soon as they are taken. This can be by direct connection over the RS-232 interface, by modem through the telephone network, or by radio modem over a radio link

•Control equipment external to the stand-alone device.

This section outlines the basic software protocol (command formats, data formats and error formats) required to program stand-alone logger/controllers as well as detailing the type of commands required to perform some of the tasks outlined above.

It is not our purpose here to detail the exact software structure of a particular stand-alone logger/controller, as this will vary between manufacturers. However, to provide an example, the most important commands, and their use in a program to control the Datataker range of loggers/controllers.

Irrespective of whether commands are sent to stand-alone devices via the serial communications interface or using memory cards, the format of the commands is the same. The PC always generates the command sequence. Programming the operation of the remote devices or reading data from them usually requires the user to enter ASCII command strings only. Commands are sent one at time by using a command terminating character after each command. For terminal emulation packages, this is typically the carriage-return (ASCII 0D). Multiple commands can be included on one line by separating them with a delimiter, typically a tab or space character, then terminating the command string with the command-terminating character.

Although the command format is not standardized between manufacturers of different stand-alone devices, several formats are commonly used. These are:

Word Commands

These are entered as continuous ASCII text, most commonly in upper case characters and also contain one or more command options that specify the functions the command is required to perform. Although they vary between different manufacturers, command options are typically enclosed in brackets, separated by commas (no spaces), and can be random.

Sometimes command options are referred to as command parameters since the user is required to append parameters that specify particular values associated with a command.

These should not be confused with parameter commands.

Switch Commands

These are used as an on/off control function that either enables or disables a particular feature or function of a stand-alone device, thereby controlling its operation. The feature

'X' is enabled/disabled by sending the following switches:

/X feature enabled

/x feature disabled

Parameter Commands

These commands set a value internal to the device that the user may only want to set once, or at least not very often. Parameter commands have a global effect, can be set at any time, take effect immediately and allow the user to set different performance options.

A parameter command can often have a wide range of values within the parameter's limits for a particular device.

Where the stand-alone logger/controller is connected as part of a network, all commands must be preceded by the address of the device for which the command is intended.

G.6.2 ASCII based data formats

All data returned to the host PC from stand-alone devices is in simple ASCII text format.

The format of the ASCII string is entirely configurable by the user and will be sent in the format in which the stand-alone device was requested to send it. Data is typically presented in two mathematical formats:

•Floating point format with 'n' (user configurable) significant digits

•Exponential format with 'n' (user configurable) significant digits

In addition, the ASCII string can be made more readable by the addition of the following text:

•Units applicable to the measurement being taken (e.g. mV, Ohms, Hz etc)

•The channel number and type of signal being measured or type of sensor being used (e.g. 1 V, 2 LM35)

•A channel ID string (e.g. boiler temperature # 1)

•The time and date indicating when the reading was taken (e.g. 10:30 12/12/99) Where the data is to be imported into a spreadsheet software package, it can be formatted so that it contains no additional text except the time (HR:MIN:SEC format) and date (DD/MM/YYYY format), is delimited by commas (ASCII 2C), and each line of data is terminated by carriage return (ASCII 0D).

If the stand-alone logger/controller is connected as part of a network, the data that is returned can be configured to include the address of the device from which the data was returned.

G.6.3 Error reporting

When an error occurs, either in sending a command to the stand-alone device or in performing some function, the error can be reported by returning error messages to the host PC.

Although not differentiated on all makes of stand-alone device, three types of errors are commonly recognized:

•Command errors

•Channel errors

•Operational errors

Command errors

Command errors are reported immediately after a command has been sent to the stand-alone device. They indicate that all or part of the command was either not understood because of incorrect transmission from the host PC, the command contained an incorrect syntax or alternatively the command itself was not actionable. If a command refers to a set of channels, some of which are not used or are an incorrect type, then the appropriate error response is generated but the command is executed for those channels to which it applies.

Channel errors

Channel errors are reported when an error occurs in the measurement from a particular channel. The method of reporting channel errors often varies, depending on the stand-alone device. As well as reporting an error, some devices return a default data error value (i.e. 99999.9) in the logged or displayed data. An example of this type of error is when a channel is read and the analog signal on that channel is out of range.

Operational errors

Operational errors occur when an operational limitation prevents the correct execution of a command. e.g., an operational error occurs when the command input buffer becomes full. This can be due to the command being too long or successive commands being sent too quickly. An operational error would also occur when the data memory became full.

Error Format

The error message is typically sent in some shorthand ASCII notation, but can be sent in a more descriptive (verbose) ASCII form. In all cases the error format is determined by the configuration in which the remote device was requested to send it. The format is usually set by a command switch. It should be noted that error messages can be turned off - typically by a command switch.

G.6.4 System commands

System commands are used to perform system initialization, hardware initialization, variable initialization, system parameters setting (such as the time, date and password), or return the system status.

G.6.5 Channel commands

The versatility and simplicity of use of stand-alone devices lies in the fact that many different types of sensor can be interfaced to the input channels of the device. In most cases it does not matter to which channel a sensor is connected, provided the device is informed which sensor is connected to each channel. The rate at which each channel is sampled is entirely variable. Some channels can be configured to be sampled continuously, while others take a measurement only when certain operating conditions are met. Once instructed to perform a data acquisition or control task (or many complicated tasks), the remote device will continue to operate by itself, taking measurements, storing data if required, or sending data back to the host PC.

Channel commands allow the user to modify specified channels for:

•Input configuration

•Sensor excitation

•Defining channel constants such as resistive shunts and attenuation factors

•Identifying reference channels for thermocouples, Wheatstone bridges

•Scaling of the channel data by spans, polynomials, factors specifying statistical analysis and histogram extraction

•Specifying progressive difference, rate of change, integral assignment of channel data to temporary storage registers

•Assigning unique names to channels

•Specifying format and resolution of the channel data

•Specifying whether data is returned to the host PC, logged or displayed locally.

Some of these channel commands are discussed in more detail below.

Channel excitation

As we have shown, many sensors require some form of excitation in the form of a voltage supply or constant current source, to enable them to output a signal. Excitation channel options inform the stand-alone device of the excitation that is required for a particular channel.

Statistical channel commands

Channels can be read frequently but produce a statistical summary at longer intervals.

This summary is returned, logged or displayed at intervals determined by the pre-defined schedules. Channels that require statistical sampling must include a channel option to indicate the statistical information to report. The following statistical channel options are typically available:

•Average: The sum of all the channel readings divided by the number of readings since the last statistical report. it's very useful in reducing sensor noise by averaging out cyclical noise, such as mains hum.

•Standard deviation: This is the measure of variability of data concerning the average. The variation may be due to noise or process changes.

•Maximum and minimum: This returns the maximum or minimum for the scan period and the time and date that it occurred.

•Integral: This returns the integral (or area under the curve) with respect to the time in seconds using a trapezoidal approximation. The units of integration are those of the original reading multiplied by seconds.

Channel Data manipulation

Data manipulation and scaling of data read from a particular channel can be performed automatically before the data is stored, by using some of the following utilities:

•Channel scaling: This automatically multiplies the value read by the fixed channel-scaling factor.

•Intrinsic functions

These are mathematical functions applied to the data read, e.g.,:

•Inverse (1/x) of the data

•Square root ( ãx) of the data

•Natural logarithm (1n[x]) of the data

•Base ten logarithm (log[x]) of the data

•Absolute value [x] of the data

•Square (x*x)

•Spans: These allow sensors with linear calibrations to be converted to engineering units. The end points of the span are defined by the user and the linear calculation of input signal values performed automatically. This is the same as applying a first order polynomial y = a + bx to the input value x, and is particularly suited for 4-20 mA current loops.

•Polynomial equations

Linearization of non-linear data can be performed using the 'n' order polynomial equation shown in ___ E.

•Channel variable storage

Internal variables are used for temporary storage of the readings taken from one or more channel. These readings can then be added to the readings from other channels or mathematical calculations applied before the data is logged, displayed, or returned to the host.

•Mathematical and logical calculations

Mathematical expressions containing arithmetic operators (+ = * / %), relational operators (< > < = etc), logical operators (AND, OR, XOR, NOT) and trigonometric functions (SIN, COS, TAN etc) can be applied to the value read from the channel.

G.6.6 Schedules

A schedule is a list that tells the remote device which channel or number of channels data is to read, as well as the method by which the reading of data on each channel is to be triggered. When a trigger event occurs, all channels listed in the schedule are scanned, and depending on the type of schedule, the data logged, displayed or returned to the host PC. Schedule triggers

Three different schedule triggers are typically defined:

•Trigger by interval

•Trigger on event

•Trigger when condition is true

Trigger by interval

When using this method, the stand-alone device is programmed to take data readings on each channel at a specified scan interval. The format of the scan interval can be every x seconds, minutes, hours or days. Where no interval is defined, scanning will occur as rapidly as possible.

Trigger on event

When using this method the occurrence of an event on a pre-determined digital input or counter input is used to trigger the scanning of all channels in the schedule.

The trigger events commonly used are:

•Trigger on positive voltage transitions (low to high) of a digital input

•Trigger on negative voltage transitions (high to low) of a digital input

•Trigger on both positive and negative transitions of a digital input

•Trigger after 'n' counts of a counter input

When schedule scanning occurs subject to a digital event, the stand-alone device must be constantly checking the required digital inputs or counter inputs for the event to occur.

This requires that the device must not go into a low power sleep mode. As there are limitations on the speed at which the device can do a check scan of the required digital or count inputs, care must be taken to ensure that the speed of the trigger event is not faster than the check scan rate, otherwise events may be missed.

Trigger when condition is true

In addition to the various methods of time interval triggering or event triggering a schedule channel scan, it's often possible to enable/disable the trigger event using the state of one or more other digital inputs. This would be very useful, e.g., if an alarm limit was reached and this condition was used to enable the trigger event that activated the channel scans.

Types of schedule

Five types of schedule are typically defined:

•Immediate schedules

•Report schedules

•Polled schedule

•Statistical schedules

•Alarm schedules

Immediate schedules

Immediate schedules are used for inspecting and testing input channels and sensors.

When this schedule is triggered, either by a command from the host PC or an alarm condition becoming true, the designated channels are scanned only once and data is returned to the host only. The execution of an immediate schedule channel scan does not disrupt any report schedules that may be in progress and have a higher designated priority. Report schedules

This type of schedule is used for repeated data acquisition from selected input channels and forms the program building blocks of the stand-alone logger/controller program.

The channel scan for this type of schedule can be triggered by

•Time intervals from 1 second to months

•Digital events (conditional on digital state)

•Counter events (conditional on count value)

The data collected from report schedules can be returned to the host, logged or displayed.

Stand-alone devices typically define several reporting schedules (e.g. RA, RB, RC, RD, RX), one of which can be used only for host requests (RX).

Polled Schedule

A polled schedule that is executed only in response to a special command is assigned a unique identifier. This schedule will only occur when:

•The host sends the host request command

•An alarm condition issues the host request

Statistical sub-schedules

Statistical sub-schedules are used for repeated data acquisition from input channels at short intervals, but produce statistical data such as the average, minimum, maximum etc at longer intervals. One or more statistical sub-schedules, each with a unique schedule identifier, are defined. By default, statistical sub-schedules are scanned at the maximum possible rate unless a user-defined trigger is applied.

The channel scan for this type of schedule can be triggered by:

•Time intervals from 1 second to months

•Digital events (conditional on digital state)

•Counter events (conditional on count value) Channels that are to be statistically sampled must include one or more channel options to indicate the statistic(s) that are required.

Alarm schedules

Alarm schedules determine the rate at which one or more channels will be scanned to check if an alarm condition has been reached (see Alarms, below). Multiple alarm schedules, each with a unique schedule identifier, are defined. By default, alarm schedules are scanned at the maximum possible rate unless a user-defined trigger is applied.

The channel scan for this type of schedule can be triggered by:

•Time intervals from 1 second to months

•Digital events (conditional on digital state)

•Counter events (conditional on count value)

Controlling Schedules

When a stand-alone device is connected to a host PC, added flexibility can be achieved by allowing the user to stop, and then resume an individual schedule or all of the schedules, as required. This allows the user to temporarily halt the data acquisition process to check and /or change system parameters or the schedule triggers. G.6.7 Alarms

Alarms are used to warn of error conditions in an application, allowing the user to make decisions when input channel signals, timers, the time and variables exceed specified alarm limits. Alarms are multi-functional and allow:

•Logical comparisons with set points. The conditional tests available are:

•less than (<) setpoint (low alarm)

•greater than (>) setpoint (high alarm)

•outside the range (<>) of two setpoints (high low alarm)

•inside the range (><) of two setpoints (in range alarm).

•Control of digital output channels based on the alarm condition, to turn on alarm lights, control relays, etc.

•Issuing of messages to the host PC or local display that may include alarm data (i.e. alarm type) and alarm time and date.

•Issuing of commands to control operation of the device.

The manner in which alarms annunciate the resultant actions to be performed is often configurable, thereby providing flexibility for the user in meeting the requirements of a particular system or process.

Alarms can annunciate actions in the following manner:

•Alarm actions are performed only once when the alarm state first becomes true.

•Alarm actions are performed only once and only when a predefined delay has elapsed after the alarm condition is first met. When a delay period is defined no action is taken unless the delay period has elapsed and the alarm state has not changed during this period. This acts as a filter to prevent nuisance alarms and unnecessary or rapid actions on digital outputs, which may be caused by noise.

•Alarm actions are performed repeatedly while the alarm condition is true.

•Alarm actions are performed repeatedly while the alarm condition is true after a pre-defined delay.

Controlling Alarms

When a stand-alone device is connected to a host PC, added flexibility can be achieved by allowing the user to stop, and then resume an individual alarm or all of the alarms, as required. This allows the user to temporarily halt a particular alarm, and to allow sensor, or actuator maintenance, without disrupting an application.

G.6.8 Data logging and retrieval

Storing data

There are two places to store data. The first is the internal memory, the second (where applicable), is the optional higher capacity memory card. The amount of data that can be stored is dependent on the memory capacity and /or the capacity of the memory cards, as well as the format of the data that is stored.

If an empty memory card is inserted into the stand-alone device, then all data in internal memory is transferred to the memory card and logging continues to the end of the card memory. If the memory card is removed, logging continues to internal memory. When a partially full memory card is inserted then logging continues to internal memory.

How data is stored

Data is logged in a fixed non-ASCII format (i.e. 24-bit floating point format) to save space. A fixed length header at the start of each schedule scan is used for identification, time and date. When the data is unloaded, the identification header is used to interpret the data and add the required information for the user. This is why schedules can't be overwritten when data has been logged. By using encoded headers and fixed length data, the amount of data required is greatly reduced.

In stand-alone devices, memory is a fixed and unchangeable quantity. Two methods of logging data are available:

•Stop when full mode

Logging stops once the memory is full. This retains data in the order it's logged, the latest data being discarded. Where a memory card is used, the internal memory is used only after the memory card is full.

•Overwrite mode

In this mode of logging data, the memory is organized as a circular buffer.

The oldest data may be overwritten when the memory is full.

Retrieving data

Data can be unloaded back to the host PC either from internal memory or a memory card, usually using simple commands sent from the host PC. A number of options, defining what logged data is to be unloaded, are usually available.

These are:

•All the data, oldest first

•The most recently logged data only

•Data for a particular schedule

•Data from the point in memory where the last unload finished

•Data logged between certain times.

G.7 Host software

The software running on the host PC completes the data acquisition system utilizing stand-alone logger/controllers, and performs two functions:

•Sends the commands that program the operation of the remote stand-alone devices, including what actions to take at any point in time, where to store the data read from the input channels, the data format, and what data to output on the output channels.

•Acquires data from the remote devices and provides analysis, storage and presentation of the data.

The simplest form of software provided with stand-alone devices is commonly in the form of a ready to use communications package with a graphical user interface. This is typical of proprietary software packages such as 'DeTerminal' provided by Data Electronics.

Stand-alone loggers.

More advanced software, either supplied by the manufacturer or developed by the user, provides a higher level of user interface that eliminates the need for the formatting of individual commands and allows the automatic collection of data into files, for graphical presentation or analysis.

Other off-the-shelf software packages that can be used with remote stand-alone devices are:

•Any terminal emulator/communications package

•Spreadsheet packages such as Excel, Lotus 123, Framework, Quattro In all cases, the format of the commands received and the data sent in return by the remote device is still in simple ASCII format, dictated by the firmware in the remote device.

G.8 Considerations in using standalone logger/controllers

Data acquisition and control using stand-alone logger/controllers is an orderly process.

When designing a system that utilizes these devices, users should consider the following:

•The first is the number of sensors and control outputs required, and their location in relation to the host PC. This determines how many logger/controllers are required and their location. Where the analog input or digital I/O requirements are greater than can be provided by a single unit, but the increased channel requirements are localized, expansion modules can be used. If the increased I/O capability must be distributed, more than one logger/controller has to be used and can be connected as part of a distributed network. Where the units are remotely located (e.g. at a remote weather station or an electricity sub-station located in the country) and it's not practical for these devices to be connected directly to the host PC, then two options are available. These are: an operator uploads data using a memory card, and the remote device is connected via a modem to the host PC.

•The volume of data that is to be logged. Stand-alone logger/controllers only have a limited amount of memory. How quickly the memory becomes full depends on the number of input channels to be read and their scan rate. If only a limited amount of data is to be stored then the internal memory may be sufficient. Increased capacity can be provided by a memory card. If the internal memory or the memory card becomes full frequently, then the logger/controller will require connection, either directly or via modems.

•How often stored data must be uploaded to the host PC. Equally important as memory considerations, upload of data to a host PC, is largely determined by the type of application. Logging applications in which the data are gathered for analysis over an extended period (e.g. weather monitoring applications), clearly don't require constant uploading. The frequency of uploading would only depend on the memory capacity of the device and the amount of data being logged. Critical applications requiring constant uploading of process data, feedback of alarms and on-line control would need to be directly connected to the host PC.

•The availability of power. Where mains power is not available, the stand-alone logger/controller is powered from a battery supply. The battery life is determined by a number of factors and is not unlimited. In time, the battery will need to be charged or replaced.

G.9 Stand-alone logger/controllers vs internal systems

G.9.1 Advantages

Logger/controllers enjoy the same benefits of distributed I/O in that they are modular and can be located where they are required. Future expansion is easily catered to by increasing the number of devices in the network.

As well as the ability to make decisions remotely, the use of stand-alone logger/controllers increases system reliability. This is because the stand-alone or distributed system can continue to operate even when the host computer is not connected or functional. It also increases overall system performance, by distributing the control decisions, algorithms and other analysis functions to localized processors.

The analog inputs of plug-in data acquisition boards are typically designed to accept voltage signals. Where the signal levels are small, or the sensors don't output voltage signals, or are remotely located from the PC and affected by noise, then some form of external signal conditioning is required. Unlike distributed I/O, logger/controllers typically have more than one channel per unit, and each one of these channels can be configured for operation with a variety of sensors and signals, not just one type of sensor for one channel. Whilst stand-alone devices don't necessarily have inbuilt filters, these are most often not required since the units can be located very close to the signal source and therefore not as susceptible to noise. In addition, statistical sampling methods, such as averaging a number of measurements or integrating over the noise cycle, help to eliminate cyclical noise such as mains hum.

As stand-alone loggers/controllers can be placed near the signal source and don't necessarily have to be connected to the host PC, the requirement for lengthy cabling, which can be affected by noise, is greatly reduced.

A final advantage is that logger/controllers often include a local operator interface, providing feedback on a system or process at the location of the device.

G.9.2 Disadvantages

When connected to the host PC, irrespective of whether there is a single logger/controller or a network of devices, all communications must proceed via the RS-232 interface. The speed at which data can be transmitted to and from the logger/controller(s) is limited by the speed at which data can be transferred across the single RS-232 communications path.

This is an important consideration where a number of units send information to be logged by the host PC or there is a large amount of data to be uploaded. In either case, the number of samples that can be taken from each logger/controller is limited by the total amount of information that can be sent via the communications interface.

Unlike specialized high-speed plug-in DAQ boards, stand-alone logger/controllers are not designed for the sampling of high frequency signals. Logger/controllers don't enjoy the benefits of high-speed microprocessors, high-speed data bus and fast memory storage facilities such as DMA that characterize modern PCs. Instead, these devices are powered by local, dedicated microprocessors or microcontrollers. The microprocessor not only performs many tasks associated with the operation of the hardware in the device but possibly multiple data acquisition and control tasks associated with the program they are required to execute. This necessarily means that when operating at full capacity these loggers/controllers can only sample signals at a very low sampling rate and are therefore more suited to applications where the signals change more slowly.

A final limiting factor, especially where the logger/controller is operating in stand-alone mode, is that the device has a limited amount of memory. The greater the number of channels and the faster the sampling rate on each channel, the greater the number of samples that will be taken in a given time period. In time, the memory will become full.

Care must be taken to keep the sampling rate of each channel to the minimum necessary, while still obtaining the information required.

Plug-in data acquisition boards can continuously sample data and transfer it directly to the PC's memory. Where even greater storage capacity is required, or the data is to be stored permanently, it can be transferred to the hard disk.

NEXT:

PREV:

All related articles   Top of Page   Home