标签：
无标签
I’m not sure you’re asking the right question. What you really need for control applications is a controller, which is a complete computer system, not just the microprocessor. As a control engineer, that is what you want to concentrate on.
The figure below shows a simple single-axis control system. The brains of the outfit reside in the controller. All the other components are simple, low-complexity analog devices. While some of those external devices might contain some programmable elements, the system’s decision making engine is the processor running the controller.
Control engineers need to worry about controllers, not the microprocessors that go into them.
That doesn’t mean that those other components don’t have any intelligence. Microprocessors are everywhere, and their capabilities, as well as the jobs they perform, vary widely. Most of the blocks shown contain at least one microprocessor.
The data acquisition electronics, for example, likely contains at least one microprocessor that directs the microsecond-by-microsecond activity necessary to sample a voltage, digitize the sample, put the sample into a memory buffer, and assemble a data packet needed to send the value over a serial bus to the controller. Even some sensors now have microprocessor controlled calibration capabilities.
The brains these system elements have, however, is typically very tiny compared to the controller’s smarts. The controller has to direct the overall operation in real time. It has to understand the sensor input, compare it to set points that describe the desired operating state, determine corrections intended to bring the actual state closer to the desired state. It is also responsible for any running the human-machine interface, if it exists.
No matter how you slice it, those requirements mean the controller needs a whole lot more than just a microprocessor. It’s a whole, grown up digital computer, not just a microprocessor. So, what you need to ask is what controller do I need, not what microprocessor.
No matter what your skill level, I do not recommend, as a control engineer, designing and building your own controller. There are lots of folks in lots of companies that do that for a living. Do yourself a favor and restrict your efforts to selecting the controller you need from commercial offerings.
As with any digital computer, there are certain elements required to make it go. Clearly, it needs at least one microprocessor. It also needs working memory — what most people refer to as “RAM” or random access memory — to hold instructions awaiting execution and data awaiting analysis or uploading.
It also needs multiple ways to communicate with the outside world, such as USB, Ethernet, serial ports, etc. It will use these to take data in (for example, from the data acquisition section) and send data out (say for use by the drive electronics. If it has to communicate with humans, it will do so through peripherals, such as biometric readers, display screens, printers, and so forth. It needs peripheral interfaces for those.
All digital computers need application software as well, which leads to a requirement for non-volatile memory to store it in when the computer is shut off. Controllers are no exception. Some systems, such as automotive engine control modules (ECUs), get by with rudimentary software burned into an electrically programmable read-only memory (EPROM). Others require large, sophisticated operating systems and application programs requiring tens of megabytes.
Controllers come in three basic types, which differ mainly in the way the minimum required features are packaged:
Programmable logic controllers (PLCs) and programmable automation controllers (PACs) are the desktop PCs of the automation world. They are designed to be more-or-less general purpose, providing all the capabilities needed for broad classes of applications. With these systems, all control engineers need to do is select a make and model, then develop application software.
PC-based control systems leverage technology readily available in the commercial PC market. Users, however, bear a great deal more responsibility for selecting peripherals and integrating them into the system. A subset of these units include industrialized PCs, which feature ruggedized packaging to survive harsh industrial environments.
Embedded systems put the most responsibility on the control engineer. He or she must not only specify a larger fraction of the components that go into the controller, but integrate them into a coordinated system and program them as well.
To incorporate PLCs and PACs into a control project is pretty much completely a control engineering task. Stepping into the PC-based world forces the engineer to spend somewhere between 40% and 60% of his or her effort on computer engineering. Embedded system designers spend 80% or more of their effort on computer-engineering tasks.
The tradeoff is flexibility. PLCs, for example, are pre-packaged for computer numeric control (CNC) and similar applications. PC-based control systems are capable of doing pretty much anything, but packaging options are limited for both the controller and peripherals. Engineers designing embedded systems are pretty much free to create anything they want in any package they want.
So, the rule of thumb is to do as much as you can in the PLC/PAC world. If you can’t accomplish what you want there, look into PC-based control. Only work with embedded systems if you can’t do it any other way.
In choosing the type of controller implementation, engineers trade increased computer design effort for increased design flexibility.
I’m not sure you’re asking the right question. What you really need for control applications is a controller, which is a complete computer system, not just the microprocessor. As a control engineer, that is what you want to concentrate on.
The figure below shows a simple single-axis control system. The brains of the outfit reside in the controller. All the other components are simple, low-complexity analog devices. While some of those external devices might contain some programmable elements, the system’s decision making engine is the processor running the controller.
Control engineers need to worry about controllers, not the microprocessors that go into them.
That doesn’t mean that those other components don’t have any intelligence. Microprocessors are everywhere, and their capabilities, as well as the jobs they perform, vary widely. Most of the blocks shown contain at least one microprocessor.
The data acquisition electronics, for example, likely contains at least one microprocessor that directs the microsecond-by-microsecond activity necessary to sample a voltage, digitize the sample, put the sample into a memory buffer, and assemble a data packet needed to send the value over a serial bus to the controller. Even some sensors now have microprocessor controlled calibration capabilities.
The brains these system elements have, however, is typically very tiny compared to the controller’s smarts. The controller has to direct the overall operation in real time. It has to understand the sensor input, compare it to set points that describe the desired operating state, determine corrections intended to bring the actual state closer to the desired state. It is also responsible for any running the human-machine interface, if it exists.
No matter how you slice it, those requirements mean the controller needs a whole lot more than just a microprocessor. It’s a whole, grown up digital computer, not just a microprocessor. So, what you need to ask is what controller do I need, not what microprocessor.
No matter what your skill level, I do not recommend, as a control engineer, designing and building your own controller. There are lots of folks in lots of companies that do that for a living. Do yourself a favor and restrict your efforts to selecting the controller you need from commercial offerings.
As with any digital computer, there are certain elements required to make it go. Clearly, it needs at least one microprocessor. It also needs working memory — what most people refer to as “RAM” or random access memory — to hold instructions awaiting execution and data awaiting analysis or uploading.
It also needs multiple ways to communicate with the outside world, such as USB, Ethernet, serial ports, etc. It will use these to take data in (for example, from the data acquisition section) and send data out (say for use by the drive electronics. If it has to communicate with humans, it will do so through peripherals, such as biometric readers, display screens, printers, and so forth. It needs peripheral interfaces for those.
All digital computers need application software as well, which leads to a requirement for non-volatile memory to store it in when the computer is shut off. Controllers are no exception. Some systems, such as automotive engine control modules (ECUs), get by with rudimentary software burned into an electrically programmable read-only memory (EPROM). Others require large, sophisticated operating systems and application programs requiring tens of megabytes.
Controllers come in three basic types, which differ mainly in the way the minimum required features are packaged:
Programmable logic controllers (PLCs) and programmable automation controllers (PACs) are the desktop PCs of the automation world. They are designed to be more-or-less general purpose, providing all the capabilities needed for broad classes of applications. With these systems, all control engineers need to do is select a make and model, then develop application software.
PC-based control systems leverage technology readily available in the commercial PC market. Users, however, bear a great deal more responsibility for selecting peripherals and integrating them into the system. A subset of these units include industrialized PCs, which feature ruggedized packaging to survive harsh industrial environments.
Embedded systems put the most responsibility on the control engineer. He or she must not only specify a larger fraction of the components that go into the controller, but integrate them into a coordinated system and program them as well.
To incorporate PLCs and PACs into a control project is pretty much completely a control engineering task. Stepping into the PC-based world forces the engineer to spend somewhere between 40% and 60% of his or her effort on computer engineering. Embedded system designers spend 80% or more of their effort on computer-engineering tasks.
The tradeoff is flexibility. PLCs, for example, are pre-packaged for computer numeric control (CNC) and similar applications. PC-based control systems are capable of doing pretty much anything, but packaging options are limited for both the controller and peripherals. Engineers designing embedded systems are pretty much free to create anything they want in any package they want.
So, the rule of thumb is to do as much as you can in the PLC/PAC world. If you can’t accomplish what you want there, look into PC-based control. Only work with embedded systems if you can’t do it any other way.
In choosing the type of controller implementation, engineers trade increased computer design effort for increased design flexibility.
系统分类:
PLC/PAC | 用户分类:
无分类 | 来源:
原创