Determinism, when associated with PLC’s, refers to the predictability of the response time of the system. One of the big arguments against using PC based systems is that they are “non-deterministic”. \u00a0This is probably somewhat of a misapplied term, but it has stuck pretty well. \u00a0This argument is routinely leveled against PC based systems by the manufacturers of PLC’s.<\/p>\n
This same argument was used for many years by Allen Bradly against Ethernet networks -vs- their proprietary (and often very slow) networks, such as “Data Highway”.<\/p>\n
I will readily acknowledge that “determinism” is a potential problem with PC based systems, and with Ethernet as a network for industrial controls. \u00a0Poorly written software can make a PC based control system a complete disaster. \u00a0The same can be said for PLC’s, but the PLC will probably still execute the poorly written program in a somewhat “deterministic” manner. \u00a0So, the PLC doesn’t get the black eye for determinism that the PC does.<\/p>\n
The dirty little secret of PLC’s is how difficult it is to write good code for a PLC. \u00a0PLC programming lacks any real structure, and has few if any real guidelines for producing quality code. \u00a0I would argue that “ladder logic” almost encourages bad programming. \u00a0It is much easier to write bad PLC code than it is to write good PLC code (assuming there is such a thing as good PLC code.)<\/p>\n
Let’s look at the Ethernet determinism argument. \u00a0PLC vendors (Allen Bradley to name one) spoke out vocally for many years against using ethernet as a communication protocol in control systems. \u00a0At the time they were bashing ethernet, they were selling network products based around very slow serial based solutions such as Data Highway. \u00a0Many Data Highway implementations were running at top speeds of under 150k baud. \u00a0Most were running in the 57k baud range. \u00a0Ethernet was running at 10 megabaud rates at that time. \u00a0Although data highway was slow, it was “deterministic”, according to AB. \u00a0Ethernet was not. \u00a0One can’t deny AB’s basic argument, but due to the raw speed (and cost) difference between the two networks, digging a little deeper seems appropriate.<\/p>\n
Nominally, the 10 base T Ehternet network is about 200 times faster than a 57k data highway network. \u00a0This means under optimal conditions, the network could transfer 200 times the information. \u00a0We know that isn’t going to happen, but we also know that chances are the Ethernet network will outperform the data highway network on average. The issue becomes, how often, if ever, the variable latency of the faster network cause a transaction to arrive slower than the worst case data highway message. (and whether it matters.)<\/p>\n
We have installed dozens of system using Ethernet based automation equipment running at 10 millisecond transaction times, and haven’t had problems with slow transactions becoming noticeable. \u00a0That is not to say that we were pushing the network hard, but the point is that it is possible to get very reliable operation at 10ms scan rates from standard ethernet equipment in control systems.<\/p>\n
Now that most network equipment is at least 100 base T, the argument becomes even less meaningful.<\/p>\n
The issue of determinism (non-determinism) in PC based controls is another discussion. \u00a0There are timing issues with Windows based computers that can’t be avoided completely. \u00a0However, the issues can be well understood, and dealt with very effectively in most cases. \u00a0It is important to have a good idea of what latency is really tolerable in a control system. \u00a0PLC manufacturers boast of highly deterministic systems, and that may be true. \u00a0But, don’t get the idea that the scan rate of every PLC system out there is down in the milliseconds. (And don’t get the idea that it has to be.) \u00a0I have seen SLC 500 systems running with scan rates of hundreds of milliseconds without causing noticeable problems in the overall picture. \u00a0This is not to say that this performance level could be tolerated in all cases, but it is to say that tens of milliseconds or less scan rates are not necessary in all cases. \u00a0There are many systems in the industrial automation world that are controllable with loop times that stretch into the tenths of seconds. \u00a0I would further argue that in most control applications, there are times where seconds could lapse without response from the control system.<\/p>\n
The point is, not all systems need extremely fast response one hundred percent of the time. \u00a0So, if we want to use a PC as a control, we need to understand how to get the level of performance required by the application when the application needs it.<\/p>\n
If PLC’s were equal in all ways to PC’s, and they had completely deterministic behavior 100% of the time, there would be no reason to consider PC’s as controls. \u00a0But, PLC’s are not equal to PC’s in all ways. \u00a0That is why we must evaluate whether the advantages offered by a PC offset the lack of determinism. \u00a0To seriously consider a PC, we must have a high degree of certainty that the PC based solution will always respond in a way that real-time control is maintained in the application.<\/p>\n
To make this determination, we must have a good understanding of what we can expect from a PC, and what level of timing we need in the application. \u00a0As a rule of the thumb, I use 20 milliseconds as “real-time” to a human. \u00a0I don’t have science to back this, but I do have a lot of experience to back it. \u00a0If a control system responds to a human input within 20 milliseconds, most people don’t sense the latency. \u00a0When the latency approaches 50 milliseconds, most people can sense it. \u00a0It is not an annoying latency, but it is noticeable. \u00a0When the latency starts to exceed 100 milliseconds, it becomes very noticeable, and can be annoying.<\/p>\n
So, to satisfy the human response, I consider 20 milliseconds or better completely satisfactory. \u00a0I also consider occasional latency of several tenths of seconds as acceptable in most cases.<\/p>\n
The other piece of the equation has to be what level of performance is required to make the equipment function properly, and more importantly safely. \u00a0This analysis can be more difficult, but we can infer that if a PLC would not be questioned as a solution, the answer is probably at least several tens of milliseconds is probably acceptable. \u00a0(It is important to recognize when this is not fast enough, even when using a PLC as the control!)<\/p>\n
If there is any kind of high speed motion that relies upon the control system to stop the motion before damage is done, further analysis should be done. \u00a0(The design of the whole system should probably be questioned too!) \u00a0In cases where light curtains are being used to protect people, it is important to completely understand how things are going to respond in the system. \u00a0If the light curtains are being properly applied, all motion should be stopping due to hardware interlocking, and there should be assured safe distances in the design. (The point being, control system response time shouldn’t factor into safety in a properly designed system!)<\/p>\n
With properly written software, it is not difficult to get consistent responses in the 10’s of milliseconds with a PC. \u00a0It is also not difficult to keep maximum latency periods down in the tenths of seconds. \u00a0So, with proper evaluation of the application, and with well written software, it is practical to consider PC’s as controls in many circumstances.<\/p>\n","protected":false},"excerpt":{"rendered":"
Determinism, when associated with PLC’s, refers to the predictability of the response time of the system. One of the big arguments against using PC based systems is that they are “non-deterministic”. \u00a0This is probably somewhat of a misapplied term, but … Continue reading