Author Archive: admin

Diesel Particulate Filter Testing on Vehicles with GPS Logging

Delphin TopMessage Data Acquisition and Control System

CHESTERLAND OH—August 15, 2011

CAS DataLoggers recently provided the data acquisition solution for Twin-Tec, a German developer and manufacturer of environmentally friendly products and technologies for reducing exhaust emissions, including a wide range of diesel particulate filters and catalytic converters for automotive applications. TwinTec was heavily involved in producing products for retrofitting and upgrading already approved vehicles as well as corresponding replacement products. In Germany, the government encouraged all owners through financial incentives to retrofit their filters since many old vehicles had no diesel particulate filtration. Many German automobile owners became interested in adding a particulate filter to their exhaust system in order to protect the environment and benefit from the reduced vehicle emission taxes. Twin-Tec was therefore developing many different retrofit filters for many different brands. Each filter required testing on the road under typical driving conditions to determine filter efficiency—however, virtually every new filter also required a new design due to the wide variety of exhaust systems and their varying temperature and pressure operating levels. During test drives, the filter temperature, pressure, engine speed, idle times, vehicle position and speed all needed to be measured accurately and reliably to ensure that the filter met all required standards. In order to record all the test data, Twin-Tec needed a sophisticated data acquisition device capable of extreme accuracy and fast signal processing and that could capture the wide range of data required in the tests.

Twin-Tec installed a Delphin TopMessage Data Acquisition and Control System with ADVT and DIOT modules in combination with a GPS sensor to record measurement data from the filters in tandem with vehicle position information. The whole system was installed in a small weatherproof enclosure and its sensors were interfaced to the enclosure through special connectors. During the test drive, all test data was recorded on the TopMessage’s internal memory. Engine RPM was recorded through a separate speed meter (DAB 500 from AVL) which was providing TTL pulse output. The pulses were then recorded by the counter and inputs of the DIOT module. The live data was visualized through a mimic interface using ProfiSignal Basic software.

The TopMessage featured 2 slots for analog, digital input, or output cards, as well as an Ethernet interface and CANbus for expansion modules. The analog inputs could be attached to RTD sensors, thermocouples, volt or 20 mA signals, enabling any physical value to be acquired. The measurement data was saved as scaled and linearized to the device, and scaling was pre-configured for all current thermocouple and RTD sensor types. The high measurement accuracy, up to a 24-bit resolution, enabled high-precision measurements without need for any signal amplification. Additionally, the device processed any signal quickly and reliably from just a few thermocouples right up to thousands of measurement points spread over several plant areas. The data acquisition device also featured screw terminal connections and up to 1 GB of local memory. The TopMessage also offered powerful alarm and programming capabilities to allow the device to process measurements and initiate actions on its own. The TopMessage could be used for local data acquisition and logging when connected to a PC; for remote unattended data collection connected to the internet; or as a stand-alone device.

In order to record the vehicle speed and direction, a special NEMA driver for a GPS sensor was developed. This driver was interfaced to the TopMessage through serial RS232 port. A separate COM channel was created for the GPS information like speed, direction, altitude, etc, and all the data was stored directly on the 1 GB TopMessage data logger memory. After the test drive was finished, all the data was analysed with the ProfiSignal software included free with the TopMessage. This user-friendly software provided for the acquisition of measurement, control and test data as well as functions for archiving, analysis, operation and monitoring. It was also possible to convert the GPS data into a KLM file which could be loaded by Google Earth to plot various measurement channels like vehicle speed, filter temperature or pressure of position or engine speed.

Twin-Tec benefitted immediately from installing the Delphin TopMessage data acquisition system in its diesel particulate filter testing program. Filter temperature, pressure, engine speed, idle times, vehicle position and speed were all measured in the test drives using one powerful device. Twin-Tec subsequently used 5 TopMessage systems to more smoothly run the testing. The universal analog inputs made it easy to connect all the temperature and pressure sensors, and engineers found it easy to configure the TopMessage’s ProfiSignal software to show live reading during the test drives. The data acquisition system’s 1 GB internal memory provided storage capacity for several thousand test drive kilometres, and the interface of the GPS sensor also gave Twin-Tec valuable additional information about vehicle speed in combination with engine RPM and particle emission. Additionally, the small and compact size of the TopMessage (200x73x118 mm) made it an ideal fit for installation in the small enclosure. Additionally, internal calculation and logic channels were used to trigger data logging when test conditions were reached.

In the event that Twin-Tec needed to expand the number of channels used, Delphin slave module expansion chassis were also available to expand the TopMessage to a maximum of 1000 hardware/software channels. Up to ten slave devices, each with identical housings and each equipped with two I/O modules, could be attached to a master, with any combination of I/O modules being possible. Check out the TopMessage’s product page here.

For further information on the Delphin TopMessage, additional data acquisition and control systems, or to find the ideal solution for your application-specific needs, contact a CAS Data Logger Applications Analyst at (800) 956-4437 or visit the website at

Contact Information:
CAS DataLoggers, Inc.
12628 Chillicothe Road
Chesterland, Ohio 44026
(440) 729-2570
(800) 956-4437

What Does “Real-Time” Mean?

Data Acquisition Devices Operating in Real-Time

CHESTERLAND OH—August 10, 2011

Many vendors claim to have “real-time” systems, but without defining what they mean by the phrase and what time frame they have in mind, it’s impossible to compare and contrast real-time systems. For example, many people have seen automobiles that claim to have “real-time four-wheel drive.” Does this mean that other vehicles have non-real-time operation? What exactly does “real-time” mean? This confusion can be clarified by defining the phrase and describing what time scales are appropriate for different applications. Specific examples of system operation based on different response times further help users understand what is possible and impossible for their real-time applications.

In general, there are three factors that define exactly what real-time operation encompasses. In addition, it’s essential to identify a time frame for real-time operation. Any real-time system must have stable and repeatable program execution–the program must produce the same result for any given set of inputs and it must do so within the same time frame. Therefore a system that produces the same output, but exhibits variability in the time it takes from input to output, cannot be considered real-time. Another key to any real-time system is the time it takes from an event or change of an input occurring to the instant the output updates. It’s critical that a real-time system provides a guaranteed time for which the output will respond to a change in the input. Finally, the execution of the program must be predictable. It’s not acceptable for the output of the program to be dependent on factors that are unknown, or at minimum, uncontrollable. Any factors that determine the output state for a given input state must be known and controllable. However, these three factors alone are not adequate to describe or compare real-time systems since they do not establish a time frame for operation.

Every process or application has its own real-time context–the time needed for the system to respond to a change or request. This time frame can vary dramatically, depending on the process. However, there are a few categories of typical time scales for real-time systems. At the low end of the scale, there are systems where a response time measured in minutes is acceptable. A restaurant could easily be considered a real-time operation – they take orders, cook the food and (hopefully!) deliver it in a guaranteed and predictable manner. In an average sit-down restaurant, the food might take 15 minutes to a half-hour. On the other hand, at McDonald’s, a wait of three minutes might be at the high end of customer expectations.

Moving on to faster systems, there are many examples where a response within seconds is necessary. NASCAR race fans marvel at the real-time response of pit crews when a car comes in for fuel or a tire change. In this case, getting in and out in tens of seconds is often expected. Additionally, any processes where temperature control is needed can manage response times measured in seconds. In conditions with a large thermal mass, temperature changes occur very slowly and a controller needs to respond to changes within a few seconds to keep the temperature at a desired set point.

Even faster systems require response times that are measured in milliseconds. These include devices like PLCs that are controlling production lines, test stands that apply a stimulus and measure the response of a system or device being tested, or systems that require feedback control loops with less than 1 kHz of bandwidth. The latter could be a simple PI or PID control loop for temperature, pressure, flow, voltage, current or position.

On the farthest end of the real-time spectrum, some of the fastest systems demand response times measured in microseconds. Examples include high-speed test stands, fast digital controllers with bandwidths up to 500 kHz, and positioning systems that employ electron beams or lasers–each need extremely fast controllers. These capabilities are often beyond that of a general purpose system and require dedicated hardware designed expressly for the target application.

Considering the preceding requirements for real-time systems and the response time requirements, it is apparent that, for many applications, Windows is not a suitable environment. Essentially, Windows is not 100% stable, as the performance of any application running under Windows is highly dependent on any other activities running on the same CPU. In a best-case scenario, users may simply see delays in the execution of one process under Windows due to another process executing at a higher priority. In the worst case, a badly-behaving process can crash the computer, causing all other processes to stop. This outcome is not acceptable if these processes are in charge of critical control or positioning functions.

Windows is not inherently designed to be a real-time platform. It uses a priority-based time-slicing approach to allocate the resources of the CPU among the multiple processes running at any one time. Typically, kernel processes that interface directly with hardware (including disk drives, the keyboard, mouse or video display) run at the highest priority. And, because of the time slicing approach, users aren’t guaranteed of when a process will be serviced. Therefore, whenever users have a control application running at a lower priority and somebody moves the mouse around, the real-time application will be delayed.

Computer devices that rely on real-time, such as sound cards and disk writers, are able to operate using local processors that buffer and manage data to enable real-time operation. Any device that operates under Windows and needs real-time has its own local intelligence. Modern Windows-based systems such as disk drive controllers, sound cards, and fieldbus cards all have a local processor to achieve the tight timing required for normal operation. While it’s possible to use Windows with a real-time kernel, such as the real-time extensions to Windows, it’s much better to use a device with local intelligence for real-time that communicates with Windows for display and data storage. See Table 1 for an example of system response on real-time.

Table 1 – A system with a 25 µs response time

Control Frequency Process Cycle Time Response Time
(% of cycle time)
Process A 1 kHz 1000 µs 2.5%
Process B 10 kHz 100 µs 25%
Process C 40 kHz 25 µs 100%
Process D 100 kHz 10 µs 250%

In this case, processes C and D cannot run since they consume 100% or more of the CPU resources.

Table 2 compares the system performance when the response time is even faster at 1 µs.

Table 2—A system with a 1 µs response time

Control Frequency Process Cycle Time Response Time
(% of cycle time)
Process A 1 kHz 1000 µs 0.03%
Process B 10 kHz 100 µs 0.3%
Process C 40 kHz 25 µs 1.2%
Process D 100 kHz 10 µs 3%

For older 486 DOS-based systems, average response times range from 10 to 40 µs. These systems typically have much lower overhead than newer Windows-based systems. Windows systems with real-time kernel extensions are somewhat slower, with response times of 25 to 200 µs. In addition to these, National Instruments markets several different real-time products. In a detailed publication, Benchmarking LabVIEW Real-Time FieldPoint Systems, they indicate that the typical input to output time is 5 to 50 ms, depending on the number of channels and system configuration. Meanwhile, Linux-based real-time systems can achieve response times on the order of 5 to 20 µs; even faster are RISC/DSP systems which can process requests in 1 to 10 µs; and still faster are the ADwin-Pro DSP-based systems which have demonstrated response times as fast as 300 ns.

The hardware and software architecture of the ADwin-Pro system has been optimized for real-time operation. For example, online calculation for each measured value for applications like PID loops or digital filters are processed immediately after measurements are made, resulting in very fast updating of output values. The architecture allows overlapping A/D or D/A conversions in parallel with calculations for the highest throughput. For calculations, maximum CPU performance is achieved through the use of a 32-bit floating-point DSP.

In summary, ‘real-time’ control means different things to different people and companies. Without having a defined time frame, it’s impossible to contrast different systems that claim to have real-time response. For the best performance in a Windows environment, however, it’s essential to have a local processor dedicated to maintaining the real-time control functions. At the high end of the real-time spectrum, the ADwin-Pro system has one of the fastest response times available for applications that demand precise and repeatable control. Check out the Adwin-Pro’s product page here.

For further information on the Delphin ADwin-Pro DSP system, other data acquisition and control solutions, and data logging and remote monitoring applications, or to find the ideal solution for your application-specific needs, contact a CAS Data Logger Applications Analyst at (800) 956-4437 or visit the website at

Contact Information:
CAS DataLoggers, Inc.
12628 Chillicothe Road
Chesterland, Ohio 44026
(440) 729-2570
(800) 956-4437

Data Logging With Remote UMTS Access In Natural Gas Dehydration Plants

Delphin Data Acquisition Systems Provide Remote Monitoring Solution

CHESTERLAND OH—August 8, 2011

CAS DataLoggers recently provided the data acquisition solution for a state-owned oil and gas company located in Eastern Europe involved in developing natural gas in distant gas fields. The gas came out of a wellhead for processing in either of two dehydration plants. These plants extract water from the gas before sending it through a compressor station and then pumping it through the pipeline system. However, since the two dehydration plants were based in a remote location, the company needed a standalone data acquisition and logging system to record production and process data from the plant and also to gain remote access to all recorded data. This system would have to be able to perform high-precision measurements and also feature sophisticated alarm and programming capabilities enabling the device to process measurements and initiate actions on its own.

Plant management decided to install a Delphin TopMessage Data Acquisition System in each of the two dehydration plants. Additionally, one ADVT module with 15 analog inputs and one IOIT module with 24 digital inputs for status monitoring were also installed in each plant. The TopMessages were then interfaced via Ethernet LAN to a MoRoS UMTS router to provide remote access functions. In case of an accident in hazardous areas, each complete system was then fitted inside an explosion-proof box outfitted with EX barriers. Within its protective enclosure, each Delphin TopMessage was then interfaced to 3 tank level transmitters using a 4-20mA analog output signal, and also to 3 gas volume conversion devices from VEGA through an RS-422 Modbus RTU interface (see Figure 1).
Figure 1: Functional Application Architecture

The TopMessage data acquisition device was capable of both Ethernet networking as well as direct PC connection (P2P). Its analog inputs could be attached to RTD sensors, thermocouples, volt or 20 mA signals, enabling any physical value to be acquired as needed. The measurement data was saved as scaled and linearized to the device, and scaling was pre-configured for all current thermocouple and RTD sensor types. The maximum 24-bit resolution measurement accuracy enabled high-precision measurements without the need for any signal amplification. Each TopMessage device could be equipped with up to 30 analog inputs or 48 digital inputs, with any possible combination of I/O modules.

Ideal for many different data logging, data acquisition and testing applications, Delphin TopMessage systems perform tasks in the fields of process technology, test engineering, and research and development, offering quick and reliable signal processing from a few thermocouples up to thousands of measurement points spread out over the plant. 1 GB of local memory stored all readings. Housed in its sturdy explosion-proof enclosure, the TopMessage system featured 2 slots for analog or digital input or output cards, as well as an Ethernet interface and CANbus for expansion modules. Screw terminal connections provide secure connections and reliable operation. Additionally, the TopMessage’s small size of 200 x 118 x 90mm made for a quick installation.

The dehydration plant operator based in the save area had a local monitoring PC running Delphin’s free ProfiSignal Klicks software. ProfiSignal Klicks offered a user-friendly development system for programming the data recording and reporting functions with no specialized IT knowledge required. The software also contained functions for automating processes and generating user-defined reports. Operators used the software’s mimic panel to monitor plant performance and also set up input screens for test parameters, test sequences and reports through the Klicks automation programming language. This provided engineers with a flexible software tool for generating their own complete applications. Utilizing the UMTS router, the control room operator at the head office had remote access at all times to the data from the TopMessage device and could see live data and downloaded data from the system memory. Additionally, the data download could be automated by using the scheduler function of the DataService Configurator. The dehydration plant itself was covered by an EDGE G2 mobile communication network.

The oil and gas company gained several benefits from installing the Delphin TopMessage data acquisition system in each of its two dehydration plants. The TopMessage data acquisition device, equipped with the UMTS router, served as an effective solution for this application covering all requirements. Additionally, the TopMessage’s compact size made the system easy to install in the explosion-proof box to guarantee its safety. Additionally, remote access was easily configured with the UMTS router, which also provided networking functions for local PCs and printers. The TopMessage system itself supported many serial interface standards so that VEGA Scan EK220 volume conversion units could be interfaced. The popular ProfiSignal Klicks software was included free to develop an operator user interface, including mimics, and also added reporting functions.

As an option for larger projects, up to 10 Delphin TopMessage Slave Modules could be used as expansion chassis to increase the master unit’s capability up to 1000 hardware/software channels, with all data transfer between master and slave taking place via a CANbus. The slave modules are connected via CANbus to the master with a maximum bus length of 100 meters. Check out the Delphin TopMessage’s product page here.

For further information on the Delphin TopMessage Data Acquisition System, other devices in the Delphin product line, details on any other data acquisition and control system, or to find the ideal solution for your application-specific needs, contact a CAS Data Logger Applications Analyst at (800) 956-4437 or visit the website at

Contact Information:
CAS DataLoggers, Inc.
12628 Chillicothe Road
Chesterland, Ohio 44026
(440) 729-2570
(800) 956-4437

Implementation Of PSI-5 Serial Sensor Interface On ADwin Real-Time Data Acquisition Systems

CHESTERLAND OH—August 3, 2011

The PSI-5 communications interface is a 2 wire serial communications interface which is used to interface sensors to Electronic Control Units (ECU) in applications such as accelerometers for airbag systems. Promoted by major auto suppliers such as Bosch and Continental, the PSI-5 interface has been in use for more than 10 years and has shown itself to be both robust and reliable. Figure 1 shows the PSI-5 telegram definition.

Figure 1: PSI-5 Telegram Definition

To minimize the number of wires going to the sensor, the physical layer of PSI-5 is implemented as a 2 wire interface that carries both the signal and power. The sensor data is sent as a series of current pulses which ride on top of the normal sensor supply current. This allows the interface to communicate at up to 250K bits/second and also provides EMC compatibility for conducted and radiated emissions. The standard data packet consists of 13 bits: 10 bits of data, 2 start bits and a parity bit (see figure 1). The data is encoded using a Manchester coding scheme where a 0 corresponds to a rising edge in the middle of the bit transition time and a 1 by a falling edge in the middle of the bit. Typically a dedicated receiver IC is used to read current signal and extract the data.

A pressure sensor manufacturer was looking for a system to simultaneously test multiple sensors using this interface. Rather than try to build a custom solution around the dedicated interface chips, they were looking for an off-the-shelf data acquisition solution that could be programmed to read the raw signal and extract the data. For this project, an ADwin-Light-16 Real-Time Data Acquisition System was selected. A simple comparator circuit was used to convert the current signal to a digital waveform that could be read with standard TTL logic. The ADwin system featured 6 high speed digital inputs allowing up to 6 sensors to be read at the same time. For each digital input, a simple state machine was implemented in software to monitor the incoming data, look for the start bits, read and decode the data.

Figure 2 shows the state machine to read one input. The minimum bit time corresponding to a 0 was 40 useconds; therefore, to allow for small variations in the timing, the state machine was setup to read the inputs at 8 times the expected clock rate, or 5 useconds. A watchdog timer was also provided to allow the state machine to reset in the case of a partial or corrupted transmission. Figure 3 lists the ADBasic code for the state machine to read one sensor. For testing, a second ADwin system was configured to generate various data packets to verify that they could be read correctly.

For this project, it was quite straightforward to create a simple state machine using the CASE structure available in the ADBasic programming environment. The deterministic, real-time capability of the ADwin system allowed the data to be read reliably without the need for specialized receiver IC’s, and the flexibility of the software enabled the different scenarios and failures mechanisms to be tested quickly and easily.

Figure 2: State Machine to Read PSI-5 Data

Figure 3: ADBasic Code For The State Machine to Read One Sensor

newbit = digin(0)AND 01B
inc counter
CASE 1 ‘ wait for high to indicate start of transmission
if (newbit = 01b) then
startcnt = startcnt+1
IF (startcnt > 10) then ‘ need to get >50 usec high to start
state = 2
CASE 2 ‘ waiting for low start bit
if (newbit = 00b) then ‘first low is start of word
state = 3
numbits = 0
bit_val = 01b
numUnusedbits = 0
counter = 1
fall_time = counter
CASE 3 ‘waiting for low to high transition to mark bit
if (newbit = 01b) then
rise_time = counter
if ((rise_time – fall_time) > 8 ) then ‘ > 40 usec = 1
data_1[i]= data_1[i] + 1 * bit_val
data_1[i]= data_1[i] + 0 * bit_val ‘ < 40 usec = 0 endif numbits = numbits + 1 bit_val = bit_val * 2 if (numbits > 12) then
state = 5
par_2 = Data_1[i]
fpar_1 = Data_1[i]*2.0
state = 4
CASE 4 ‘waiting for high to low transition to start next bit
if (newbit = 00b) then
fall_time = counter
state = 3
case 5 ‘ 3 unused bits
if (newbit = 00b) then ‘ start of unused bit
state = 6
case 6
if (newbit = 01b) then ‘ end of unused bit
numUnusedBits = numUnusedBits+1
if (numUnusedbits > 1) then
state = 7
state = 5
case 7
if (newbit = 00b) then ‘ start of error flag
fall_time = counter
state = 8
case 8 ‘ read error flag
if (newbit = 01b) then
rise_time = counter
if ((rise_time – fall_time) > 8 ) then ‘>60 usec = 1
errorflag = 1
errorflag = 0
state = 9
par_3 = errorflag
case 9
IF (counter > 1000) Then
state = 1
counter = 0
IF (counter > 1000) Then
state = 1
counter = 0
par_1 = counter

For further information on ADwin real-time data acquisition and control systems, other data acquisition system product lines, or to find the ideal solution for your application-specific needs, contact a CAS Data Logger Applications Analyst at (800) 956-4437 or visit the website at

Contact Information:
CAS DataLoggers, Inc.
12628 Chillicothe Road
Chesterland, Ohio 44026
(440) 729-2570
(800) 956-4437

ProfiMessage Is Delphin’s Latest Cutting-Edge Data Acquisition System

CAS DataLoggers has partnered with Delphin Technology to offer the new Delphin ProfiMessage system, the latest high-speed, precision solution for data acquisition, industrial process monitoring, and automation of machinery and test stands. ProfiMessage is a state-of-the-art modular measurement system that utilizes master and slave devices along with a range of different I/O modules to easily adapt to any task. Learn more…

Testing High-Performance Engines on a Military Patrol Boat

CAS DataLoggers recently provided a data logging solution for Puckett Power Systems, the heavy equipment and engine dealer for Caterpillar (CAT) for central and southern Mississippi. The company was running a very strenuous test program to help CAT and Navistar validate a new engine design by measuring the performance of engines installed in a high-performance military patrol boat. CAT and Navistar specified the test procedures to be carried out. Learn More…

Rotary Flex Testing on a Pipefitting Test Bench

Data acquisition systems have helped to increase quality control and cut costs in a wide range of manufacturing fields. One particular customer to discover this was a leading hydraulic tube and fitting manufacturer in India. Their company developed many different pipe-fitting systems and exported a full 90% of their products worldwide. With the use of a data acquisition system and its software monitoring a test bench, this company was able to optimize its rotary flex test procedures and guarantee a better product. Continue Reading …

Dashboards Efficiently Monitor Utility Usage in a School Building

The requirement to closely monitor utility usage in a school building measured by floor, as well as present this data logged in an easy-to-understand dashboard for each wing was submitted to CAS DataLogger Solution Analysts. Electrical sub-panels are located on each floor but they are separated from their floors’ main utility rooms. These components need to be integrated into the dashboards as well to view the entire usage. Continue reading…

DELPHIN UPGRADES PROFISIGNAL KLICKS ProfiSignal Basic Software Extended for Data Logging Processes

Delphin Technologies announces ProfiSignal Klicks for Delphin TopMessage, LogMessage and ExpertKey data logging and data acquisition systems. ProfiSignal Klicks extends the ProfiSignal Basic software with functions for automating processes and for generating user-defined reports. Follow this link to learn more about the Delphin ProfiSignal Klicks.

MULTI-FUNCTION I/O CARD with A/D, D/A, Counters, SSI and EtherCAT

Multi I/O module for ADwin-Pro-II systems

Multi I/O card for ADwin-Pro-II Systems

The multi I/O modules for ADwin-Pro II are autonomous multi-function cards for any type of signals: The module combines the fast reacting local TiCo processor with analog and digital I/Os. With this capability, the intelligent slide-in card can react independently to measurement values and events as well as offload the main processor. For examples such as performing as fast closed-loop controller, digital filter for analog signals, function generator or intelligent limit monitor.

There are even more possibilities using the extended version, with counter inputs, SSI decoder or EtherCAT interface.


  • TiCo Processor
  • 128 kB Internal Memory
  • 4 MB External SRAM
  • 37-pole Sub-D Plug

Analog inputs

  • 8 Differential or 16 Single-Ended Channels
  • ADC Resolution 18 Bit; Conversion Time 2 µs
  • Multiplexer Settling Time 2 µs

Analog outputs

  • 4 Channels
  • DAC Resolution 16 Bit
  • Settling Time 9 µs

Digital channels

  • 8 Channels with TTL Logic
  • Configurable as Inputs or Outputs in Groups of 4

Optional MIO-4-ET1 Expansion (Order Time Option)

  • 4 Transistor Outputs
  • 4 Optically Isolated Inputs
  • (1) Counter Block with (2) 32 Bit Counters (a forward/backward counter and a counter for PWM analysis)
  • 1 SSI Decoder
  • 1 EtherCAT Interface (slave)

The ADwin multi-function I/O card and provides a capable method of handling demanding real-time processing or control applications. It increases the power of ADwin systems by localizing processing on the input card and freeing up the main processor for higher level activities.

For complete solutions for complex real-time processing and control applications, contact CAS DataLogger’s Solution Analysts for application specific designs. Pricing based on individual application needs and required results.