Welcome to PLC Start

I started with DAQ products - NI, Computer Boards, etc, initially in scientific research. I have lately switched to PLC's for both control and DAQ. Traditionally, DAQ is not real-time. Most would record a data buffer on-board which is later read into PC memory. At Westinghouse, we used NI boards under QNX to realize real-time data collection & display. I also made a real-time system with a DAQ/DSP board from Innovative Integration. NI has since made real-time DAQ & control using FPGA's (Compact RIO and others) and has marketed to the automation world.

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.
PLC control will become more prevalent at that point allowing the implementation of less sophisticated control devices, this will in turn allow the DAQ to occur through the PLC. Providing that the workforce is monitored and not allowed to conduct their own training programs on the equipment. Once they lose the buttons they were pushing, they will experience a loss of control and will compensate. (I have witnessed in-house mechanics breaking devices so they can learn how to fix them, deliberate sabotage so they could come up with the fix when the boss shows up, and the unnecessary replacement of expensive parts to resolve a simple manual intervention issue; "Just so we could show them we changed something...") The problem with line scan cameras and other high-end devices like that is that they are typically used in harsh environments, subject to process loads, and sold into inappropriate applications.
1. What is a programmable logic controller and how is it utilized in motor applications?
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.
b. Time-delay period.
c. Contact that changes state after the timer times out.
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?
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.
Just as companies evolve, so has the positions within a company. The technicians are a vital part of a company in maintaining the healthy operation of the equipment.

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.
I simulate entire systems to the extent that the control system knows about them (e.g. whatever makes it to the PLC and HMI. I will simulate level changes based on simulated flows and the measurements of the tanks, positions based on speed and time, running signals and speeds based on run commands and speed demands, pressure can be trickier so sometime you just have to BS it a bit (air pressure can be done based on the physics of the system but incompressible pressures are a bit of a guess or perhaps based on pump curves, etc. Some modeling I have done using excel which then spits data back at the PLC and can also give you good charts and graphs for tuning but largely mine is done in PLC logic by replacing field inputs with logically simulated inputs and watching the results on the HMI as if it were real time.

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.
My machine has developed a 'sticky' valve. It works as it should 99.999% of the time, but every so often, my cylinder doesn't quite make it into position when it is supposed to. Do you write an error message for dozens or hundreds of cylinders that 'might' fail to operate properly one in 500,000 cycles?

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.
Chinese economic growth is at a critical juncture. After 30 years of high-octane growth, it is seeing a comparative slowdown due to internal and external pressures. The macroeconomic data released from the China State Statistics Bureau showed the declining GDP growth rate — 7.8 percent in 2012, lower than 9.2 percent of 2011. This is the slowest China GDP YoY growth in the past 13 years.
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.China PLC market forecast 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."
I think that all PLC's are probably reliable and capable, but the issues of importance would be maintenance of the process and support available. For the maintenance personnel the support software (programming software) is very essential and needs to be readily understandable. Maintenance issues usually do not have much to do with which PLC is used, but rather how easily is the program understood and failed or failing instruments and discrete components attached to the I/O.

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.
As certified automation technician and IT engineer, I have been thoroughly trained and educated in the Siemens Simatic platform, way back from the old S5 and upwards, and I must say that their products have never failed me; whenever a new piece of Simatic equipment was integrated into an existing configuration, or a whole new plant for that matter, it has always been smooth and with little or no problems to speak of. I'm also experienced with Omron and AB, and again, they haven't caused me any significant problems.

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.
I have personal knowledge of an automotive plant in Detroit. After years of extreme frustration the team of electrical maintenance staff finally did reverse-engineer the Siemens products and replaced most of it with AB on their own time! (The company bought the AB equipment.) I do not mean to imply that the Siemens PLC is poor equipment. It is not. The programming environment of the day though (Lad90) set a whole new standard for awkwardness. It became especially unwieldy if you had to interface with any third-party HMI's. As a programmer you were required to communicate with the HMI in blocks of 16 contiguous bits and the bit/byte order expected by even the brand-labeled Siemens HMI's was not the default bit/byte order provided on the S7 PLC front port. This meant that a great deal of your programming effort went into creating 'translation tables' and your documentation would turn into an incomprehensible mess. In conjunction with the 256 rung limit per program segment... Well if felt like you were working in several straight jackets at the same time.

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.
Siemens PLC is mostly used in process industry, like food and beverages, whereas AB is used in discrete manufacturing like assembly. But it depends upon who can do a better job of selling. I worked on a lot of GM projects, where they were solely using A-B PLC, but now they have switched over to mostly Siemens.

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.
From my perspective (we do most brands of the biggest PLCs, so don't really care what our customers use), I've seen a good chunk of "top down" approach, where corporate has made a decision, likely on price, to push this into the plants. Some of the plants we've been dealing with have really been suffering, as they don't have the training to support, and aren't prepared for the costs in supporting these. We've also seen a lot of customers that have purchased machinery already containing Siemens, again, with no in house or local support. In the last year, I've seen a HUGE push in the Detroit area towards Siemens, most all coming from the top, and forced down through the plant. From our perspective, it's created some true havoc!

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.
I can't speak for anywhere other than the UK with any great authority, but in the circles I tread it is hard to differentiate between the three main players Rockwell, Siemens and Mitsubishi.

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.
HMI or other Operator Interface that can provide the connectivity to the PLC by way of the native protocol of the PLC. This allows the best data access capabilities to the various PLC memory types. From there, the HMI should be able to provide an OPC Server (or even an sql) connection for other applications and devices to share the data.

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.
I have used Matrikon OPC servers for years. I have not used universal PLC server, but Matrikon is a good application. For each PLC you will set up a communications channel and the server pretty much takes care of itself. Also available are redundant servers that will assure communications.
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.
OPC or OPC UA is very good in terms of interfacing and standardization. But one issue we have faced is the cost of OPC server for a particular PLC. I don't know if you want to connect to many different PLCs or only one type of PLC. But here is how the deployment will be - PLC - OPC Server for the specific PLC - OPC Client - Your application

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 my opinion the necessity is to protect the various networks that need to intercommunicate and maintain both physical and data security. The systems that you will have running the applications that need the data will probably be PC related or PC's and the interface would be your server. The server would have at least two network cards addressed to the separate networks. The Ethernet PLC network addressed into the PLC domain provides the link to the PLC data and this network has only this connection to the server(s). The OPC server or HMI server passes on the data to the higher level network. If your system uses HMI interface the data servers that serve this data to this system can probably also serve the applications you desire on a third network.

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.
The basic mathematical functions performed by most PLC's are: add, subtract, multiply and divide. These types of instructions are used by PLC's to gather data from various memory locations, to compare data, and to scale values. Data comparison is an extremely useful programming tool that allows outputs to be energized depending on whether data in one memory location is greater than, less than, or equal to data stored in another memory location. Scaling is also an important application of math function because it allows numbers which are very small or large to be enlarged or reduced by a fixed constant. The standard format for math functions in many PLCs is that the desired math operation is performed on a memory location, and not directly on a number. In other words, if you wish to add two numbers, these numbers must be entered into memory locations, and the contents of the addresses will be added together.

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.)
servicePLC manufacturers
Sales Email buy@plcstart.com
Support Email tech@plcstart.com