Your Ad Here

Thursday, November 27, 2008

Control Information Services

Posted by Imdad at 11:59 AM 0 comments  

Control Systems - Journals

Posted by Imdad at 11:58 AM 0 comments  

Control system - Professional Socities

Professional Societies

Posted by Imdad at 11:57 AM 0 comments  

Control system Library - 15

United States of America

Venezuela

Posted by Imdad at 11:56 AM 0 comments  

Control system Library - 14

United Kingdom

Posted by Imdad at 11:55 AM 0 comments  

Control system Library - 13

Switzerland

Taiwan

Thailand

Turkey

Posted by Imdad at 11:54 AM 0 comments  

Control system Library - 12

Spain

Sweden

Posted by Imdad at 11:53 AM 0 comments  

Control system Library - 11

Singapore

Slovakia

Slovenia

South Africa

Posted by Imdad at 11:52 AM 0 comments  

Control system Library - 10

Poland

Portugal

Romania

Russia

Russian Academy of Science, St. Petersburg

Posted by Imdad at 11:51 AM 0 comments  

Control system Library - 9

Netherlands

Norway

Norwegian University of Science and Technology (NTNU), Trondheim

Posted by Imdad at 11:50 AM 0 comments  

Control system Library - 8

Japan

Korea

Malta

Mexico

Posted by Imdad at 11:49 AM 0 comments  

Control system Library - 7

Ireland

Italy

Posted by Imdad at 11:48 AM 0 comments  

Control system Library - 7

Greece

Hungary

India

Indonesia

Posted by Imdad at 11:46 AM 0 comments  

Control system Library - 7

Germany

Posted by Imdad at 11:45 AM 0 comments  

Control system Library - 6

France

Posted by Imdad at 11:42 AM 0 comments  

Control system Library - 5

Denmark

Finland

Posted by Imdad at 11:42 AM 0 comments  

Control system Library - 4

Chile

Colombia

Croatia

Czech Republic

Posted by Imdad at 11:41 AM 0 comments  

Control system Library - 3

Canada

Posted by Imdad at 11:40 AM 0 comments  

Control system Library - 2

Austria

Belgium

Brazil

Posted by Imdad at 11:39 AM 0 comments  

Control system Library - 1

Argentina

Australia

Posted by Imdad at 11:39 AM 0 comments  

Wednesday, June 25, 2008

ABB analyzer controls coagulant chemical additions at water utility

May 12, 2008 - An analyzer for dissolved organic compounds now monitors raw river influent and automatically controls aluminum sulfate (alum) additions at a water plant in New Jersey. The township estimates that the system paid for itself within six months in terms of chemical savings and reduced labor.

The utility processes 16 MGD of water. Several neighboring townships rely on it for supply. Influent sources for the water utility include a river, deep and shallow wells, an ASR well, and a pumped water storage reservoir. The versatility in source water options and resulting treatment strategies provide the staff with a process train that can be tailored to maximize efficiency in chemical use, while adapting to changing river conditions.

The analyzer for DOC is an AV400 from ABB Instrumentation (Warminster, PA). A sample pump sends the raw water sample to the AV400 detection cell located within the central treatment building. This cell contains a light source that flashes every 2 seconds through the sample. The detected absorption at 254 nm is updated each time the lamp flashes, and during this brief flash duration the instrument takes over 200 readings. A second measurement at 405 nm enables the monitor to compensate automatically for fluctuations in turbidity. A dual-wiper system, housed in the cleaner module, cleans the flowcell optical windows to help ensure the sensor's functionality.

The utility supplements this cleaning system with a rigorous maintenance schedule to assure the instrument's proper operation. Maintenance technicians conduct calibration checks once every month, a process that takes about one hour. Also at this time, they use a 25% solution of HCl to clean the optics. The instrument is installed downstream of the chlorine dioxide injection, and depending on source water selection, oxidation of material in the raw water can create stains on the optics. The technicians have a weekly scheduled job that requires flushing of the lines and filter maintenance. This prevents clogging and ensures that the instrument continues to see the required flow.

The measured signal goes to the AV400 transmitter mounted nearby. The transmitter display shows inferred values most useful to the user. A typical level of dissolved organics in the river at the intake is about 0.15 to 0.2 mg/l. The signal output from the transmitter is a 4 to 20 mA current proportional to the instantaneous reading. This kind of analyzer requires no consumables, such as reagents, which is a significant economic advantage. The instrument calibration is validated by instrumentation technicians using a pure solution of known carbon content.

A closed-loop system now controls alum treatment additions. The plant SCADA sends real-time online measurements of dissolved organics in the raw water influent to the control room computer. Software processes the dissolved organic measurement, along with other variables, to develop a control signal for the pumps that automatically meters alum to the mixers, as shown in the diagram.

The water plant has experienced substantial savings in chemical use for this process segment. As conditions change, the coagulant dose immediately tracks the online UV254 result. This avoids over or under feeding during the period of time necessary for the operator to manually respond. The online instrument also precludes grab sampling and bench top analytical for UV254, freeing the operations staff to complete other tasks, and negating the need for a dedicated UV spectrophotometer in the lab.

The utility views the continued employment of advanced technology as necessary to keep improving water plant efficiencies. Such efficiencies can help compensate for the multitude of factors tending to drive up the price of water.


Posted by Imdad at 3:40 PM 0 comments  

Labels:

National Instruments offers 6,000 drivers for control

June 10, 2008 – National Instruments now offers more than 6,000 drivers through the NI Instrument Driver Network, the industry's largest source for instrument drivers. Written for the NI LabVIEW graphical system design platform, the NI LabWindows / CVI ANSI C integrated development environment and Microsoft Visual Studio, the instrument drivers make it easy for users to connect to and control stand-alone instruments from more than 275 vendors.

 

For more than 30 years, National Instruments has been a leader in developing technology for integrating and connecting computers with stand-alone instrumentation. With the NI Instrument Driver Network, users can download LabVIEW Plug and Play and Interchangeable Virtual Instrument (IVI) instrument drivers certified by NI and remotely control thousands of instruments, including the latest PXI, Ethernet, LXI, GPIB and USB instruments, from LabVIEW, LabWindows/CVI or Visual Studio. National Instruments continually works with industry-leading instrumentation vendors including Agilent Technologies, Anritsu Company and Tektronix to develop drivers for a wide variety of popular instruments such as multimeters, oscilloscopes and signal generators.

 

In addition to providing extensive support for the most popular instrumentation, the NI Instrument Driver Network now includes the LabVIEW SDI-12 API for interfacing with thousands of environmental monitoring sensors. The SDI-12 protocol is commonly used for environmental data acquisition (EDA) applications such as climate change tracking, water collection and testing, ecological research, soil monitoring, agriculture and weather analysis. By combining the SDI-12 API with the flexibility of LabVIEW, users can create SDI-12 applications ranging from simple data collection and analysis to automated communication, data recording and Web publishing.

 

Adopted by engineers and scientists worldwide, LabVIEW provides a high-level, easy-to-use programming interface that is ideal for instrument control. The software also offers tools that reduce development time such as the Instrument Driver Finder, which helps users instantly search and download drivers from the NI Instrument Driver Network within the LabVIEW environment, and the Instrument I/O Assistant, a utility that helps users perform simple instrument I/O tasks or create their own instrument drivers. Additionally, LabVIEW Plug and Play instrument drivers provide source code native to the development environment and a standard programming model, making it easy to add instruments to a test system without learning new communication protocols or programming paradigms                                     

 

About National Instruments

 

National Instruments is transforming the way engineers and scientists design, prototype and deploy systems for measurement, automation and embedded applications. NI empowers customers with off-the-shelf software such as NI LabVIEW and modular cost-effective hardware, and sells to a broad base of more than 25,000 different companies worldwide, with no one customer representing more than 3 percent of revenue and no one industry representing more than 10 percent of revenue. Headquartered in Austin, Texas, NI has more than 4,800 employees and direct operations in nearly 40 countries. For the past nine years, FORTUNE magazine has named NI one of the 100 best companies to work for in America.

 

 News from automation.com

 

Posted by Imdad at 10:03 AM 0 comments  

Friday, May 23, 2008

CAN in the ISO/OSI stack and higher level protocols

The scope of the CANbus protocol covers the physical and data link layers of the ISO/OSI model. The spec [1] refers to three levels in the CANbus protocol; physical layer, transfer layer and object layer. The physical layer is not defined in the Bosch spec, but is typically shielded or unshielded twisted pair. Idle state is both lines at +2.5 volts. A dominant bit reduces one line, known as CAN_L, to zero, while increasing the other line (CAN_H) to +5 volts while a recessive bit is close to the idle value, with CAN_L slightly above CAN_H, so is “over written” by a dominant bit. A standard for the physical layer of a 500 KBPS vehicle network is defined in SAE J2284-500 [4].

The transfer and object layers between them comprise all the services and functions of the ISO/OSI data link layer. These are discussed in the spec.

Various higher level protocols might be added to CAN itself. Kvaser has some material on this, and Omegas have some links on their website. Of these the Kvaser source is perhaps the more useful. I have also seen an article on higher level protocols that gives an overview of the most important higher layer protocols, especially those used in industrial automation.

The Can in Automation (CiA) trade organisation supports various higher level protocols

1. CANopen
2. DeviceNet
3. CAL (CAN application layer)
4. CAN Kingdom
5. SDS (Smart Distributed System)

CiA is an organisation mainly interested in using CAN for industrial automation so it may well be that the protocols listed above are more common in that field than in the automotive field.

In addition to these, Kvaser list J1939 and OSEK. There is an introduction to OSEK in the companion notes, Miscellaneous Notes. J1939 is an SAE standard for a Truck and Bus Control and Communications Network, that uses the CAN protocol, but includes documentation (though not explicit definitions) for each layer in the ISO/OSI stack. There is a brief introduction to J1939 in the companion Other automotive industry protocols. In addition to those listed on the Kvaser site, there is FNOS that appears to be a Ford alternative to OSEK.

Author: Jon Bell

Posted by Imdad at 1:52 PM 0 comments  

Bit timing and synchronisation

This is covered in the spec [1], of course, and there is an introduction to this in the Omegas material। Briefly, a bit time consists of four non-overlapping segments, Sync-seg, Prop-seg, Phase-seg1 and Phase-seg2. An edge should lie within Sync-seg, while Prop-seg is used to compensate for delay times in the network. It is therefore the sum of twice the signal propagation time on the bus, the input comparator delay and the output driver delay, so is characteristic to the network. Phase-seg1 and Phase-seg2 are used to compensate for edge phase errors. They can be lengthened or shortened by resynchronisation. The sampling point is the boundary between Phase-seg1 and Phase-seg2. As non-return to zero encoding is used, there need not be an edge during Sync-seg, but bit stuffing ensures that there will be an edge after five edge-free ones.


There is a paper on The Configuration of the CAN bit timing which describes the bit synchronisation algorithm and parameters to be considered in calculating the CAN bit time
Author: Jon Bell

Posted by Imdad at 1:48 PM 0 comments  

Error detection

There are 5 error detection mechanisms: -

  1. Cyclic redundancy check. Each message contains a 15 bit CRC code computed by sender and checked by receivers, who will flag any errors. More in the spec (in black binder)
  2. Frame check. At certain points in the frame, the correct value is predefined.
  3. ACK (acknowledgement) Error Check. If transmitter determines an error has not been acknowledged, an ACK error is flagged.
  4. Bit Monitoring. A transmitter checks the network and flags a bit error if the value on the bus is not that sent. This does not happen during transmission of the identifier field, of course, as that is how a collision is detected.
  5. Bit stuffing After 5 consecutive bits of the same value, a bit of the opposite value is added to the frame.

If an error is detected, an error frame is sent, aborting the transmission.

Error confinement (unique to CAN?) provides a mechanism for distinguishing between temporary and permanent errors. Each node has two error counters (for transmit and receive) which are incremented when errors are found. It is covered in more detail in the spececification, but briefly each receive error increments its counter by one, and each transmit error increments its counter by 8. If either counter goes above 127 the node concerned goes into “error passive” mode. In this mode it can still transmit and receive messages, but is restricted in flagging errors. If a device’s transmit error counter goes above 255, the device will go into “bus off” mode and will cease to be active. This condition will clearly need to be modelled in simulating CANbus systems for FMEA. This seems to imply that we must allow for the modelling of repeat errors or for modelling the network as though the counter(s) had reached a level such that devices were going into “bus off” mode.

Error detection is thorough. Omegas stuff suggests that the undetected error probability is 10 to the power of –11. Of course, detected errors will result in loss or delay to messages, which effects might well need modelling.

Author: Jon Bell

Posted by Imdad at 1:47 PM 0 comments  

Message format

The format of the message frames is to be found in detail in the Bosch specifications or in less detail in the omega.co.uk, stuff and the Kvaser website. The standard CAN (2.0A) frame has an 11 bit identifier, while an extended CAN (2.0B) frame has a 29 bit identifier, for compatibility with other protocols used in the US vehicle industry.

The standard identifier format allows for 2032 nodes on the network (2 to 11 =- 2 to 7) and the extended identifier allows more, but as the extra 18 identifier bits are needed for compatibility with other protocols, their use is restricted. The SAE J2284-500 standard [4] allows for any number of nodes between 2 and 16, inclusive, which doesn’t seem many.

A 2.0A compliant device will flag an error if presented with a 2.0B message, unless it is “2.0B passive”, when it will tolerate, but ignore, messages in 2.0B format. 2.0B devices are backward compatible, and can transmit and receive messages in either format. The RTR field (set to 1 if the message is a request for information) follows the identifier. As such a “remote request” frame uses the identifier of the source of the required data, this means that data takes precedence over a request for that data, but a request for high priority data takes precedence over lower priority data. These remote request frames are apparently rarely used. The identifier field and RTR field are used in collision resolution.

The data field can contain from zero to eight bytes, its length being stated by a 4 bit DLC field that immediately precedes the data field.

The data field is followed by a 15 bit cyclic redundancy check, a delimiter, acknowledgement field and end of frame and intermission fields। After these and a set idle time (which may be zero) another node can start transmission।

Author: Jon Bell

Posted by Imdad at 1:45 PM 0 comments  

Network access, collision detection and resolution

Binary zero is represented by a “dominant” state in the bus and binary one by a recessive state, so a binary zero takes precedence over a one, so lower numbered identifiers have priority over higher numbered ones.

CAN is a CSMA/CD protocol. If the network is idle, any node can send a message. If two messages are sent simultaneously, the node that sends a recessive bit, but detects a dominant bit stops transmitting, leaving the network free for the higher priority message. The higher priority message is not corrupted (Non-destructive bitwise arbitration). As this strategy resolves collisions and does not merely detect them, some sources describe protocols with a similar collision strategy as CSMA/CR, Carrier Sense Multiple Access/Collision Resolution. The identifier and RTR fields are used for collision arbitration. Therefore arbitration breaks down if two nodes can send data (as opposed to remote request) messages with the same identifier, as the clash will not be identified until later in the message, giving rise to a bit error. Each node must send data messages with a unique identifier. This has the side effect that if, say, all four road wheels had rotation sensors (for ABS and traction control) they would each need their own identifier, so they would have an order of priority. It seems to me not unreasonable to suggest that this could lead to conflicts in designing the system, which I do not propose to discuss here as it is outside the scope of the project.

This is supposed to guarantee latency, but surely can only do so for messages of high priority? Clearly this guarantees the highest priority message access to the network once the current message transmission is complete. The second highest priority message is guaranteed access after that, provided the top priority message source doesn’t broadcast continuously, so this is pretty much guaranteed. Surely, however, as one moves down the order of priority, eventually one is going to reach a point where a high priority source might be ready to transmit again while a low priority source is still waiting, so its latency is not guaranteed. This is perhaps one reason why the SAE J2284-500 standard is limited to so few nodes? LOOK HARDER. How well this works will inevitably depend on loading of the bus(?) - how heavily used does it get, typically? LOOK HARDER! It seems reasonable to suppose that rotation sensors (for wheel rotation, engine revs etc) cannot send data continually, as it takes time to find the speed, so in practice this might limit bus load sufficiently for latency to be OK. There is a paper on Guaranteeing Message Latencies on CAN I have not yet found a copy।

Author: Jon Bell

Posted by Imdad at 1:42 PM 0 comments  

CANbus introduction

Controller Area Network (CAN) is a network protocol developed by Bosch for vehicle systems, but which is coming into use for linking distributed controllers, sensors etc in other fields. Bosch have published a specification. Any reference herein to “the spec” means this specification, not the ISO 11898 one, which I have not seen (it costs!).

CAN is a CSMA/CD protocol (some sources have CSMA/CR for similar protocols) that uses non-return to zero coding with bit stuffing. It supports speeds of up to 1Mb/s so is an SAE class C protocol, suitable for real time control applications.

Messages are not addressed to intended recipients, but the sender’s identifier is included, and this tells the receivers what data it contains so the receiver ignores it if it is not interested. Messages are given a priority according to the sender’s address, so the priority of messages is decided at the design stage.

In the specifications, there are two standards for CAN 2.0, imaginatively called A and B. These differ in message format (see section 4), B has an extended message format, with a 29 bit identifier, as opposed to A’s 11 bit one.

In basic can (not to be confused with standard CAN) each controller on the network is interrupted by every message on the bus. In full CAN, the CAN devices add filtration of the messages, so a controller is only interrupted by those messages the filter passes, that is those of interest to that controller.

The notes on CANbus in Automobile Electrical and Electronic Systems draw attention to the difference between having a local intelligent control module (for example, for all functions located in the driver’s door) and having the intelligence actually in the actuators, so control is distributed, and each actuator (and each sensor) is on the bus itself.

Posted by Imdad at 1:36 PM 0 comments  

Monday, April 21, 2008

CONTROL ENGINEERING

Control engineering is the engineering discipline that focuses on the modelling of a diverse range of dynamic systems (e.g. mechanical systems) and the design of controllers that will cause these systems to behave in the desired manner. Although such controllers need not be electrical many are and hence control engineering is often viewed as a subfield of electrical engineering.

Electrical circuits, digital signal processors and microcontrollers can all be used to implement Control systems. Control engineering has a wide range of applications from the flight and propulsion systems of commercial airliners to the cruise control present in many modern automobiles.

Control engineers often utilize feedback when designing control systems. For example, in an automobile with cruise control the vehicle's speed is continuously monitored and fed back to the system which adjusts the motor's torque accordingly. Where there is regular feedback, control theory can be used to determine how the system responds to such feedback. In practically all such systems stability is important and control theory can help ensure stability is achieved.

Although feedback is an important aspect of control engineering, control engineers may also work on the control of systems without feedback. This is known as open loop control. A classic example of open loop control is a washing machine that runs through a pre-determined cycle without the use of sensors.

Posted by Imdad at 7:19 AM 0 comments  

Labels:

CONTROL SYSTEMS

A control system is a device or set of devices to manage, command, direct or regulate the behavior of other devices or systems.

There are two common classes of control systems, with many variations and combinations: logic or sequential controls, and feedback or linear controls. There is also fuzzy logic, which attempts to combine some of the design simplicity of logic with the utility of linear control. Some devices or systems are inherently not controllable.

The term "control system" may be applied to the essentially manual controls that allow an operator to, for example, close and open a hydraulic press, where the logic requires that it cannot be moved unless safety guards are in place.

An automatic sequential control system may trigger a series of mechanical actuators in the correct sequence to perform a task. For example various electric and pneumatic transducers may fold and glue a cardboard box, fill it with product and then seal it in an automatic packaging machine.

In the case of linear feedback systems, a control loop, including sensors, control algorithms and actuators, is arranged in such a fashion as to try to regulate a variable at a set point or reference value. An example of this may increase the fuel supply to a furnace when a measured temperature drops. PID controllers are common and effective in cases such as this. Control systems that include some sensing of the results they are trying to achieve are making use of feedback and so can, to some extent, adapt to varying circumstances. Open-loop control systems do not directly make use of feedback, but run only in pre-arranged ways.

Posted by Imdad at 7:12 AM 0 comments  

Labels:

Subscribe to: Comments (Atom)

HASH

Template bycomputer internet technology | Search engine optimization