Why do you pay for PLC programming software?

C
Hi Dave
I don't disagree with all your points, but you are basing the whole works on price. That is not why I am looking elsewhere for my small PLCs.

Cost and value are certainly factors, but the
Mitsubishi units I am installing in the interim are actually more expensive than Micrologix. And I don't think it's quite accurate to class Mitsubishi as a bargain basement company either.  I don't classify Koyo there either
seeing as they have been a premier supplier
to many big names.

It's about reliability. And the training issue is a red herring for me as I wouldn't hire anyone who could only use one brand of PLC. In my situation that would be ridiculous as we support many brands.  The spares argument kinda
works the same way in my situation.

I suppose if you're all AB then it works for you to be all AB and it certainly makes them happy. But what do you do if you need a product they have problems with? Should I write off the failures because it's AB? No can do.

Regards
cww
 
D
Curt:

I hate to admit it after 10 + years, but I actually kind of agree with you here.

Mark this day.

PS: Had to throw the kind of in there.................. : )

Dave Ferguson
 
V

Vladimir E. Zyubin

It's really interesting, why do we pay more?
$99 PLC with RS and TCP/IP stack + the C language on the board are all we need (in 99,9% of projects). The misstandardisation and the close architectures look like a key for right answer.
 
C
I kinda liked Forth, but I'm better now. It was one of the better "ROMable" languages for the Z80.

Regards
cww
 
B
Might work for some situations but many automation porjects need to have something a little easier to debug, test, and modify out on the plant floor.

For a simple system that can be shutdown to relaod a program, and you have an experienced C programmer available to do any programming and debugging, the $99 answer may work OK.

For factory floor systems where you need the ability to do online programming, debugging, and testing by plant electricians, it is an awful choice, no matter how cheap.
 
K

Ken Emmons Jr.

Curt,

I have long thought of using C++ with RTOS for machine control and wrapping commonly used functionality into objects. Picture a pneumatic
cylinder with hall effect limit switches on both ends of travel (90% of motion we use at my company). You could instantiate an object called
"CylinderWithLimits" or something like that. You could even define timeouts and things associated with waiting for the cylinders to hit the end stroke switches, and even have it generate error messages and such. Imagine a program that looks like this:

SomeSequence() {

// Extend method extends the cylinder, waits for switch,
// generates timeout message if not actuated.
// Method could also check for common issues
// such as switches wired in reverse, etc.

TransferCyl.Extend
InsertCyl.Extend
InsertCyl.Retract
TransferCyl.Retract
}

Who could argue that this would be difficult to read, while still understanding the functionality? Of course you would have lots of object instantiations in some setup code, but you only have to do that once per project (or when adding new mechanisms).

Of course, you can do the same in ladder (and I have, in a more manual way using function blocks), but in the end there is more debugging and code entry. I currently use Mitsubishi PLCs with the IEC programming software (using ladder with function blocks) because they have the fast IO, fast CPU, and other supporting hardware/software such as analog IO, communication, and such in a small modular package (The Q series PLC).

If I could have the same package programmed with a high level language and RTOS with drivers to handle all IO, life would be good. Unfortunately with rolling your own controller using PCs you have to deal with drivers for every peripheral, and it needs to work seamlessly with your RTOS as well, which is not trivial. Then there is the potential for hardware/software interactions with multiple vendors. I wish I had an answer, but things are not quite there yet in my opinion. If anyone has any suggestions, I'm all ears. :eek:)

KEJR
 
W
This method is easy to program and read, but difficult to debug and diagnose. What do you do when you call TransferCyl.Extend and nothing happens?

A major reason that ladder logic is so popular is that it replaces extensive diagnostic routines. Instead of built in diagnostic routines, you just give the customer ladder source code and let them read the logic and diagnose the problem themselves. Nothing is hidden.

I suppose you could put enough error messages in the code that the end user instantly knows what conditions are not met, but that is a lot of work to write and maintain.

Most high level computer languages do not display variable values while the program is running either. You must set breakpoints and your program is stopped while your outputs are still in their last state. (been there, done that) Or write more code to print values of all of the variables to a debug screen.

These are just a few of the reasons why most people just throw in the towel and use PLC's for direct machine control. PC's are better used for supervisory control.

Bill
 
D
You can do something very close to this now in AB Controllogix Version 16.

The ability to build custom function blocks and custom data types in whatever language under the covers you chose (of the 4 (of 5 6311-3) languages).

I have done this a lot, so you can build a standard motor or valve type (object) and have all the code written the way you like it and then punch out instances of them. If you change the master, they all change (or not if you chose). Once you create the FB you can use it as a ladder object or a function block, but when you open it (available or you can make it view only or lock it out all together) it could be written in ladder, or FB, or SFC or structured text, which is very close to a C-like language. In fact I have some hydraulic cylinders written just as you described below... by creating my own data type, I am able to access "parameters" just like this davesvalve.zso (open limit) or davesmotor.mz (motor final control element) or davesmotor.mi (motor indicator) or davesmotor.mcas (motor control auto start or davesmotor.mci (motor control interlock), etc.

Very handy and very close to what you speak of and yet if I want to use the logic as ladder (which the plant floor gets) then I can and embed the logic inside the "ladder" for the more "complex" parts.

P.S. You can also do this in DeltaV (pretty closely).

Dave Ferguson
 
W
I like Forth too, but I can't figure out a way to actually use it. The basic concepts are brilliant, but it is very difficult to master. You have to learn to think differently, which is never easy.

Bill
 
M

Michael Griffin

In reply to Ken Emmons Jr.: The problem with the sequence example in C++ you gave is that it doesn't show any conditions for initiating the sequence. It also doesn't handle auto/manual, sequence initialisation, etc. It also doesn't show how you would do multiple things in parallel. These are the messy details that tend to account for the bulk of the logic in a typical program. In fact, making the machine move is often the easiest part of the entire project.

What is really missing in PLCs are what is known in conventional programming as application frameworks. Frameworks go beyond libraries in providing an overall template for an application where you just have to fill in some details. You still have to know how to program, you have to pick the right framework for the job, and there is a learning curve for the framework itself, but it saves a lot of time when developing routine applications. For example, custom web applications (which is where most custom business programming is done these days) are moving to being done with things like Rails or Django.

As an example, consider the following. You have a machine whose mechanism consists of a number of pneumatic cylinders and MRS switches (which describes probably 90% of the machines in a typical factory). At the minimum you typically need initialisation, sequencing, fault detection, auto/manual control, and alarm monitoring. A lot of this could be fill-in-the-blank type configuration (especially fault detection and alarm monitoring).

You would still have to write the details of the actual sequencing, but that is usually fairly easy. You would also need different frameworks for different classes of machines (e.g. a water system versus a press), but again, most people deal with a narrow range of machinery and so would only need to learn a few templates.

Many people try to get some of the benefits of this by copying and pasting code. That however tends to import more complexity into their programs and they still have to hand edit most of the logic.

Unrelated to the above (the following has nothing to do with the programming frameworks I was describing above), your example doesn't really need C++ to operate. You could have a simple compiler convert that logic into Mitsubishi code.
>
>> TransferCyl.Extend
>> InsertCyl.Extend
>> InsertCyl.Retract
>> TransferCyl.Retract

You would need to add parameters which define what I/O to use, and what bits to use for sequence control, but the compiler itself would be very simple. You would need to define that TransferCyl and InsertCyl are of type "Cylinder". Type "Cylinder" would contain a string or strings (which you create) that holds the IL code for what you want a cylinder to do. The compiler then just goes through your sequence list and substitutes the parameters into the pre-defined string to create the code for that step.

Essentially, the compiler would simply automatically replacing the sequence description with a stored standard code template that you have created. Regular expression strings can be used to validate the sequence program (i.e. that you typed in valid inputs and outputs for the sequence).

The end result is an ordinary PLC program with most of the code being auto-generated. Someone looking at the end result wouldn't know that it wasn't all created by hand. Getting that into the Mitsubishi programming software is left as an exercise for the student.

Something like this could be written in Python or Perl (or possibly even awk) fairly easily. It is basically just a bunch of string compares and string substitutions to transform one set of text into another set of text. I suspect that this is more in line with what you are looking for.
 
V

Vladimir Zyubin

I do not propose to use the C language as a programming tool, just as a perfect and sufficient means to create "OPENability" of PLC.

BTW, the C language is not more dificult than ST (a Pascal-like) or IL (an assembler). Obviously, they do not meet requirements the control programming set.

--
Best regards,
Vladimir
 
K

Ken Emmons Jr.

Thanks Dave,

I'm glad I'm not the only one doing this out there. I am doing very similar with Mitsubishi IEC developer (not supported in the US, but it is going to become the next Mitsu platform globally with the next release this year, or so I'm told). I wanted to use RSLogix, but at the time they didn't have the custom FBs. How is RSLogix with regard to timers within user defined function blocks? Mitsubishi gets weird about timers when the function block is called like a subroutine, or should I say, when it doesn't get called (i.e. not scanned). I've had to configure most of my function blocks using timers to be "macro" function blocks that compile to inline IL. I would hope Rockwell handles it better.

~Ken
 
K

Ken Emmons Jr.

Hello,

Yes, of course I agree that making the machine move is the easiest part, but, having said that, doing it with all of the error handling and recovery code is what makes it heavy and bug prone to do in ladder in my opinion. My example code would have to be used with an RTOS and need to have conditions placed around it, of course. I've done this in RTAI and Epson robot controllers already and it isn't that difficult. You have your code start up, initialize variables and equipment, spawn new threads to handle the parallel-isms, and then have a main program that controls when the parallel threads are executed (This can be a simple "If" statement, or an RTOS related Mutex/Semaphore/Signal thing that doesn't incurr a task switch unless the variable is true). Of course, multithreaded programming is difficult for the beginner to understand, but so isn't race conditions associated with PLC scanning. I consider myself a fairly advanced PLC user and I still get bit once in a while by a problem with the way the PLC scans and some stupid mistake I made. The difference is that in normal PLC programming the glitches caused by scan issues can happen *everywhere* in your code. With RTOS you write your architecture once and debug it. The code within that structure tends to be easily modified.

I've used both, done it both ways and there are benefits to each approach, certainly. I've done simple ladder with brick PLCs that did nothing but sequence on timers, to sequencing on switch input, to full error handling based on swith input with timeouts on everything. In my experience the PLC/Ladder/IEC approach is quicker for simple things, but more complex for other more complicated things. Changing the ladder code, especially where complex decisions are concerned is more involved. I can re-arrange lines of text and write "If" statements much faster than adding and subtracting sequence rungs, renumbering them, moving function blocks, etc.

On the other hand, PLCs are nice because you can "cheat" when you need a quick and dirty parallel routine, even within a POU (using IEC speak) that is sequential. There is no doubt that this is powerful and fast.

I like your idea regarding a preprocessor for Mitsubishi, but this is already done to some extent with the IEC Devleoper implementation. What you have to do is wrap the features in a function block and instantiate it every time you use one. It can be made to be close to the same thing by passing in predefined structures that "configure" the function block [object] for each instance. Or, you can use input variables to configure the FB. It just gets really repetitive and heavy to do it everywhere. Whats missing from your preprocessor idea is the debugging aspect, which, to me, is one great feature of most PLCs. Given infinite time you could run a PLC debug session by reading and trying to understand compiled IL, but its really not worth it. Getting in there and seeing what step of a sequence you are in, monitor and forcing variables and IO and seeing its effect on the code is essential.

In the end, I think it boils down to what you are more efficient at. If you need to write programs that are read and modified by people who don't know high level languages, then I guess my proposed approach is not valid for those applications. I stick to my guns, however, that human readable (intuitive) text programming is much easier to understand for the layman. What is more difficult is the layout architecture syntax that you describe. Are there really [a majority of] plants out there where people need to completely re-arrange architecture without consulting the engineer/programmer? My machine architecture almost never changes at that level (I'm struggling to think of an example) unless there are major overhauls/upgrades to equipment. Most of the time it is more like tweaks to delays, swapping the order of sequences, adding an operation, etc.

I appreciate your opinions, you bring up some good posts over the years of me reading this list. I don't know all the answers, which is why I brought it up, but I do know that the IEC implementations just aren't all they are promised and there are bound to be better ways for future systems to be programmed. You have to wonder with kids coming out of school having programmed in C/C++ and/or Basic if the natural order of things will change over time. My experience with programming Epson robots and their implementation of a multitasking robot with a "C" like programming environment is extremely rich. Its not without issues but I've been able to not only program the robot, but also entire rotary turntable machines operating in conjunction with the robot, without a PLC attached, and much faster than any PLC I've ever used. I'm not trying to promote them, Its just my solid experience with a text based language system that was done right for automation. If only they made it with a PLC like format with all of the available add on modules, and added object capability in addition to functions. ;-)

~Ken
 
K

Ken Emmons Jr.

Bill,

Thanks for the input, these are valid concerns. I think you are starting to get what I'm saying in one of your comments:

> I suppose you could put enough error messages in the code
> that the end user instantly knows what conditions are not
> met, but that is a lot of work to write and maintain.
It boils down to how you program. I have timeouts on everything. The machine *Never* stops without alerting the operator of something beign wrong. I have HMI touch panels on every machine for this reason. The nice thing is the operator has instant feedback which in most cases allows them to troubleshoot the machine quickly and get it back to running. You could have your message built and sent to the HMI by the controller by the object, something that would equate to:

"Transfer cylinder did not extend in the alloted time."

Where "Transfer Cylinder" is the descriptive HMI name set up in the object at initialization/Instantiation.

"Extend" and "retract" can be built in to the message (or use some other term that you initialize), or you could have custom fixed messages for both states of the pneumatic device. The possibilities are endless with a higher level language. Again, these things are programmed in initialization code, once, and 99% of the time never chang. It might be possible to auto generate much of this, using scripting tools as Mr. Griffin points out.

The monitor capability boils down to the capabilities of your RTOS and support software for the controller "system". You definitely need a system where you can monitor the state of threads and break into execution, step through code, etc. You also need the ability to monitor variables. I think for 99% of your initial concern, however, is handled by having a self diagnosing code will get you away from the need to monitor the ladder code directly.

I haven't seen a system that does everything I would ideally like, that's why I'm still using a PLC for most projects. As I said in my email to Mr. Griffin, however, the Epson Robot controller (RC+) does a lot of this already. If something like that were packaged in PLC hardware (right now it's a metal rack mount kind of thing with an industrial PC inside) with appropriate IO/communication modules things would start into the right direction.

~Ken
 
B

Business Industrial Network

Although I agree with you to a point, why pay for software (Hey I am human too. :>), I can easily justify the cost. Sure it would be nice to only pay a couple hundred for the software, but with AB RSLogix software, we show customers how to save hundreds of thousands of dollars using the RSLogix 500 and 5. (Because we teach our customers how to minimize downtime which saves the TDC. See http://www.DowntimeCentral.com)

Allen Bradley's RSLogix has features that other PLC vendor software does not have or is too difficult to use, that if thought by the right instructor can save you the kind of money mentioned above.

So that is the main justification for the software price, but for those who can not see the intangible, $1k software is only 10% of a typical $10k PLC System installed. Then your next system, and next, and next no software required if you stick to standardization while purchasing future PLCs. So if your facility has 5-20 SLC 500 and or Micrologix, the RSLogix software is only a fraction of the cost. (Plus other vendors can include software price, hidden within their equipment PLC hardware cost.)

Now for Controllogix and RSLogix 5000, the above does not apply. Because the RSLogix 5000 is a new type interface leaning (catering) towards the higher level software programming languages that IT people understand and electricians are overwhelmed by. Also the annual fee, but that is insignificant compared to the downtime caused by the huge learning curve and social barrier caused by the RSLogix 5000.

To stray a little from the software cost topic and better explain what I mean by "Social Barrier" (because it is interesting :>), I'll explain what most of you already know. The workplace for a PLC pre-RSLogix 5000, was you install a machine, and unless if breaks down, you pretty much did not mess with the PLC. When it broke down, an electrician would use the PLC and his 10-30 years electrical experience to troubleshoot. Typically he would find a electrical/mechanical problem and fix it or have a mechanic fix it. To modify an exsiting RSLogix 500 or 5 program, the electrician was well aware of safety and reliability issue being noted before he/she would make a change. Work with the OEM when needed, base on the electrician's experience.

The new social barrier is that with Control Logix (RSLogix 5000) industry is finding the need to bring IT into the picture. Because of the Ethernet management primarily, but also to help with the learning curve of the new interface that caterers to computer programmers, not ladder logic programmers (electricians). The barriers are that typically IT people do not have 10-30 years experience with electrical work or the machine. Also I fear the concept that IT changes typically do not have real word, real time effects that can damage man or machine, they may be more prone to those kind of mistakes. (Which stresses the importance that IT get more real world training before let lose on th PLC. But additionally when a machine does go down, now you have the IT guy, the Electrician and the mechanic. So simply put, 33% more time to repair and chance for error. (Actually it would be higher when you take a TDC mentality. Because of a much increased chance for personality conflict, lack of hierarchies, procedures, authority, communication and understanding.)

Just wanted to get my two cents in. And no offence intended towards the IT people, they are some of our best PLC training students. Just stating what most already know, they need more electrical and PLC training for their new job responsibility. :>)
 
M

Michael Griffin

In reply to Ken Emmons Jr.: My replies are in-line with your comments so that I can respond to each in turn.

KE:
> Yes, of course I agree that making the machine move is the easiest part,
> but, having said that, doing it with all of the error handling and
> recovery code is what makes it heavy and bug prone to do in ladder in my
> opinion. <

MG Reply:
This was the point I was responding to when I was talking about application frameworks. When you are looking at a particular class of applications (e.g. assembling parts on a dial table), a lot of things in the PLC code tend to be very repetitive from one machine to the next, with small differences in detail. That is, things like detecting faults, reporting alarms, editing and
selecting product recipes, etc. are usually very similar. They are usually *not* similar enough though to let you simply copy a program from one machine to another and just make a few changes (at least not without gradually evolving into an undecypherable mess).

An application framework would let you select the architectural characteristics (the overall design features which make a dial table different from a water purification system), automatically create an overall framework for the program, and let you fill in the details. The actual details of the alarm handling wouldn't be visible to you. You would simply tell the software things like "this is a cylinder, these are the limit switches for it, these are the messages I want associated with it, and this is the time limit on cylinder stroke", and the alarm system would take care of the rest.

The parts of the program that you would concentrate on the most would be the parts which make your application unique. There would need to be a number of different application templates, because no one template would fit all applications. You would also need to be able to develop your own templates, as it wouldn't be feasible to predefine all possible fields of application.

I'm not saying that I have a clear idea of how to do this at this time, nor am I saying that I thing that ladder logic is suited to this. I am saying though that I think this is the direction the industry needs to go in, in order to progress. I think the foundations for frameworks such as this would have to be built into the PLC or soft logic system to really make it work well, so I don't think it is something that could be easily added to existing systems.

KE:
> My example code would have to be used with an RTOS and need to
> have conditions placed around it, of course. I've done this in RTAI and
> Epson robot controllers already and it isn't that difficult. You have
> your code start up, initialize variables and equipment, spawn new
> threads to handle the parallel-isms, and then have a main program that
> controls when the parallel threads are executed (This can be a simple
> "If" statement, or an RTOS related Mutex/Semaphore/Signal thing that
> doesn't incurr a task switch unless the variable is true). <

MG Reply:
I don't think the OS needs to be an RTOS. It simply needs to be multi-tasking (unless some of tasks themselves really need to be real time).

KE:
> Of course, multithreaded programming is difficult for the beginner
> to understand, but so isn't race conditions associated with PLC scanning. <

MG Reply:
What the designers of ladder logic (and IL) dialects have done is to design a language that is "non-blocking". That is, the natural way of writing it is in a manner that allows it to "scan" continuously in a single thread.

I think that in order for your idea to achieve general acceptance, the language syntax would need to naturally takes care of these details. This way, the compiler would be able to fill in the details by itself, and also catch a lot of the possible programming errors.

KE:
> I like your idea regarding a preprocessor for Mitsubishi, but (...)
> Whats missing from your preprocessor idea is the debugging aspect,
> which, to me, is one great feature of most PLCs. Given infinite time you
> could run a PLC debug session by reading and trying to understand
> compiled IL, but its really not worth it. Getting in there and seeing
> what step of a sequence you are in, monitor and forcing variables and IO
> and seeing its effect on the code is essential. <

MG Reply:
Actually, debugging would be the same as debugging any PLC program. The preprocessor idea is really just a code generator that outputs IL. Ladder logic is just IL that is written to follow certain recognisable patterns. In fact, the easiest way to create the code strings would be to write the
standard ladder logic that you want to reuse over and over again, convert that to IL, and then paste it into the code generator.

Once you had output your sequence for an application, you would work with it in ladder after that. It's just saving you a lot of routine typing when creating the program. It would also save you from a lot of routine typographical mistakes as compared to typing it all in manually. Anyone seeing it later though would simply think that you typed it all in by hand very methodically. You wouldn't use the code generator to make small changes to the PLC program. It is meant only for creating large new chunks of code
from scratch where there is a lot of code repetition.

This isn't as advanced a concept as what you were discussing, but it is something that could be applied today to almost any PLC. It would mainly be of use to someone who has to write a lot of fairly similar PLC programs. It is a feature that could even be built into the programming software.

KE:
> this is already done to some extent with the IEC Devleoper
> implementation. What you have to do is wrap the features in a
> function block and instantiate it every time you use one. It can be
> made to be close to the same thing by passing in predefined
> structures that "configure" the function block [object] for each
> instance. Or, you can use input variables to configure the FB. It just
> gets really repetitive and heavy to do it everywhere. <

The difference with the code generator is that you aren't creating a function block. The code is being inserted in-line. That code could call a function block of course, but it doesn't require one.

A number of SFC implementations are simply code generators. The code they generate though is usually very hard to understand, because there is such a large semantic gap between SFC and ladder. The code that is generated by the means that I am talking about above should be easily understandable, as it is really just human created code that is being automatically inserted.

I'm not saying the code generator idea is the answer to all your problems. I was just pointing out that it seems to address part of what you were looking for while still using the same hardware that you already have. It also gives some perspective on actually implementing the ideas.

KE:
> My experience with programming Epson robots and their implementation
> of a multitasking robot with a "C" like programming environment is
> extremely rich. (..) Its just my solid experience with a text based
> language system that was done right for automation. If only they made it
> with a PLC like format with all of the available add on modules, and
> added object capability in addition to functions. <

Industrial controls seem to be evolving to where I/O is mainly on a network, so the physical package the logic runs on is becoming less important (provided of course you use an open protocol). So, it ought to be feasible to
use a system such as you describe even if it isn't packaged into a PLC (you just really want something in a rugged and reliable embedded computer).

If we go back to your text example, I think the idea has enough merit to warrent further thought. What I don't see from your example is how you could handle parallel sequences with divergence and convergence without all the work of writing the code for launching a separate task. For example, consider your original example:

> TransferCyl.Extend
> InsertCyl.Extend
> InsertCyl.Retract
> TransferCyl.Retract

What if I want TransferCyl.Extend and InsertCyl.Extend to happen at the same time? We would need to add some coordination functions. They could work something like this.

Wait(TransferCyl.Extend, InsertCyl.Extend)

That however gets quite complicated though for non-trivial sequences.

We would need a syntax that expresses sequential and simultaneous operations. The following is an example which I am presenting for the sake of discussion.

If we wanted to hide a lot of the implementation details, then we would need to define a set of sequence data structures which could be passed to a class which took care of whatever needed to be done in order to execute the sequence (however that is accomplished).

For example, if "()" were to enclose operations that happen simultaneously, while "[]" could enclose operations that happen sequentially, then this could translate to:

Step1 = (TransferCyl.Extend, InsertCyl.Extend)
MainSeq = [Step1, InsertCyl.Retract, TransferCyl.Retract]

TransferSeq = Sequencing(MainSeq)
TransferSeq.Run()

In the first two lines we are assigning lists of steps to variables, which defines the actual sequence. In the third line we are instantiating a
particular sequence from a sequence class. In the last line we are running the actual sequence. There would need to be other class methods of course for stop, fault, single step, etc. The "Sequencing()" class would take care of whatever needs to be done to execute the sequences.

The above is valid Python syntax, but there are probably ways of doing the same in other languages.

All of this (application frameworks, code generators, sequence syntax) is all related in a way. Typical application frameworks usually include some sort of template language to define how the framework is instantiated. I think it
should be possible to use a sequence template language to automatically generate the details of the sequence logic together with all associated alarm logic etc., without straying too far from familiar PLC concepts.

I'm not sure that existing PLCs though are the best platform to implement this on. I think there needs to be some higher level architectural support so that some of these features are built in without having to add huge masses of IL code to implement them.
 
K

Ken Emmons Jr.

Hello,

In response to Michael Griffin:

You bring up good points with the framework. I don't know of such a tool to use for this, and my preference would be to have it be backed by the programming and monitoring software maker unless it can produce code that is highly readable. Something like Structured Text (ST) with human readable tags (instead of memory addresses an IO) would be nice. This is just my opinion, but IL is readable but somewhat difficult to understand at a large scale, especially when you are looking at an uncommented mass of instructions. It all depends on the target PLC I would think, which language is handled better (or even supports it).

As far as the code and changing order and making some things in parallel, one simple way is to have more methods such as this:

MyCyl_1.ExtendNoWait
MyCyl_2.ExtendNoWait
MyCyl_1.WaitExtended
MyCyl_3.ExtendWithWait

Or something similar. Of course we would have to figure out the language of it all to make sense for each object type, but it accomplishes the basic logic of what cylinders get fired in series and what is in parallel. I do now in a different way with ladder and blocking languages alike.

This is just my opinion, and please readers... don't respond with flame email, ;-) but I think blocking code is easier to understand than scanned code. What is missing, and I think you touched upon this, is the ability to break into parallel code and reconverge when you need it. In ladder it is quite easy, you make two sequences, trigger them, and then wait on them both to be done. What does get a little confusing is in the classic multithreaded model dealing with triggers and waiting on things to be done is handled by creating two threads, triggering them from a master, and waiting for them to be done. I'm not reall afraid of this, but I have gotten into debug sessions with this type of thing that can be confusing.

We can classify the OS or System as as being multithreaded for now and not get into OS details. I'd hate to diverge into a discussion about deterministic vs. non-deterministic and all that, its best left for OS discussions.

Now that we have said this, it brings up something I have long thought: Flowcharting is nice for organization, but crappy for detail work (IMHO). I personally like having flowcharts on some complicated sequences that branch and loop for understanding and documenting. Of course there is SFC and Steeplechase VLC that are touting this as a method for the outer structure of the program. For many reasons these languages are not always good for low level "detail" programming. What about using simple Flowchart like language to define your branching, merging, and looping, and do the guts in a "blocking" text type language such as I described (It could be modified version of "C" or whatever). Does this not do everything we need for machines?

I agree that existing PLCs would be a bad target for such a device for many reasons. I think the open remote IO almost gets us to a point of being able to run a standard embedded PC of sorts, but its not quite the same. With IO starting to run on Gigabit ethernet, I don't know if this is the case anymore. You still have to pick the right IO systems and tailor your software around them if you do your own software with open fieldbus IO. I've found that even [what should be] simple modbus TCP implementations impose single digit millisecond delays on things for no apparent reason. I know some "slice" IO systems, at least in the past, have delays in their serial piggy back "backplanes". I haven't done enough with fieldbus IO to tell if this is the norm, however. When dealing with high speed equipment imposing millisecond delays on sequences due to hardware limitations is not good. This is why we are using top of the line Mitsubishi with fast response input cards on the backplane. Not because we need it, but it saves us that much time on our machine cycle wich can pay off quickly. Maybe the answer is to have an embedded PC with multiple ethernet ports to handle all the different networks you are likely to have?

Thanks,
~Ken
 
M

Michael Griffin

In reply to Ken Emmons Jr.: My replies are interspersed with your comments below:

On April 23, 2008, Ken Emmons Jr. wrote:
> You bring up good points with the framework. I don't know of such a tool
> to use for this, and my preference would be to have it be backed by the
> programming and monitoring software maker unless it can produce code
> that is highly readable. Something like Structured Text (ST) with human
> readable tags (instead of memory addresses an IO) would be nice. This is
> just my opinion, but IL is readable but somewhat difficult to understand
> at a large scale, especially when you are looking at an uncommented mass
> of instructions. It all depends on the target PLC I would think, which
> language is handled better (or even supports it). <

MG: I don't think that what I have in mind would work too well with a conventional PLC. It could be packaged in an embedded computer that *looks* like a PLC, but there needs to be a lot more capability than just executing IL code. I think it would look something like the following:

First, the soft logic interpreter would be part of the overall framework and execute inside it, rather than the framework executing inside the soft logic interpreter. That is, the code which executes the IL (or ladder) logic would be a library which is part of the overall framework. This is why a conventional PLC wouldn't work with this idea.

The overall system would take care of things like scheduling logic execution, communicating with I/O, stop/program modes, etc. There would be a set of standard class libraries that would handle things like cylinders, conveyors, dial tables, etc. This set of classes could be extended and added to by the user to handle tasks that were not included with the standard ones.

These class libraries would be written in an ordinary scripting language, not IL. You would have to know *something* about programming to extend or add to them, but the learning curve would be fairly easy. Programming in the scripting language wouldn't be required to use the system (write PLC programs), only if you wanted to extend the system.

When writing a logic ("PLC") program, if you wanted to use for example the "Cylinder" class, you would need to import it into your program. The class would do nothing by itself until you filled in some details. If you opened it up like a function block or subroutine, there would be several sections inside which you had to fill in.

You would fill in some of them by writing some simple ladder logic. For example, there would be the start of a rung for "extend" which you would have to complete by including an output(s) plus any additional permissives you want.

There would be an alarm section that included logic which detected faults, plus any associated alarm messages. Displaying alarms on an MMI and acknowledging them would be handled by the overall framework, not by logic in the soft logic section. Whether those alarms were displayed on an graphics terminal, a web browser, or a mobile phone would be completely transparent to the PLC program.

Most of the class sections would be automatically created with some sort of reasonable logic or messages, so you would only have to change those things which didn't fit the default.

Once you have created this "logic object" (as I will refer to it), it could be used as you said, "TransferCyl.Extend", "TransferCyl.Retract", etc. There would also be "TransferCyl.Extended" and "TransferCyl.Retracted" to indicate the actual state of the cylinder (not to mention "TransferCyl.Faulted", and anything else defined by the class).

Logic objects would usually, but not necessarily be associated with inputs and outputs. You could also have logic objects which purely deal with internal logic, such as auto/manual mode changes, start-up, shut-down, etc.

Now, to contradict what I said previously, to aggregate these logic objects into a program, you would have two choices. One method would be to use it as an ordinary output instruction in ladder logic. In this mode, TransferCyl.Extend and TransferCyl.Retract would be like set/latch or reset/unlatch instructions in that they would be active if they were called and the logic stack was true. Of course you wouldn't specify an address (as this was already done), but otherwise you could use them

For example (in IL):

STR "StartButton"
AND "CycleStart"
TransferCyl.Extend

STR TransferCyl.Extended
AND "StartButton"
TransferCyl.Retract

(The above example by the way should appear as one instruction per line - in case the line wrap gets lost in this forum.)

The above allows people to use the capabilities of the system without straying too far from familiar ladder logic. It doesn't address sequencing though, which was your original concern. To deal with that, we need to add a set of sequence classes. These would include a "state" or "step" class, a "sequential" class, and a "simultaneous" class.

A "state" or "step" class would be a container class which collects a group of logic objects into a "step object". The step object would again include alarm messages which would supplement (or even replace) the messages in the logic objects. When all the logic objects in the step object were ready, the step object would itself indicate a "true" condition. For example (in IL):

# The control section activates the outputs.
- Control:
- STR "ON"
- TransferCyl.Extend
- InsertCyl.Extend

# The status section monitors the results. When all are true, the step is ready to advance.
- Status:
- TransferCyl.Extended
- InsertCyl.Extended

Step objects can be aggregated by means of "sequential" and "simultaneous" class objects. The difference between these two is that in one, each step proceeds one at a time in sequence and the sequence is done when the last step object is complete, while in the other, all proceed simultaneously and the object is complete when all step objects are ready. Sequential and simultaneous objects can be nested to allow sequences of any arbitrary size and complexity to be constructed.

The above would require a complete system that is designed around the concept. It isn't something that could readily be added to a conventional PLC. I have a pretty good idea of the overall software design to create this, and it would need to be loaded onto something more like a computer than a traditional PLC. It would also replace the traditional MMI panel, because the MMI logic would be integrated into the control logic system (the logic objects contain MMI components).

KE:
> This is just my opinion, and please readers... don't respond with flame
> email, ;-) but I think blocking code is easier to understand than scanned
> code. What is missing, and I think you touched upon this, is the ability
> to break into parallel code and reconverge when you need it. <

MG: In PLC applications, you tend to need to physically do a lot of simple things in parallel. It is more or less inherent to the application so the system should be designed around that. Ladder logic does this well. What ladder logic does poorly is coordinating these small details into sequences. But as the above illustrates, it is possible to readily extend the above concept to handle that explicitly.

KE:
> We can classify the OS or System as as being multithreaded for now and
> not get into OS details. I'd hate to diverge into a discussion about
> deterministic vs. non-deterministic and all that, its best left for OS
> discussions. <

MG: I agree, the concept does not depend upon RTOS versus conventional OS. Some applications might require a fast RTOS, but that is a separate issue.

KE:
> Now that we have said this, it brings up something I have long thought:
> Flowcharting is nice for organization, but crappy for detail work
> (IMHO). I personally like having flowcharts on some complicated
> sequences that branch and loop for understanding and documenting. Of
> course there is SFC <

MG: The problem seems to be that ladder logic (and IL) are too low level, while SFC is too high level, and neither concept is readily extended to cover the whole range. I think that SFC is an excellent design tool, but it doesn't extend well to the actual implementation. The problems of ladder logic in large programs are too well known to bother mentioning here.

There are similar problems by the way in conventional computer programming. There are a number of code generators which can create Java programs from flow charts (generally some form of UML). They work, but only in some very limited applications. Huge sums of money have been sunk into this problem without success, so it looks to be inherently unsolvable for the general case.

KE:
> I agree that existing PLCs would be a bad target for such a device for
> many reasons. I think the open remote IO almost gets us to a point of
> being able to run a standard embedded PC of sorts, but its not quite the
> same. With IO starting to run on Gigabit ethernet, I don't know if this
> is the case anymore. You still have to pick the right IO systems and
> tailor your software around them if you do your own software with open
> fieldbus IO. I've found that even [what should be] simple modbus TCP
> implementations impose single digit millisecond delays on things for no
> apparent reason. I know some "slice" IO systems, at least in the past,
> have delays in their serial piggy back "backplanes". <

MG: From what I can tell, the problem is the limited capability of the communications hardware in most PLCs and their I/O racks. I've seen delays of over 100 msec. in remote I/O racks in older PLC hardware. I've also seen similar delays in many PLC rack backplanes (in the same rack as the CPU even!) once you get away from simple digital or analogue I/O. This is why small cheap shoebox PLCs can often outperform large expensive rack style PLCs in many applications. Several years ago I cut approximately 15% off the cycle time of a set of machines by replacing one large PLC with several smaller ones (one per machine).

KE:
> I haven't done
> enough with fieldbus IO to tell if this is the norm, however. When
> dealing with high speed equipment imposing millisecond delays on
> sequences due to hardware limitations is not good. This is why we are
> using top of the line Mitsubishi with fast response input cards on the
> backplane. Not because we need it, but it saves us that much time on our
> machine cycle wich can pay off quickly. Maybe the answer is to have an
> embedded PC with multiple ethernet ports to handle all the different
> networks you are likely to have? <

MG: Some networks (e.g. Ethercat) use special hardware in the I/O nodes to cut I/O delays without adding excessive cost to the I/O.

Even with standard Ethernet though, you can get good speed provided the protocol is simple enough that the software doesn't have to work too hard to decode it. I have done PC applications with using I/O modules which had a simple Ethernet protocol, and reading the inputs or writing the outputs took an average of less than 0.75 msec.

There are a few other things that make a difference as well. One is whether multiple I/O nodes are polled in parallel, or one at a time. If they are polled in parallel, the total time for a poll is the time the slowest node takes. If they are polled one at a time, then the total time is the sum of all of them. This can make a *big* difference.

Another thing is how simple the protocol is. Older RS-485 (or proprietary media) based networks were often limited by network bandwidth, so some protocols were designed to limit how much information they would transfer. For modern Ethernet though, the bottleneck is usually inside the I/O module itself rather than in the network bandwidth. This means that a simple protocol can outperform a complex one because it requires less work from the I/O module logic (field devices have to be designed with cost and low power in mind). Sending the state of all the inputs in a module at once can actually be faster than sending the state of just one.

When you have a lot of bandwidth, brute force and simplicity will usually outperform a "clever" protocol.
 
Top