PLC_MISC: front end to translate AB/Modicon/Omron/etc

L

Thread Starter

LouisKriek

QUOTE............
Subject: LinuxPLC: To store, or not to store, that is the question
What is the AB meaning to the FILE parameter? Is it applicable to the Puffin PLC, or is it to make it look more like an AB PLC? If this is the case,
why don't we just write a little front end to translate AB/Modicon/Omron/etc configuration files to our own internal format (which could be
AB/Modicon/Omron/OurOwn/etc)?
..................

I have been holding off, (because of doubts that I could explain how to actually achieve this)
but in the spirit of brainstorming:

I have been imagining what an idealised PLC could be (now or in the future).
Imagine a PLC which can be programmed/monitored by laptop with the commercial/off-the-shelf
Allen-Bradley software like RSLogix or what ever AB software. Imagine the very same PLC being programmed by the next person who happens to like/has-been-trained-on the Omron programming software Syswin or whatever.
Our LinuxPLC would simulate communications to-and-fro normally going into the RS232 socket on the Allen-Bradley PIC device, or the RS232 socket on the Hostlink. Replace all the brandname placeholder in the sentence above with Your
favourite brand.

Imagine the LinuxPLC being as smart as we human beings are. The LinuxPLC can "eyeball" the ladder diagram of Any brand and be able to
explain/evaluate the workings of the Ladder Logic diagram. And like us human beings, it will have difficulty with some of the wonderfully strange
idiosyncrasies in some of the different brands.

(This is where I have my stumbling block)
Because I don't anticipate that we are clever enough to untangle this "tower of Babel", which we must if we are not to be limited to just the
"lowest common denominator", then a less ambitious desire is for the LinuxPLC to just be able to be programmed/monitored by a laptop with the commercial Allen-Bradley software. The LinuxPLC gives all the anticipate responses to the commercial Allen-Bradley software. This means that the whole world of Scada software which expects to communicate to an PLC that speaks the Allen-Bradley language, will not notice any difference. This means that all the work that thousands of people have done to communicate
to Allen-Bradley PLCs will immediately work with this LinuxPLC too. ie none of their work needs to be sacrificed for those people to have a try at
using our LinuxPLC.

Maybe the ladder put into the LinuxPLC by the Allen-Bradley commercial software needs to be wiped away before another person can use his(her)
Omron commercial software to download a new Ladder program into the LinuxPLC. Now the pre existing Scada packages will need to be set to use
their Omron PLC drivers to communicate to the LinuxPLC.

Perhaps it may be possible to have two separate Ladder Diagrams within one LinuxPLC. For example, the baking oven was installed by Allen-Bradley type people who downloaded their Ladder into the LinuxPLC, but the material handling conveyors to and from the backing oven was installed by people who just could never understand the Allen-Bradley way of doing things but are experts at the Omron way of doing things.

People comfortable with Allen-Bradley's software (or hardware) can use the parts they are comfortable with, and those comfortable with Omron's can use Omron's programming software. Those wanting the newly developed programming
software (either plugged in the traditional way, or co-resident) can mix and match in a very "Open" way. If Allen-Bradley or Omron want to add
incompatibilities they are free to do so. But imagine if Allen-Bradley was compatible with a LinuxPLC today, and imagine Allen-Bradley introducing incompatibilities into their new version of software to thwart the LinuxPLC, then it would not look a good quality company if what used to work with an unchanged LinuxPLC suddenly no longer worked. There is a certain amount of those things that can be done, but just as in politics, doing those things will spend some of the "political capital" or "goodwill". If there was plenty to begin with then there is no risk of
running out of goodwill. They may find it in their own interests one day, (or they may not) to view to LinuxPLC source and they may suggest ways to overcome some obscure bugs that we have never heard of.

The economic consequences might one day be... Allen Bradley gets to sell yet one more RSLogix programming package to someone, and Omron gets to sell yet one more Syswin programming package. Neither of them loose out, which they would if a Linux programming package had been used. The factory gets to use the programming/monitoring software that its people are comfortable/quick with.
And thirdly, those people who want to program the Ladder with some LinuxPLC version of the Ladder programming/monitoring software on an external laptop or even co-resident on the LinuxPLC box, can do so in their own good time and be able to sleep soundly at night knowing that if they get into difficulties they have the Brandname software as a fall back in times of real-need/danger/panic.

Both the Allen-Bradleys and Omrons of the world get a half a chance to poach customers with this half way step. The customers/factory owners of
this world get a chance to try out the software from the "other brand" without making a 100% jump/commitment. Maybe it might even become like a "cross roads of the world" situation where everything is interchangeable. And it might be more like the Integrated Circuits economy where having a "second source", and being able to be "pin for pin compatible" have real economic values. So the same applies to the Input Output racks and special function modules, if the LinuxPLC is able to work with Any/various brands
from the Allen-Bradleys and Omrons of the world. The Allen-Bradleys of the world have a very deep knowledge of all things "PLC", and also have the
Allen-Bradleys of the world have a great deal of "insider knowledge", which is a great positive for them and will always keep their software and
hardware at a premium level of "capabilities" in comparison to what anyone else can do. However they may find it in their own interests one day, (or they may not) to view to LinuxPLC source and they may suggest ways to overcome some obscure bugs, or some obscure improvement to the hardware
drivers to overcome potential problems with their hardware that we have never heard of, and will never see, but with those Allen-Bradley sourced
hints for improvements, the Allen-Bradley hardware may be able to perform with the "quality" that people expected when they purchased Allen-Bradley hardware for their LinuxPLC. If the Allen-Bradley hardware is not able to quite maintain the high expectation, people might be tempted to try Omron hardware for the LinuxPLC especially so if the Omron hardware did not need some "magical" tweaks to be made to perform better, or because Omron was willing to make some subtle or not so subtle hints to the LinuxPLC writers of the hardware part of the source code. Again please switch brands names
here in order to suit personal taste. Sometimes the different brands work to keep customers from straying from the brand, and in other markets with
different dynamics the different brands work to convert customers to them by using the "pin for pin compatible" strategy. Usually, somewhere in
here, someone says that the customer is the winner.

Of course, there would also be a LinuxPLC set of PLC instructions/op-codes, and,
(Here with tongue firmly in cheek)...
perhaps one day the Allen-Bradley RSLogix will allow a PLC model selection/choice of SLC503,4,5 _and_ LinuxPLC_v1,2,3,or 4.

Enough of the mights and maybes, and idle speculation. Again...
change the brand names to suit your favourite brands/ the brandnames are only for metaphorical/rhetorical/illustrative purposes/
have been changed to protect the innocent/
this is only a hypothetical/wishful/fictitious story.
Please choose whichever you think should apply.

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
J

Johan Bengtsson

>I have been imagining what an idealised PLC could be (now or in the
>future).
>Imagine a PLC which can be programmed/monitored by laptop with the
>commercial/off-the-shelf
>Allen-Bradley software like RSLogix or what ever AB software.
>Imagine the very same PLC being programmed by the next person who happens
>to like/has-been-trained-on the Omron programming software Syswin or
>whatever.
>Our LinuxPLC would simulate communications to-and-fro normally going into
>the
>RS232 socket on the Allen-Bradley PIC device, or the RS232 socket on the
>Hostlink.
<Replace all the brandname placeholder in the sentence above with Your
>favourite brand.

As well as being able to program without another computer or over the LAN or .... your choice..

>Imagine the LinuxPLC being as smart as we human beings are.
>The LinuxPLC can "eyeball" the ladder diagram of Any brand and be able to
>explain/evaluate the workings of the Ladder Logic diagram. And like us
>human beings, it will have difficulty with some of the wonderfully strange
>idiosyncrasies in some of the different brands.

Probably

>(This is where I have my stumbling block)
>Because I don't anticipate that we are clever enough to untangle this
>"tower of Babel", which we must if we are not to be limited to just the
>"lowest common denominator", then a less ambitious desire is for the
>LinuxPLC to just be able to be programmed/monitored by a laptop with the
>commercial Allen-Bradley software. The LinuxPLC gives all the anticipate
>responses to the commercial Allen-Bradley software. This means that the
>whole world of Scada software which expects to communicate to an PLC that
>speaks the Allen-Bradley language, will not notice any difference. This
>means that all the work that thousands of people have done to communicate
>to Allen-Bradley PLCs will immediately work with this LinuxPLC too. ie none
>of their work needs to be sacrificed for those people to have a try at
>using our LinuxPLC.

Or whatever....
I agree (eventually this will happen, but not as the first step)

>Maybe the ladder put into the LinuxPLC by the Allen-Bradley commercial
>software needs to be wiped away before another person can use his(her)
>Omron commercial software to download a new Ladder program into the
>LinuxPLC. Now the pre existing Scada packages will need to be set to use
>their Omron PLC drivers to communicate to the LinuxPLC.

That would be the easy part, but not really necesary to wipe it out (see below)

>Perhaps it may be possible to have two separate Ladder Diagrams within one
>LinuxPLC.
>For example, the baking oven was installed by Allen-Bradley type people who
>downloaded their Ladder into the LinuxPLC, but the material handling
>conveyors to and from the backing oven was installed by people who just
>could never understand the Allen-Bradley way of doing things but are
>experts at the Omron way of doing things.

I agree completely
That is what I and others have meant by allowing more than one logic solver process (as well as other controlling processes) to be run at the same time. The different processes can run ladder/fbd/whatever programs in the same or different languages, eventually

>Of course, there would also be a LinuxPLC set of PLC instructions/op-codes,
>and,
>(Here with tongue firmly in cheek)...
>perhaps one day the Allen-Bradley RSLogix will allow a PLC model
>selection/choice of SLC503,4,5 _and_ LinuxPLC_v1,2,3,or 4.

Or perhaps just IEC61131-3 will be the default
Puffin Linux Control logic solver languages
(along with some PID controllers and such)


/Johan Bengtsson

----------------------------------------
P&L, the Academy of Automation
Box 252, S-281 23 Hässleholm SWEDEN
Tel: +46 451 49 460, Fax: +46 451 89 833
E-mail: [email protected]
Internet: http://www.pol.se/
----------------------------------------


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Top