PLC's have always been real-time, albeit fairly slow (>10 ms cycle time). Beckhoff Automation developed very high-speed PLC's (EtherCAT 0.05 ms cycle) and has marketed it as "Scientific Automation" (i.e. to eat NI's lunch). B&R Automation has similar high-speed PLC's. The advantage of PLC's is that much of the overhead is built into the system. Your code doesn't have to poll the I/O for values or manage cycle loops. The PLC system does that and has the I/O readings available automatically for your code. The I/O wiring is simpler and more rugged than most DAQ hardware. The hardware is also claimed to be more reliable and supported for decades. Prices are fairly comparable. Indeed, when I last priced an NI FPGA solution, it came out x2 higher with all the software licenses. Beckhoff's latest push has been to migrate the code environment into Microsoft Visual Studio, allow PLC coding in C/C++, and integration with Matlab Simulink. That should make it attractive to scientific labs. On the factory floor, NI's integration with vision may still be better. I haven't worked with that lately.
2. List the five major components of a PLC system along with the function provided by each.
3. List the advantages of fixed and modular PLCs.
4. Explain the function of a PLC program.
5. Compare the way in which the states of devices are referred to in an electrical diagram and in a ladder logic program.
6. When does logic continuity occur in a rung of a PLC ladder logic program?
7. Compare hard-wired-type control with programmable control.
8. For safety reasons, a programmed start/stop circuit is always wired using normally closed stop push buttons. Why?
9. Compare the way in which electromechanical and programmed timers operate.
10. State what timer instruction(s) is associated with each of the following:
a. Time that has elapsed since the timer was last reset.11. What would be the correct address for a push button connected to terminal 4, slot 1, of a single-rack SCL 500 modular PLC controller?
b. Time-delay period.
c. Contact that changes state after the timer times out.
12. List three common functions programmed counters perform.
13. What does the accumulator of a programmed counter count?
14. How is a programmed counter reset to zero?
15. Explain the principle of operation of an up/down counter.
Like a surgeon who needs to go in and do a biopsy to see if an area of cells or a tumor is cancerous, a technician needs to go in to the PLC code to see if the code is good or bad. Sometimes a technician needs to replace old, failing code with new code, like a surgeon needs to replace an old, failed knee or hip with a replacement.
As long as we take care of our bodies, like eating healthy foods, we will live longer. As long as we write and thoroughly test machine code, and fault and diagnostic code with easy visual readout to the human world, then that machine will run better and longer. When code has been poorly written, or the machine code has not been thoroughly tested, or the machine health is not visually seen on the machine, then the technician/surgeon will have to open the machine code to see what is going on.
Admittedly PLCs (and similar devices like DCSs, embedded controllers, PC controllers, etc) are my hammer and I look for nails. If the system doesn't have any smart devices I'm probably not working on it so there is little need for me to simulate it. I think that your choice of simulation methods at that point would depend a lot on just what you are trying to model and you would select different methods for different situations. PLCs/HMIs could still be a good hammer for you in some cases but if you are looking at 3D motion you might need a different solution.
Being able to look at PLC code has usually been the very first place I go to try and troubleshoot a misbehaving machine.
Or perhaps adding a millisecond or two to a timer will allow production to continue at 2:45 am. A good technician should be able to do that without calling me from my slumber.
The market trend of PLC and PLC-based PACs in China shows a high correlation with the macroeconomic scenario. In 2012, Chinese PLC and PLC-based PAC market seems to have declined significantly. But this is a natural fallout; when industrial growth is lackluster, the demand for automation reduces.
ARC Advisory Group's report, "PLC and PLC-based PACs for China Market Research Study" states that the PLC market in China is experiencing fierce competition and this trend will not change in the short-term. Almost all global PLC suppliers have forayed into the China market, and domestic players are emerging, especially in the micro PLC market. According to David Cao, Country Manager, ARC Advisory Group China, and author of this study, "To succeed in the competitive marketplace, suppliers must differentiate themselves and continue to offer increasing value propositions to end users and OEMs and respond with agility to market dynamics. This is especially important because the market is expected to grow steadily during the forecast period and beyond as users in many industries have recognized that increased automation is vital for increasing productivity, efficiency, and energy conservation."
The programming software loved bu "programmers" may not be easily understood by maintenance professionals who don't have the time to learn the "similar to assessembly language" coding. There is a definite disconnect in the interface between real world maintenance concerns and the manufacturers/programmers.
I have seen many enhancements that improve productivity of contract programmers at the expense of maintainability and troubleshooting. Most maintenance departments are under a lot of pressure to do more with less and do not have the time to learn all of the new programming systems. Add to this the lack of support at the user level and life can get difficult on the line. With the current economic conditions support has been cut to the bone and the manufacturers are hard pressed to provide the support thay might like to.
The most time-consuming part, however, has always been to get familiar with the PLCs, and understand the workings and technical specs. Whenever I've had to integrate other equipment into a Simatic environment, I've always taken care to make sure that that particular equipment was compatible (standard analogue signals, standard comm. etc.); most manufacturers even provide some sort of communication or interface code-snippet to insert into the Simatic environment for their equipment!
Of course I'm biased by my education and experience, but I'm sure everyone is; Siemens just happen to be my choice of brand due to my positive experience, and I will naturally bring that to my customers. Due to my lack of experience with other brands, I'll be reluctant to use other manufacturers, even though they might be equally good.
The last project I did with Siemens PLC involved S7 Hardware, the Sematic development environment, several small HMI's and a Wonderware SCADA system on a Profibus card with a Siemens custom OLE driver (before the days of OPC) The bit/byte order 'feature' was carried forward and it involved far more programming effort to create and debug the translation tables and communications error-checking than it did to create the rest of the program.
A-B PLC needs to distinguish between their "traditional" PLCs (PLC5, SLC, and smaller) and Control/CompactLogics PLCs. ControlLogix PLC (rockwell deservedly calls it PAC) which I used a lot in process control applications was capable of doing any complex control loops I had to put together. CLX also is tag-based, so no idiosyncratic addressing that someone mentioned is there anymore (blocks of timers, etc.) Custom instructions (Function blocks) are also available. Data structures - yes, too. Now even some advanced control capabilities are built right into CLX software.
I do have 15 years of experience and as a result of this I can say that Siemens is not my brand of choice. If you choose for Siemens you sell your soul to their sales department. Their License strategy is only to rip your money. What is the additional value of all the updates every 6 months? After an update the machinery dos not have any more output or whatever. I advise my customs GE Fanuc. Its a very stable platform, easy to use software (4 days free trial) and enables my customers to service it without big (expensive) trainings and so on. Free firmware upgrade. Out on the North sea I never meet an S7. GE Fanuc proves to be that solid platform designed for doing the job. Unfortunately nowadays not the E&I or automation engineer decides what to choose, But the purchasing department. They, off course, do not have any technical knowhow.
Rockwell did loose out slightly because of their Lisencing policy, but the clients that have moved to Siemens have found that their policy has its downside too.
A lot of it depends on how a product is sold (and who its sold to).
There are good reasons to have a single platform in a plant or even enterprise.
Other than that it comes down to personal preference, many engineers in the UK just don't like Siemens (an opinion mostly deriving from the ghastly Step5 software). But I have heard people say they hate Siemens, others hate Rockwell and love Mitsi. Personally, I'm not keen on Mitsi, from the programming point of view. I am comfortable with both Siemens and Rockwell (and Mitsi, Omron and Modicon for that matter), but I prefer to program using RSLogix by a mile. Just my preference though.
The network infrastructure and firewalls need to provide the security for the most part. Additional security can be added to the PLC code by way of encryption or a calculated heartbeat or checksum method within the data to prevent write attacks. However, again this complicates the application.
GE may have been one of first to offer a UDP solution with a light protocol header, so I do believe in UDP for certain applications, however, special care must be taken in applying it for control data, and application code can be required at both ends to pack and parse the data. Good planning is required to leave room for expansion in an orderly manner if this is used for data transfer or collection. This method is particularly efficient when the application requires multiple end points to receive the data (multicast). This data multiplexing method or protocol creation within the data exchanges is a very seasoned approach going way back to modbus rtu and before, when data types were an application issue, not a communications issue. Be sure to plan for the dropped packet as there is no guaranteed delivery with UDP.
This is not the cheapest way to get information, but if you have a system of any real importance then the support and documentation is worth the money.
If you develop a custom application then if there are problems then YOU have to handle it and if something happens to the developer what do you do?
Again if you are using an HMI then the HMI provider often provides servers for that application. Many power meters etc. use Modbus RTU or ModbusTCP as standard and the OPC server might be needed to get this data.
Typically you need to buy OPC server for each PLC. You can develop or buy a single OPC client that will communicate with all OPC servers. Then you need to interface your application with the OPC client.
Another alternative is to build protocol drivers directly using the native protocol supported by the PLC. Then the deployment will be PLC - protocol driver - your application.
Don't forget that if you have an windows based HMI you probably already have an OPC server installed. You can access the data from the HMI application just as easily as from a secondary OPC server. Most HMIs support this data exchange.
As to custom applications please remember that means that YOU are continued support and in the future the author may not be with the company. Any savings at the front end may be regretted many times later when changes must be made for some reason.
In short you would have three networks serving PLC, HMI, and Management data. To maintain the highest throughput at the control level you would want to limit the number of data requesters and maximize the exchange form these servers to your other applications. The HMI system can either be separate and serve only the workstations or both the workstations and your applications.
In my opinion the separate data servers are a good choice with Ethernet communications since the data throughput is high and the hardware is inexpensive and available. Keeping the networks separate is a good idea from both a security aspect and throughput as well.
Math's functions are the very things that all computers, including PLCs do most naturally and most easily. What? PLCs were designed for Boolean logic? Well that’s true, but processors were originally designed to do maths functions, and all the other clever things they appear to do are really about doing maths functions. It was never particularly challenging to make PLCs do maths, even floating point maths. (Even PLCs sometimes had maths co-processors.)