Tag Archive: adwin

New LINBus Communication Card for ADwin-Pro-II Systems

For ADwin Real-Time Data Acquisition System Solutions

CHESTERLAND OH—August 30, 2011

The new Pro-II-LIN-2 card now available for ADwin-Pro-II systems provides convenient LIN communications capabilities that can be used to test different types of sensors, switches and other mechatronic devices in distributed automotive applications. The card, which is fully compatible with the LIN 2.1 interface standard, has 2 single wire LIN serial communications ports that can be individually configured as a master or slave with transfer rates up to 19,200 kBit/sec and standard or enhanced checksum verification. Each port features 64 message boxes, each with a programmable identifier header, that can be used to send or receive data packets up to 8 bytes. Depending on the card configuration, master or slave, the appropriate bus termination is automatically selected to ensure reliable communications. All 4 transfer operating modes are available, including master send, master receive, slave receive and slave send. A library of functions is available to initialize, configure, read data and write messages. Additionally, the card provides additional timing diagnostic information including the total message transfer time and the response time from request to the receipt of data.

The Pro-II-LIN-2 card is just one of over 80 different plug-in cards available for the ADwin-Pro-II real-time data acquisition and control system. These customizable cards provide a comprehensive set of capabilities for high speed data acquisition and control including analog inputs, analog outputs, digital inputs, digital outputs, counters, signal conditioning, and CANbus, Flexray, serial and EtherCAT interfaces. The architecture of the ADwin data acquisition system is optimized to provide precise, deterministic operation boasting usecond response times. A high performance local DSP controller manages the data acquisition hardware and works in cooperation with a PC via a shared memory interface that provides transparent access to data and control variables. In this way the system is partitioned to share the load such that the DSP in the ADwin system controls all time-critical tasks, while the PC is free to handle the user interface, data presentation and data storage.

The ADwin-Pro-II system is freely programmable, using either the ADBasic real-time IDE or alternatively the graphical model-based Simulink® software package from Mathworks®. All ADwin systems are compatible with computers running under Windows, Linux, Mac, or Unix. Driver packages are available for virtually all common PC development tools including VB, VB.NET, C/C++/C#, Java, Phyton, LabVIEW, WinCC, Matlab, Simulink, VEE, Dasylab, and many more. Check out the ADwin-Pro-II data acquisition system product page here.

For further information on the ADwin-Pro-II data acquisition system, other ADwin DAQ solutions, 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 www.DataLoggerInc.com.

Contact Information:
CAS DataLoggers, Inc.
12628 Chillicothe Road
Chesterland, Ohio 44026
(440) 729-2570
(800) 956-4437
sales@dataloggerinc.com
http://www.dataloggerinc.com

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 www.DataLoggerInc.com.

Contact Information:
CAS DataLoggers, Inc.
12628 Chillicothe Road
Chesterland, Ohio 44026
(440) 729-2570
(800) 956-4437
sales@dataloggerinc.com
http://www.dataloggerinc.com

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

EVENT:
newbit = digin(0)AND 01B
inc counter
SelectCase(State)
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
startcnt=0
endif
endif
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
i=i+1
data_1[i]=0
endif
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
else
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
else
state = 4
endif
endif
CASE 4 ‘waiting for high to low transition to start next bit
if (newbit = 00b) then
fall_time = counter
state = 3
endif
case 5 ‘ 3 unused bits
if (newbit = 00b) then ‘ start of unused bit
state = 6
endif
case 6
if (newbit = 01b) then ‘ end of unused bit
numUnusedBits = numUnusedBits+1
if (numUnusedbits > 1) then
state = 7
ELSE
state = 5
endif
endif
case 7
if (newbit = 00b) then ‘ start of error flag
fall_time = counter
state = 8
endif
case 8 ‘ read error flag
if (newbit = 01b) then
rise_time = counter
if ((rise_time – fall_time) > 8 ) then ‘>60 usec = 1
errorflag = 1
else
errorflag = 0
endif
state = 9
par_3 = errorflag
endif
case 9
IF (counter > 1000) Then
state = 1
counter = 0
endif
ENDSELECT
‘watchdog
IF (counter > 1000) Then
state = 1
counter = 0
endif
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 www.DataLoggerInc.com.

Contact Information:
CAS DataLoggers, Inc.
12628 Chillicothe Road
Chesterland, Ohio 44026
(440) 729-2570
(800) 956-4437
sales@dataloggerinc.com
http://www.dataloggerinc.com