         |
G.1 Introduction
As with other forms of data acquisition hardware, stand-alone logger/controllers are designed to measure and record real world signals, as well as to act on these signals to provide control of a system or process. In addition, stand-alone logger/controllers have many features that distinguish their operation and use from other data acquisition hardware, such as plug-in boards and distributed I/O.
This section looks at the hardware and software configurations of stand-alone logger/controllers, the system configurations for which they can be used, and the features that allow these devices to meet specific requirements in the field of data acquisition and control.
G.2 Methods of operation
Stand-alone logger/controllers are intelligent devices, capable of performing complex data acquisition and control functions, as well as making decisions based on current system or process conditions. To do this they must first be programmed, typically by a sequence of ASCII-based commands formatted by the host PC, which are interpreted and executed by the device so that it knows what actions to take at any point in time.
Once programmed, the stand-alone device can continue to operate, taking sensor measurements, logging the data to memory and performing control functions, even when the host computer is not connected or functional. From an operational point of view, it is this important feature that distinguishes stand-alone logger/controllers from other data acquisition hardware, such as plug-in boards and distributed I/O.
Two methods of programming - the stand-alone logger/controller, and uploading logged data to the host PC, are available, either by the RS-232 serial communications interface or by using portable and re-usable memory cards.
This flexibility allows stand-alone logger/controllers to be operated in a number of ways, depending on the required location, volume of data to be stored and availability of power:
•Stand-alone operation with periodic data recovery (and programming where required) using memory cards or a portable laptop PC
•On line to a host PC with periodic uploading of data (and programming where required)
•On line to a host PC via modem, with periodic uploading of data (and programming where required), initiated by either the host PC or the remote device Where an application requires many more sensors than can be provided by a single stand-alone controller, and these are distributed over a large area, a distributed logger/controller network may be required. Each mode of operation, employing only a single logger/controller, is also applicable when more devices are connected as part of a distributed network.
G.2.1 Programming and logging data using PCMCIA cards
The credit card size portable memory card provides a reliable media for transporting data and programs, but requires a memory card interface connected to the RS-232 serial port of the computer. This is shown in Figure G.1.
Figure G.1: Using memory cards to program and log data from a stand-alone
logger/controller (Computer Memory Card Interface PCMCIA Card Remote Data Logger
Stand-alone logger / controller; Thermocouples Strain; gauges Relays)
Programming the operation of a logger/controller and recovering data using the PCMCIA card is especially useful when the logger/controller is remotely located and/or not connected to a host PC. Even when connected to a host PC, the storage capacity of the logger/controller can be greatly increased by leaving the PCMCIA card permanently inserted in the device. This is its intended use since it also increases system reliability because data is logged directly to a semi-permanent storage medium.
G.2.2 Stand-alone operation
As their name implies stand-alone logger/controllers are specifically suited to be operated independently of the host PC. This makes them especially useful where the device must be located in a remote and/or particularly harsh environment, or where they are unable to be continuously connected to a host PC, either directly or via modem.
Special applications, such as temperature monitoring of a refrigerated truck, or weather reporting at a remote weather station, make use of a logger/controller in a stand-alone configuration. In these real life applications the stand-alone device can be either programmed, in the office or with a portable laptop, then left to operate, powered from a local power supply. Data stored in the device's memory can be periodically uploaded using a portable laptop PC or memory cards.
When operating as a stand-alone device there are several important considerations.
Where it is necessary to power the unit from a battery supply, irrespective of whether the battery supply is rechargeable, battery power is not unlimited. This requires that the batteries be either recharged, or replaced where they are not rechargeable. Another important factor is that stand-alone units have 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. The memory capacity of a device can be greatly increased by leaving a higher capacity memory card in the device and logging data directly to the memory card.
G.2.3 Direct connection to the host PC
The most common system configuration, and one which provides the highest system reliability, is a direct connection to the host PC via the RS-232 communications interface as shown in Figure G.2. This setup allows frequent uploading of data, constant monitoring of alarm conditions and on-line system control. It is most likely implemented in industrial plants or factories, where critical processes must be constantly monitored and controlled.
The maximum distance that the logger/controller can be located away from the host PC is dependent on the baud rate of the communications interface. When a single logger/controller is directly connected to the host PC, it can be configured to return data as soon as it is available..
Figure G.2: A direct connection to a stand-alone logger/controller via an
RS-232 serial interface
Where an application requires more than one logger/controller, and each unit is distributed over a large physical area, for example, in an industrial plant or factory, the logger/controllers can be configured as part of a distributed RS-485 multidrop network. A single unit, deemed to be the host unit or local unit, can be connected directly to the host computer via the RS-232 serial interface, as shown in Figure G.3, thus avoiding any requirement for an RS-232 to RS-485 serial interface card.
Figure G.3 Distributed logger/controller network
An advantage of this implementation is that other host PCs, printers or terminals can be connected to the RS-232 ports of other logger/controllers further increasing system reliability. This system configuration is shown in Figure G.4.
Figure G.4 Distributed logger/controller network with additional host
How frequently logged data is uploaded depends firstly on how critical the immediate analysis of data is to the system or process being controlled, and secondly on how much memory is available and how quickly it will become full.
How quickly the memory will become full is important for two reasons. During failure of the host PC or communications interface, there must be enough memory to allow data logging to continue without loss of data. In addition, a device connected to the host PC via a multi-drop network can only return data when requested by the host PC. Where a large number of units are connected to the host, the memory of each unit must be large enough to allow data logging to continue without loss of data, until the next time the host requests a data upload.
Aside from this specific limitation, it is good practice to recover data as often as possible since any sensor errors, power supply failures or problems with the unit itself will be detected early, thereby increasing system reliability. In addition, frequent data recovery will help to minimize the chance that data may be lost due to device failures such as battery-backed memory failure.
G.2.4 Remote connection to the host PC
Another useful configuration is the connection of remote logger/controllers to the host PC using modems via either a telephone network or radio communications. In large factories or industrial plants, where one or more devices are distributed over a wide physical area, the closest logger/controller to the host PC may be too far away or too greatly affected by noise to allow connection to a host PC via the RS-232 communications interface. In such applications, the use of radio communications is a practical solution. When radio communications take place between the host PC and the distributed network, all communications must go through the logger/controller to which the remote radio modem is connected. This is shown in Figure G.5.
Figure G.5 Remote connections to a logger/controller network via radio communications
In many applications, the stand-alone logger/controllers are not contained within the same factory or industrial plant, but located at a distance beyond the capabilities of radio modem communications. An example of this would be a remote electricity sub-station used to monitor alarm conditions, provide on-line voltage, current, and power readings to a central control room. Communications between the host PC and the remote units via the telephone network is shown in Figure G.6. A dedicated phone line allows frequent up-loading of data to the host PC, constant monitoring of alarms and on-line system control, where required.
Figure G.6 A remote connection to a logger/controller network via the telephone
network
G.3 Stand-alone logger/controller hardware
The important features that give stand-alone logger/controllers the power and flexibility to operate, either as stand-alone devices, or as part of a distributed network, fundamentally lie in their relatively complex hardware structure. The simplified hardware schematic of a typical stand-alone logger/controller is shown in Figure G.7.
Figure G.7 Simplified hardware schematic of a stand-alone logger/controller
The following hardware components discussed in this section are:
•Microprocessor
•Memory
•Real time clock
•Universal asynchronous receiver and transmitter (UART)
•Counter/timer circuitry
•Input multiplexer and elector
•Power supply
•Power management circuitry
•Analog and digital I/O circuitry
G.3.1 Microprocessors
At the heart of the stand-alone system is the microprocessor or microcontroller. In conjunction with the embedded software (firmware), it provides the control and functionality of the system.
It is important to clarify the distinction between microprocessors and microcontrollers.
A microprocessor is just the central processing unit (CPU) part of a computer, without the memory, input/output circuitry, and peripherals needed for a complete system. The Intel 8088 and 80286 chips are microprocessors. All other chips in the PC are there to add features not found within the microprocessor chip itself. However, when a microprocessor is combined with on-chip I/O, memory and peripheral functions, the combination is called a microcontroller.
The microcontroller is probably the most popular choice for stand-alone systems, as it provides the necessary peripheral functions on chip. The advantages of microcontrollers include reduced cost, a reduction in chip count and hence reduction in printed circuit board 'real estate'.
G.3.2 Memory
Non-volatile memory, used for the storage of sensor measurements and control parameters, is an important feature of a stand-alone system. Typically, random access memory (RAM) is used for data storage and requires some form of battery backup to maintain the contents during power loss.
Manufacturers of stand-alone controllers are now incorporating memory card readers that allow measurement data to be stored directly onto memory cards. The memory card can subsequently be removed and the data transferred to a host computer.
ROM / EPROM
The embedded operating system or firmware of a stand-alone device is stored in either read only memory (ROM) or erasable programmable read only memory (EPROM).
Once-only programmable ROM technology is typically used in systems where high volume manufacturing is involved.
EPROM technology is therefore more popular in low to medium volume stand-alone systems, as it allows manufacturers to modify firmware, incorporating new features or enhancements, without committing to the volume requirements of ROM technology. To allow easy installation and replacement of the ROM or EPROM chip during the lifespan of the device, these chips are usually mounted on the circuit board via a socket.
RAM
Random access memory (RAM) is generally used in stand-alone systems for the storage of measurement data, control, and system parameters. The two most popular types of RAM technology are static and dynamic. Dynamic RAM requires periodic updating or refreshing, whereas static RAM does not require refreshing. However, the advantage of dynamic RAM over static RAM is a far greater memory capacity for a given area of silicon.
Dynamic RAM is suitable for a personal computer used in an office environment where memory capacity is an important requirement. However, in a stand-alone system the advantage of static RAM lies in its ability to maintain the data contents, using a backup battery, in the absence of main power. This can be achieved with relative ease, because static RAM does not require refreshing, even in standby mode.
EEPROM / FlashPROM
Electrically erasable programmable read only memory (EEPROM) is a non-volatile memory technology, generally used for the storage of limited configuration data and control parameters. The moderate memory capacities and slow write cycle of EEPROM (typically 10 milliseconds) limit its application.
Flash programmable read only memory (FlashPROM) is also a non-volatile memory technology, and is used for both mass data and program storage. FlashPROM is available in memory capacities ranging from 32 Kbytes to 2 Mbytes. The much shorter write cycle of FlashPROM is achieved at the expense of having to erase data on the chip in fixed-size blocks rather than a byte at a time.
Memory Card
Similar to RAM, plug-in memory cards are also used in stand-alone systems for the storage of measurement and control data. Although there are a number of memory card manufacturers, the Personal Computer Memory Card International Association (PCMCIA), USB Flash and similar standard cards, have become very popular for use with notebook computers.
PCMCIA memory cards are available in ROM, one-time programmable ROM, static RAM, UV EPROM, flashPROM and EEPROM technologies. The static RAM PCMCIA cards are the obvious choice for data storage in stand-alone systems, and are currently available in memory capacities ranging from 64 Kbytes to in excess of 8 Mbytes.
An important advantage of memory cards in a stand-alone system is their ability to be removed and replaced with another blank card in the field, providing a convenient data transfer mechanism. Additionally, memory cards allow the user to purchase and install only the memory capacity required for a particular application.
G.3.3 Real time clock
The real time clock (RTC) is an important part of any stand-alone system. It not only provides the necessary date and time information, but also provides periodic and alarm functions for triggering the reading of sensors and controlling outputs under program control.
The RTC will be connected to the associated power management circuitry, allowing the system to remain in standby mode conserving power, until the RTC periodic event or alarm event wakes the system up. The control software is then able to read and record sensor data and manipulate control outputs, before returning the system to the low power standby mode (sleep mode).
In a typical stand-alone data acquisition application, sensor readings are taken at periodic intervals, allowing the system to return to the standby mode conserving power, during these periods of inactivity. For example, sensor readings may only be required once every 500 milliseconds. The RTC would, therefore, be programmed for an alarm wake-up event every 500 milliseconds (see low power mode). The system activity could be reduced to approximately 10 milliseconds in every 500 milliseconds, providing a substantial power reduction, which is very important for battery-operated systems.
G.3.4 Universal asynchronous receiver/transmitter (UART)
The start, stop, and parity bits used for checking data integrity in asynchronous transmission are physically generated by the universal asynchronous receiver/transmitter (UART), located between the microprocessor bus and the line driver, which interfaces to the actual communications link.
The main purpose of the UART is to look after all the routine housekeeping matters associated with interfacing between the parallel bus to the microprocessor and the serial communications link to the host computer.
When transmitting, the UART performs a number of functions. These are to:
•Set the correct baud rate for transmission
•Interface to the microprocessor data bus and accept characters one at a time
•Generate a start bit for each character
•Add the data bits in a serial stream
•Calculate and add the parity bit to the data stream
•Terminate the serial group with the required stop bit(s)
•Advise the microprocessor it is ready for the next character
The receiving circuitry of the UART performs the following functions. These are to:
•Set the correct baud rate for receipt of data
•Synchronize the incoming data with the start bit
•Read the data bits in a serial stream
•Read the parity bits and confirm the parity
•Read the stop bits
•Transfer the character as a parallel data onto the microprocessor data bus
•Interface the handshaking lines
•Observe and report any errors associated with the character frame received.
Typical errors that the UART can detect are:
•Receiver overruns - bytes received faster than they are read
•Parity errors - mismatch between parity bits and character frame
•Framing error - all bits in the frame are zero or a break condition is reported A break condition occurs when the transmitter that holds the data line is in a spaced (or positive voltage) state for a period of time longer, than that required for a complete character. This is a method of getting the receiving UART to react immediately and perform some other task.
G.3.5 Power supply
Due to the nature of their operation and the purposes for which they can be used, stand-alone devices have a variety of power sources:
•Low voltage AC (9-15 V AC)
•Low voltage regulated DC (11-17 V DC)
•9 V alkaline battery (6-10 V)
•6 V gel cell battery (5.6-8 V)
A simplified power supply schematic of a typical power supply circuit is shown in Figure G.8.
Figure G.8 Simplified power supply schematic
When both an internal non-rechargeable alkaline battery and an external AC or DC power supply are connected, the output of the regulator is increased to a voltage greater than the alkaline battery voltage (i.e. 10 V), so that power is drawn from the external supply and not from the internal battery. In this situation, the in-line diode connected to the alkaline + terminal prevents charging of the alkaline battery.
It is not recommended that both internal and external batteries be connected. If two batteries are required, it is better if the external battery is 12V and connected as external DC power.
Extreme care should be taken to ensure that external batteries are connected with the correct polarity otherwise, damage might occur. In addition, when an external DC supply is grounded it must be a negative (-) ground. AC supplies should never be grounded.
Battery Charging
Where an internal gel cell rechargeable battery is connected, an external AC or DC power supply can provide temperature compensated charging with voltage set by the output of the switch mode regulator and charging current limited by the 0.22 ohm charging resistor.
Sealed gel cell batteries may also be charged via a 12 V solar panel connected to the AC/DC power input terminals. The size of the solar panel required depends on the hours of full sunlight that can be expected. As a rule, one day in seven should be regarded as a charge day and the charge must be able to fully replenish the batteries on that day.
Battery Life
The maximum battery life that can be achieved depends on:
•How often the input channels are scanned
•The number of analog channels and how many are connected to sensors
•The number of digital channels and how many are driving outputs
•Sensor excitation power draw
•Complexity of any calculations A precise calculation of the battery life is extremely involved, however manufacturers can provide battery life charts, based on the number of channels and the time between each scan of all the channels.
G.3.6 Power management circuitry
All microprocessor systems need some supervisory functions that are analog rather than digital in nature. For a typical system, these functions include power reset, battery backup switching for RAM and real time clock, and the watch dog timer (WDT).
Reset Circuitry
The reset circuit ensures that the microprocessor is in the reset state in the absence of power. Embedded systems that may need to function in hostile environments require advanced reset circuitry that provides voltage threshold detection, independent of the rate of rise of the system power.
Battery Backup
The battery backup circuit ensures that the RAM and real time clock components receive a constant source of power. It also ensures that the RAM and real time clock are write-protected and in the low power mode, when the main power supply fails.
If the voltage from the main power supply falls below a preset level, then the battery backup circuit switches the RAM and real time clock power source to a supplementary battery supply. Additionally, the battery backup circuit ensures that the RAM and real time clock are write-protected, and in the low power sleep mode.
Low-Power Mode
Two power states, wake and sleep (standby), ensure that the minimum amount of power will be used when the unit is not required to perform any data acquisition function. For example, the device will wake up when:
•RTC periodic interrupt signals a scan of the input channels is due
•A memory card is inserted
•Characters are received at the communications port
•A key is pressed (where fitted) When an internal or external battery is being powered from an AC or DC supply then the low power sleep mode is not required to be entered.
Watch Dog Timer
The watch dog timer (WDT) circuit is intended to detect software-processing errors.
During normal operation the software is responsible for periodically resetting the WDT.
Failure to reset the WDT on a periodical basis indicates that the software is no longer executing the intended sequence, and accordingly the WDT initiates a system reset.
In essence, the WDT is a fail-safe mechanism that resets the system if for some reason it 'runs off the rails'. Although the WDT would seem a perfect fail safe mechanism for static or electrical noise induced problems, there is still the possibility of the software erroneously entering a loop, which continuously resets the WDT and hence never initiates a system reset.
G.3.7 Analog inputs and digital I/O
Analog Input Circuitry
Logger/controllers typically have multiple analog input channels. A special feature of these devices is that each channel can be configured for operation with a variety of sensors and signals. The simplified schematic of a typical input channel is shown in Figure G.9.
Figure G.9 Simplified schematic of analog input channels
The versatility, that allows each channel to be configured for a wide range of sensors, different excitation requirements and either differential or single-ended input terminations, is provided by the analog signal selector. The configuration of each channel is provided by software commands that are interpreted by the logger/controller to switch the analog signal selector to the required settings.
Sensor excitation is typically provided in the form of a low level constant current source (250 µA), for measuring resistance, a higher level constant current source for RTD and Wheatstone bridge measurements or a voltage source (usually unregulated) via an internal resistance, useful for powering some sensors.
Input termination resistors, typically of 1 M §Ù can be switched into the circuit to provide a return path for instrumentation amplifier bias currents. Where the termination resistors are not switched into the circuit, the input impedance seen by the sensor is of the order of 100 Meg-ohm.
Digital I/O Channels
Logger/controllers typically have multiple dual-purpose digital I/O channels that share the same terminations and act as both digital inputs and outputs. This is shown in Figure G.10.
Figure G.10 Schematic of digital I/O channel
Digital inputs have a high impedance input resistance and are buffered to protect the more sensitive CMOS digital interface circuitry from damage from current surges. A 30V zener diode provides input over-voltage protection by limiting the incoming voltage to below the transient voltage threshold of the input buffer.
The most commonly implemented form of digital output available on stand-alone loggers/controllers is the open collector output configuration capable of sinking 200 mA at 30 V. In this configuration, the zener also acts as a voltage limiter when the channel is used as an open collector output.
The schematic of a typical digital counter channel is shown in Figure G.11. Counter input channels are provided with a Schmitt trigger input buffer with threshold voltage set to 2 volts. This prevents spurious noise below the threshold value causing a count transition. The capacitor at the input to the Schmitt trigger input buffer provides filtering but limits the count rate to approximately 1 kHz (=1/RC). When it is removed, the count rate can be as high as 500 kHz.
Figure G.11 Schematic of digital counter channel
G.3.8 Expansion modules
Expansion modules provide increased localized channel capacity for a data acquisition system using stand-alone logger/controllers. Expansion connectors provide an extension of the internal data and control bus lines of the logger/controller. When connected, additional analog input channels, digital I/O channels, and counter channels, on the expansion module, are treated as if they were part of the logger/controller to which they are attached. This is shown in Figure G.12.
Figure G.12 Connection of expansion modules
G.4 Communications hardware interface
Communications interface standards define the electrical and mechanical details that allow communication equipment from different manufacturers to be connected together and to function efficiently. Two standards are commonly employed for communications between PCs and stand-alone or distributed logger/controllers:
•RS-232 standard
•RS-485 standard
G.4.1 RS-232 interface
As the RS-232 communications interface is standard on most IBM PCs and compatibles (i.e. COM1 and COM2 ports), stand-alone devices first used this interface for communication to the PC. The RS-232 interface is discussed in detail in Section 6, however some of the most basic setup parameters for stand-alone logger/controllers are discussed below.
Comms Port Parameters
Usually, the comms port parameters (i.e. start bits, data bits, stop bits) are fixed. The only user-setable parameter is the baud rate, which is typically set by dip switches on the device. Commonly used baud rates are 300, 1200, 2400, 4800, 9600 and 19200. The optimum baud rate setting is a compromise between the speed necessary to transmit the necessary amount of data over the communications interface, and the speed required so that data can be transferred without error over the distance that the host PC is located from the local stand-alone logger/controller.
Communications Port Connections
Stand-alone loggers/controllers are typically equipped with a DB-9 connector. The pin allocations commonly used with the DB-25 and DB-9 connectors for the RS-232C interface are not quite the same and often provide a trap to the beginner.
Figure G.13 shows the standard connection between both the DB-25 and DB-9 connector of the host PC and the DB-9 connector of a stand-alone logger controller.
Figure G.13 Communication cable connections to IBM host PC
Great care should be taken when connecting stand-alone devices to the host PC. While the standard pin configuration is likely to be adhered to by manufacturers at the PC's communications interface, it is possible (and often likely) that the data receive and transmit lines on remote stand-alone systems are on different pins of the DB-9 connector.
It is therefore wise, to consult the manufacturers' data sheets.
Data handshaking is not usually employed on stand-alone logger/controllers as their use often leads to communication problems. Instead, the handshaking lines are connected at the host PC, as required by the communications software, and left unconnected at the logger/controller interface.
G.4.2 RS-485 standard
With a growing need for a distributed logger/controller network, RS-485 interfaces have been added to the hardware. The RS-485 interface typically operates as a balanced two wire, half duplex and un-terminated network (see Section 6). However, the protocols used for communications on the network are often proprietary, with different manufacturers using undisclosed protocols, and error detection/correction methods, between devices. This does not alter the fact that communications to devices on the RS-485 network still occur via a single logger/controller, known as the local device, which communicates to the PC via the RS-232 interface.
An RS-485 repeater is used where more than 32 stand-alone devices are required on one network. A further 32 devices may be connected for each repeater used.
G.4.3 Communication bottlenecks and system performance
When logger/controllers are constantly logging data to memory, data gathered can be sent to the host PC via the communications interface at any convenient time before the memory becomes full. This allows great flexibility in obtaining the data from a stand-alone device or a network of devices. However, when operating in real time, that is, data is continuously returned to the host PC from a single stand-alone logger/controller or a network of logger/controllers, an important consideration is 'can the volume of data obtained, be transmitted over the serial communications link?' This depends on a number of factors:
•Baud rate
•The number of channels being scanned
•How often the channels are scanned
•Whether the device is stand-alone or part of a distributed network stand-alone logger/controller
Consider first, a stand-alone logger/controller connected to the host PC via the RS-232 interface operating at 9600 baud. As we have seen previously, data sent over the communications interface is sent in a 10-bit frame consisting of 1 start bit, 8 data bits and 1 stop bit. The time to transmit each byte of data at 9600 baud is 1.042 ms (t = 10 bits/ 9600).
Therefore, to transmit the maximum amount of data at the required baud rate, the maximum time between each data byte, being ready to be sent, is 1.042 ms.
Consider a logger/controller that is scanning 10 channels. If, for each channel, seven bytes of data are sent (on average), plus there are another ten bytes for each scan of the input channels, then the total number of bytes to be sent for each channel scan is 80 bytes.
The maximum time each channel scan could take is 83.36 ms (80 bytes × 1.042 ms).
Therefore, all channels could be scanned at the maximum rate of approximately 12 Hz (1/83.36 ms).
This calculation assumes that there are no hardware factors, such as multiplexer settling time, input amplifier-settling time etc, which limit this rate even further. Irrespective of the performance limitations imposed by the stand-alone communications interface, logger/controllers are not designed for high-speed data measurement.
Distributed logger / controller network
When operating as part of a distributed network, the considerations that determine the performance of the system are different. Despite RS-485 being an extremely reliable interface, even at high speed, the potential speed at which the network can operate is limited by a number of factors:
•Each device in the system has a unique address and must be polled by the host computer for information.
•Only one device can be polled at any time.
•As the RS-485 network is half-duplex, the host PC must wait for a response to each request for data before polling the next device.
•There is an inherent delay, or turnaround time, in responding to a host request irrespective of whether one byte or one hundred bytes of data are returned in the response. This is because the device must interpret, process, then act on the command received before returning its response.
•Where the RS-485 network is operating much faster than the RS-232 interface (i.e. more than twice as fast) the potential speed at which the data can be sent to the host PC is limited by the baud rate of the RS-232 interface. Where this is not the case, the baud rate of the RS-485 network is the limiting factor.
It has been shown in the example for a stand-alone device, that a device scanning 10 input channels and returning 80 bytes of data to the host PC for each scan, would take 83.36 ms to transmit the data. If the time required to transmit a ten-byte poll command is 10.42 ms, and assuming a turnaround time of 1 sec, the total time to obtain the data from a single device is 1093.78 ms. The time taken for 10 devices operating in the same manner would be approximately 11 sec. Clearly, the system would not be able to operate in real time unless each device scanned its input channels and returned data to the host once every 11 sec.
Where the channels of one or more of the devices must be scanned at a faster rate, the data should be logged to memory and returned at a more convenient time. G.4.4 Using Ethernet to connect data loggers
Data loggers have traditionally used RS-485 as a type of networking system. RS-485 works very well for multi-dropping up to 32 data loggers. As requirements have expanded in the plant environment, we have seen a need to connect data loggers to expanding networks of systems. This has seen the rise of data loggers being connected via existing Ethernet networks. The advantages are obvious. One of the main problems with connecting data loggers on an RS-495 network is the limited range of access to the system. By having access to the data loggers over the Ethernet, the user can view and even change data anywhere the network is connected. This brings rise to the use of data loggers using the Internet. Intra- and inter-networking of data loggers also raises security issues. How safe is the data? Will someone that does not have authorization be able to access the hardware? These problems and their solutions will be the subject of much discussion when it comes to connecting Ethernet to data loggers.
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 is 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 is 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, by Data Electronics Australia Pty Ltd, is shown in Appendix H.
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. For example, 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 is 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, for example:
•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 Appendix 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 is often possible to enable/disable the trigger event using the state of one or more other digital inputs. This would be very useful, for example, 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 cannot 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 is 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 is 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 do not 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 do not 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 do not 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 do not 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 do not 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: