Linux longevity (was MS 'Monopoly'?)

J

Johan Bengtsson

What a lot of people are trying to say is that if you buy a PLC from someone and use it. This someone then publishes the source code to whatever internal functions there is inside the PLC would that:

- Lower the value of your PLC?
- Rise the value of your PLC?
- Neither

- Make it harder to get support from the one you bought it from?
- Make it easier to get support from the one you bought it from?
- Neither

- Make it harder to get support from someone else?
- Make it easier to get support from someone else?
- Neither

Make any other difference to you as end user of the PLC?

What would the difference be if you from the start got the source?

What would the difference be if you knew it was developed as OSS?

What would the difference between having the source, developed as OSS with GNU licencing vs not having the source be if the company you bought it from discontinues the product, or no longer exists?

Have I missed any important questions?


I will now try to put answers to these questions as I see them
I realize my answers will not be the same as everybody else but anyway:

value: it would at least not be lower, ie it would rise or not change

support from vendor: probably no change, at least not harder

support from someone else: since noone else really could support you if the source isn't published this will be easier by a lot

Would it make any difference?
As long as everything is working: no
A hardware failure: not much change probably, you will need to replace the broken hardware with a new piece. For a PLC this will mean the same thing as all other PLC:s, and for a PC based control this can actually be easier if you are unable to find an exact match for the old hardware since it would be easier to get support.

If I got the source from start?
Well it would mean that I from the start got the source and the above would apply from start

If I knew it was developed as OSS?
Little difference, If I knew more about the people in the project I could perhaps know if they are good programmers or not and that could of course mean a lot about expected quality but otherwise little difference.

Gnu vs closed
I can't be locked in

/Johan Bengtsson

----------------------------------------
P&L, Innovation in training
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/
----------------------------------------
 
Bob Peterson:
> At least with a name brand PLC the end user can always (at least for the
> forseeable future) find someone with the expertise to make the changes he
> wants, usually within his own plant. With an "open" Linux based system,
> the end user is screwed, unless he is willing to pay through the nose to
> have the OEM make the changes for him.

I find this argument strange, almost backwards from common sense.

With a name brand PLC, the only way to get changes made is through the manufacturer/OEM, or else by opening the box and voiding the warranty. With a true open source system, anyone can make changes, and therefore the OEMs will compete on price, service and quality rather than lock-in.

> How many people can add a time delay to a typical PLC program?

The LinuxPLC will normally be programmed in one of the ``user languages''. Currently there's a choice of two - a simple IL (mnemonic) language and a PLC5 emulator - but we hope to get others.

Specialized code may be written in C, but then again most current PLCs allow specialized code to be written in C, so that's no different.

The main point of having the source isn't to change it (though you can), it's to guard against lock-in. With the source in your hand, nobody can
seriously lock you in, because you can always take your source and go next door.


Jiri
--
Jiri Baum <[email protected]>
http://www.csse.monash.edu.au/~jiribvisit the MAT LinuxPLC project at http://mat.sourceforge.net
 
L
Interesting to note that the US is looking at changing depreciation allowances for high tech capital items including PC's to allow either
treating them like expense items rather than capital items or shorten the depreciation period to 3 years or less. That helps from an economic
standpoint for companies to begin looking at more frequent upgrades, but it is also incumbent on automation professionals to identify projects with
shorter paybacks and plan their projects for maximum reusability when inevitable system upgrades are forced upon users. I think this should lead some manufacturers to apply more strategic planning to their automation needs. That is about as much as I can devine from my crystal ball. ;)

Lou Heavner
 
R

Ranjan Acharya

I agree with an important point raised by Richard Higginbotham on the downside of proprietary control architectures. I have used TI505 for quite some time too. The TI555, for example, was once a top-notch PLC and able to compete with anything else around. After Siemens bought TI's PLC line, they (I think) assumed that they could cajole customers to switch to S5 and then S7 by a two-pronged attach (1) reduce investment in new features in the TI505 line and (2) raise the prices of the TI505 line. I note now that
Siemens have also started to raise prices on the S5 line. I have no idea if this is fact, it is only personal surmise. The fact that the TI505 line has only a few pages in the SIMATIC catalogue leads me to believe that it really
is being marginalised. APT is another story all together, a quite good IEC 61131.3 precursor but now an antiquated DOS-based programming tool.

Unfortunately for Siemens (I think) many TI505 users may have interpreted this as a chance to look at other PLC vendors. I am not privy to sales figures, so I don't know if this got Siemens in trouble.

Having used the S7-400 -- which is a top-of-the-line "non-linear" PLC I can see that Siemens had reason to be very confident in their product. However, the S7-400 is more difficult to use than a SLC or ControlLogix processor and expensive.

This is a point that the LPLC folks have to exploit. They have to make us believe that their open product will have an incredibly long life cycle because it will be supported no matter what. I think that commercial realities may kill them here. I do not see, for the time being at least, a large PLC OEM offering a new line-up of LPLCs with no proprietary code.

We only need to look at what happened to two IEC standards -- IEC 61131.3 and IEC 61158. IEC 61131.3 was supposed to usher in the era of open PLCs where code for any application could be ported from one vendor's PLC to another with no regard to the underlying hardware. Instead of an end-user's standard, it is now a manufacturer's standard where code cannot be ported. The early promises of function block houses -- companies that wrote generic code for any PLC -- has vapourised. IEC 61158 is an even bigger joke.
Instead of a new standard fieldbus -- that would make things easier for the LPLC folks too -- we have an eight-headed hydra. When the standard came out, I fell off my seat laughing. The manufacturer's lobby in each voting country got their way, not the user's lobby.

No matter what, it is all about cold hard cash.

I do not think that LPLC will change that.

RJ

P.S. I have been caught out by no vendor support in closed architecture PLCs too
 
R

Ranjan Acharya

From CWW
&lt;clip>
For me it's all about engineering. I am a tool maker. You wish to be a tool
user. No problem.
...
In our case, many people, myself included, could help you out. This is
another Red Herring. Illogical, if you understand what Open Source is about.
...
There is no need to rely on a few harried individuals at a company with
echelons of message takers who seek to delay you until it's someone else's
shift.
...
That's your way of doing business, I am more consultative, people ask me
what the best solution is. There's certainly room for both although I
find your way to be much more difficult.
&lt;/clip>

Like most Systems Integrators, we are "tool makers who use other people's tools". The other tools are SCADA packages, DCSs, PLCs, HMIs and so on. We are not just "tool users" per se.

Does your personal offer of helping / support extend to a toll-free number that works 24/7 every day of the year anywhere in the world? This is my point about commercial support. It might cost a lot, but it (sort of) works.

I do not think it is entirely fair to gang up on the technical support people at A-B or Siemens in that manner. The reason we have to go through
the first level of "dumb questions" is that so many users 'phone in with "dumb questions" themselves. That will be no different for whatever support model you choose for your Open PLC. I think that you will get equally tired
of the "dumb questions" and put up some kind of firewall. Also, from my point of view I have the e-mail addresses and telephone numbers of people
who provide true technical support. They know I only contact them with real questions.

As far as "my way of doing business", I consult too. But at the end of the day most of my customers have standards set by a head office in Frankfurt or Sydney and they do not have the choice to go off and use another brand of PLC. The immediate customer and I can rant all we want about how bad the XYZ brand is, but we still have to use it. That does not mean we do not have a chance to change things, especially with smaller clients. They are the ones who might get an LPLC solution from us one day.

RJ
 
M

Michael Griffin

At 08:01 13/07/01 -0400, Ranjan Acharya wrote:
&lt;clip>
>This is a point that the LPLC folks have to exploit. They have to make us
>believe that their open product will have an incredibly long life cycle
>because it will be supported no matter what. I think that commercial
>realities may kill them here. I do not see, for the time being at least, a
>large PLC OEM offering a new line-up of LPLCs with no proprietary code.

I could however imagine several small PLC OEMs offering such a product, in hopes of becoming bigger OEMs. The larger PLC manufacturers
probably wouldn't because they are too interested in locking in their existing customer base. The smaller ones though could stand a chance to gain
if they could turn the market upside down and take business away from the larger ones. The more companies which offered such a product, the lower the risk would be for a customer picking any particular one of them. Time invested in learning, training, and in actual PLC programs could be transferred to different compatable brands.

I can also see a requirement for something like an LPLC among certain machine OEMs who produce standard equipment. I know of several
companies who have created their own proprietary soft logic systems for use in their own equipment. It is quite possible that several years from now, some of us may have an LPLC in our plants and not even be aware of it.


>We only need to look at what happened to two IEC standards -- IEC 61131.3
>and IEC 61158. IEC 61131.3 was supposed to usher in the era of open PLCs
>where code for any application could be ported from one vendor's PLC to
>another with no regard to the underlying hardware. Instead of an end-user's
>standard, it is now a manufacturer's standard where code cannot be ported.
>The early promises of function block houses -- companies that wrote generic
>code for any PLC -- has vapourised.
&lt;clip>

Yet if the same firmware (the LPLC) were offered on different brands, the PLC programs could be transfered and reused. There wouldn't be a question of "how standard" something was, it would *be* the same from a software point of view.

I could see the PLC industry splitting into three parts. One part would be the CPU + local I/O + specialised modules. The second part would be networked I/O (e.g. Beckhoff, Wago). The third part would be advanced software development tools (not GPL liscenced) offering something better than the standard "free" programming software to people who are full time programmers.
There is no reason why a single company couldn't offer all three parts, but they would still be viewed as three separate functions. However, a broader market would allow specialisation to take place where there was a
demand for it.

At this point of course, this is all hypothetical. The LPLC (or MAT) doesn't exist yet. It is at the stage where a small number of people are working on it. No, they're not an IEC committe where everybody's opinion has to be taken into account, which is probably a good thing when you consider the fate of the IEC standards mentioned above. Too many cooks will spoil the broth, as the saying goes.

However, while I can understand, and perhaps forgive the excessive "enthusiasm" of some of those who are directly working on this project, I am to say the least puzzled by how heated some of the debate has become on both
sides. (I am not referring to Mr. Acharya here). There is no reason why everyone cannot conduct this debate like gentlemen (and ladies). There is as much fault to be found on one side of the question as the other, so please let's not hear from anyone protesting their innocence.
Whilst I am in my pulpit here, could I also ask that the obscure American political analogies be done away with? Those of us who are not Americans will often have no idea what you are talking about, while no doubt half of those of you who are Americans will feel slighted by what was said.


**********************
Michael Griffin
London, Ont. Canada
**********************
 
We boast when someone offers of 24hr/7days support. Don't you think that the reason for support is basically:
a.. Either the product does not do what it is supposed to do.
b.. There are large number of failures in the product.
c.. There is insufficient documentation for proper use of the product.
The same overhead charged by the vendor in maintaining a 24/7 support could fetch you spare modules.

There is always a possibility that some user does not possess the necessary skills, but this can be overcome by having proper manpower and training.

And with all the 24/7 support, when a professional gets in a jam over the first issue i.e. the product does not do what it is supposed to do, believe me you find yourself quite lonely with the problem. The vendor promises to call you back or the correct personnel is not available or
points out at some fault at your end.

I am not denying the role of support, it is definitely critical and helpful at times, but a solid product should give you the same results.
With open source, a number of professionals in the website (and this is the reason for the list to be popular and may gain ground from old
stalwarts like ISA) respond to your queries faster than 24/7 support, and you get real solutions and help and not just company propoganda!

case: We had a very long program on a popular PLC. Three pumps were to start one after the other with 40 second intervals. two pumps starting
at a time would cause the power to dip and cause trips and further problems. the logic was correct and also confirmed by the PLC vendors
representative. Bit for pump 1 on, logic and a timer. End of timer, logic and 2nd pump on. Another timer and same sequence. But two pumps would start at a time. Finally we concluded that somehow the "Scan time of the program affected the way the program was working, where the logic was taking values from the previous scan and making two pumps start together." We developed a workaround this problem. And the system worked. But so much time was wasted!

Believe in open source, you will see your troubles vanish.

Anand
 
C
Ranjan Acharya wrote:
>
> &lt;clip>
> >From CWW
>
> For me it's all about engineering. I am a tool maker. You wish to be a tool
> user. No problem.
> ...
> In our case, many people, myself included, could help you out. This is
> another Red Herring. Illogical, if you understand what Open Source is about.
> ...
> There is no need to rely on a few harried individuals at a company with
> echelons of message takers who seek to delay you until it's someone else's
> shift.
> ...
> That's your way of doing business, I am more consultative, people ask me
> what the best solution is. There's certainly room for both although I
> find your way to be much more difficult.
> &lt;/clip>
>
> Like most Systems Integrators, we are "tool makers who use other people's
> tools". The other tools are SCADA packages, DCSs, PLCs, HMIs and so on. We
> are not just "tool users" per se.

I'm sure you can see that LPLC would be great for integrators to use as their higher level of expertise would let them do things not even remotely possible with a system that has the hood welded shut. This is perhaps the most exciting part of the project. This is the biggie for me personally as I get many requests for things that would be easy to do but simply aren't possible with existing products. I could say yes much more often and the guy with the most yesses gets the business.

> Does your personal offer of helping / support extend to a toll-free number
> that works 24/7 every day of the year anywhere in the world? This is my
> point about commercial support. It might cost a lot, but it (sort of)
> works.

I haven't used very much commercial suppport. It hasn't been very useful and when I have a problem, it's usually a problem for them also. I hate having to do it as it takes too long to get to someone who can actually help and the lower echelons like to run you through hoops.

We wil be primarily supported via the lists, although there's no reason someone couldn't make money by providing "commercial" support. A lot of
the more complex OSS products have companies that specialize in support.

Asking everyone in the world who is connected with the project with one email message is more efficient and cheaper in time and money. I much
prefer this model as I seldom feel I have time to converse with low level folks armed with a list of questions.

> I do not think it is entirely fair to gang up on the technical support
> people at A-B or Siemens in that manner. The reason we have to go through
> the first level of "dumb questions" is that so many users 'phone in with
> "dumb questions" themselves. That will be no different for whatever support
> model you choose for your Open PLC. I think that you will get equally tired
> of the "dumb questions" and put up some kind of firewall. Also, from my
> point of view I have the e-mail addresses and telephone numbers of people
> who provide true technical support. They know I only contact them with real
> questions.

> As far as "my way of doing business", I consult too. But at the end of the
> day most of my customers have standards set by a head office in Frankfurt or
> Sydney and they do not have the choice to go off and use another brand of
> PLC. The immediate customer and I can rant all we want about how bad the
> XYZ brand is, but we still have to use it. That does not mean we do not
> have a chance to change things, especially with smaller clients. They are
> the ones who might get an LPLC solution from us one day.

Our sector has little automation to start with. This is good and bad. We can sell solutions in our core competancy instead of having to conform to preconcieved notions. But, it is crucial that you reuse as much as possible and don't propose more than is wanted or needed. We are mostly
machine builders and cell integrators. LPLC would be ideal in this cost sensitive market. Much better bottom line. Our customers turn purple at
the mention of $1200.00 serial cards and $150.00 connectors. Telling them to throw away equipment to get compatibility makes the meetings very
short. Commercial stuff doesn't fit very well at all as it costs too much and integrates very poorly. They take the approach, "First replace
everything with our stuff and then buy a bunch more".

Of course all sectors are a little like that.

Regards

cww
 
We at Automation are suffering the ills similar to the L vs M$ issues. Our Vendors have spent a lot on research and gone through same cycles et-al
and please read Intech May issue where the yada...yada.. stuff from Curt Woullet is very true and inspiring. This multiplicity of same research and other issues not directly benefitting
the customer in anyway results in cost to the vendor. Next their source is closed and so only a specialized few can touch that and change that and which is verycostly and also error prone. if these group of people are not in touch with the latest technologies, then they will work in a direction which is not in the upcoming trend inthe maket and so much more money is wasted. This is again cost to the vendor.

All these costs that you are unaware of is being spent by you.

With open source and the model of Linux, you have an open source so bug fixing is faster and you do not have to worry about employee turnout. the
free development (i mean freedom here) ensures that no one is working in a misguided vision of an individual and so the direction, though unclear at the moment, due to the numbers driving it, moves in the right direction.

In the case of automation, standards will have to be followed in addition to the developments etc. Thus any open source in automation has to do more. But you will see more coming out of the linuxPLC.

I am writing a charactiser algorithm for Linux PLC which with the help of good programmers might get coded later on. Now with people driving such open source projects, the blocks like charactiser, totaliser, rate of change that are absent in most PLC's of this day, will be available in a PLC. This logic can be used by a closed vendor too! Which is also necessary to keep the market on its toes. At the end of the second or third issue, you may see conventional vendors emulating the tools in LinuxPLC.

We may also come up with better means of achieving redundancy and even better and true TMR designs than conventional vendors at a later stage in the project.

Believe in Open Source, You will see your troubles vanish.

Anand
 
Ranjan:
> The TI555, for example, was once a top-notch PLC and able to compete with
> anything else around. After Siemens bought TI's PLC line,
...
> This is a point that the LPLC folks have to exploit. They have to make
> us believe that their open product will have an incredibly long life
> cycle because it will be supported no matter what.

This is where the radically different support model becomes an asset. With single-sourced products, you never know when the company will decide to sell (as above), ditch or upgrade the product line. It is a decision taken by a small group of people in some strategy meeting (or just one person), which you can't affect nor really predict. It could happen tomorrow.

With open source, your support is spread among hundreds or thousands developers and fellow users. If you feel comfortable with the level of
support at the time you are selecting the product, you can feel confident that it will remain similar throughout the life of the project.

Even if all the developers dropped out at the same time (say, if we had a conference and got poisoned/bombed/legionnaires' disease), new developers would come forth either from the ranks of the users, or from elsewhere at the concerted demand of the users.

Jiri
--
Jiri Baum <[email protected]>
http://www.csse.monash.edu.au/~jiribvisit the MAT LinuxPLC project at http://mat.sourceforge.net
 
R

Richard Higginbotham

> The fact that the TI505 line has
>only a few pages in the SIMATIC catalogue leads me to believe that it
really
>is being marginalised. APT is another story all together, a quite good IEC
>61131.3 precursor but now an antiquated DOS-based programming tool.

Not antiquated if your factory is full of 505 stuff. Not to mention in many respects it is *still* ahead of other other major offerings, including S7. Its just that people don't really know about it, because Siemens isn't interested in puting a new coat of paint on it, or supporting all of its features. Its far closer to a *real* programming language, so it does takes longer to learn. A non programmer who sees it doesn't necessarily see the power thats there. For example, APT is an object oriented language. You may use devices (which support inheritance, etc.) but you may not know its possible for you to make your own. They dropped the tools to do so after 1.6, but have included them again in the latest Release 1.9A. They still provide no instruction to do so, and its not a pain free process to say the lease. Theres nothing stopping APT from being updated, except Siemens. I'm sure there are plenty of companies/groups that would love to take it off Siemens hands, but Siemens won't do that either. They will make more money with one line of PLCs than they will with two. That just business. Everytime 505 users see Siemens buy out another company to get marketshare, we know whats comming.

>Having used the S7-400 -- which is a top-of-the-line "non-linear" PLC I can
>see that Siemens had reason to be very confident in their product.
However,
>the S7-400 is more difficult to use than a SLC or ControlLogix processor
and
>expensive.

Nice PLC in some respects, bad programming packages productivity wise. Typical Harder is Better, philosophy.

>This is a point that the LPLC folks have to exploit. They have to make us
>believe that their open product will have an incredibly long life cycle
>because it will be supported no matter what. I think that commercial
>realities may kill them here. I do not see, for the time being at least, a
>large PLC OEM offering a new line-up of LPLCs with no proprietary code.

No one is going to do that (guarentee support forever). The thing that they should be able to say is, "we're not in the *business* of selling you hardware, so theres no need for us to do everything we can to force you to replace your old adequate equipent with our brand new model (old clunker with a new paint job)".


>We only need to look at what happened to two IEC standards -- IEC 61131.3
>and IEC 61158. IEC 61131.3 was supposed to usher in the era of open PLCs
>where code for any application could be ported from one vendor's PLC to
>another with no regard to the underlying hardware. Instead of an
end-user's
>No matter what, it is all about cold hard cash.

No mystery there, who sits on those boards? Are the major PLC vendors represented there, like I don't know Siemens. Its in their interest to make
sure that thier products are incompatable. They're not going to let you have a package you can also use to program AB stuff (at least until they buy them out, even then they'd rather have you replace all your current stuff). Your asking them to do things that will hurt their business (in thier eyes at least). Then if AB comes out with a better PLC hardware wise, you'll just switch at no cost to yourself. The more painful it is, the less likely you are to switch.

>I do not think that LPLC will change that.

Your right, it won't. The major vendors know how to make money (er. perhaps not as well lately ;) ). They don't make it on software, they make it on selling you hardware. LPLC won't force Siemens or AB to make their packages
open. They can only offer an open alternative... Perhaps a programming package that supports Siemens hardware in addition to the LPLC. Thats a lot of work to be sure (as much or more than an LPLC itself) and I'm not sure about the legal issues there, but its not implausable.

Don't get me wrong, Siemens has/have had a lot of good people working for them. I know and have worked with quite a few. But the good intentions in Johnson City are no match for the corporate monolith in Germany. Theres no doubt in my mind how good the 505 line can be, nor that it will never be allowed to happen. Rumors abound that the Johnson City site (505 line) will be closing down soon. A lot of the knowledge is about to be lost (wheres Jim Pinto ;) ), which would be a bad thing if they *really* wanted to you buy 505 line products. Instead of just saying, "its gone, buy our S7 or else", their cutting personel and support so that you'll be disatisfied with the 505 line, but not necessarily through out the idea of adding S7s (saying the same thing with a smile on thier face and a friendly handshake). Yet, they aren't making the upgrade path for existing users very easy from what I've heard. All my rumors come first hand btw ;).

Looking foward, I'd rather through my support in with a project that will give me options even if company X doesn't really care to support me. The more near painless options you as a customer have, the better. If it were Siemens who were coming out with an open source project, I would be just as enthusiastic. I don't care who makes the hardware, or even the software. The important point is that I have choices. If I like APT and want to put an APT IDE into LPLC, theres nothing stopping me, and I'll have all the information I need. If enough people like the idea, they'll support those efforts.

Richard Higginbotham
 
R

Richard Higginbotham

Ranjan:
>> The TI555, for example, was once a top-notch PLC and able to compete with
>> anything else around. After Siemens bought TI's PLC line,
>...
>> This is a point that the LPLC folks have to exploit. They have to make
>> us believe that their open product will have an incredibly long life
>> cycle because it will be supported no matter what.

Jiri:
>This is where the radically different support model becomes an asset. With
>single-sourced products, you never know when the company will decide to
>sell (as above), ditch or upgrade the product line. It is a decision taken
>by a small group of people in some strategy meeting (or just one person),
>which you can't affect nor really predict. It could happen tomorrow.

>With open source, your support is spread among hundreds or thousands
>developers and fellow users. If you feel comfortable with the level of
>support at the time you are selecting the product, you can feel confident
>that it will remain similar throughout the life of the project.

>Even if all the developers dropped out at the same time (say, if we had a
>conference and got poisoned/bombed/legionnaires' disease), new developers
>would come forth either from the ranks of the users, or from elsewhere at
>the concerted demand of the users.

There is a problem with support (not without a solution though). I won't say its not different with a large vendor, even though the perception may be that its different. Time consious support can be very important, as well as *dumb* support. You, as a developer, probably don't want anyone to call you at 3:00 in morning on a weekly basis because they just don't know how to
program, "it says press the any key, I can't find the any key", or theres a problem in someone elses code, etc (I wouldn't want it anyway). There is also the case when your on vacation, etc and no one else really knows your code. In the time it takes them to fix, compile and test everything, it has cost several million at the customers site because start up has been delayed
(even a day) or a critical process is down. Where I'm at now, 15 minutes can cost over 15 million.

Most of the simple support problems could be solved just by having a place for users to congregate and ask questions. A place frequented by the developers and other knowledable persons. Whether its completely free or not is immaterial.

The "what about bugs" part can be satisified by having a clear versioning systems. A version that may not have all the latest features but has been used and is considered stable is available, as well as the latest version, which may be completely stable it just hasn't been used as much (for those who like the bleeding edge). Also, some automated testing will help (I would consider critical) for the bugs that spring up because package A breaks package B when feature C is used. In a industry of our size its very
possible you could be trying out a new combination of events simply because theres not a user base large enough to catch everything with the beta version.

Past that, I've no doubt that if people are willing to pay money for 24 hour "wheres that smoke coming from" support, someone will accomodate them. I'm sure it will happen. I understand the need, even if its something I don't
really want to do. If theres money to be made at it, you can pretty much be sure that the service will be offered. To my knowledge, there is nothing about LPLC that will prevent that, in fact, I expect the model will help that process tremendously.

Richard Higginbotham
 
G

Gilles Allard

I like APT and I would support those efforts.
The "device" portion of APT would not be very difficult to duplicate but the SFC (Grafcet) would be much more difficult to do.
Gilles


>Looking foward, I'd rather through my support in with a project that will
>give me options even if company X doesn't really care to support me. The
>more near painless options you as a customer have, the better. If it were
>Siemens who were coming out with an open source project, I would be just
>as enthusiastic. I don't care who makes the hardware, or even the
>software.
>The important point is that I have choices. If I like APT and want to
>put an APT IDE into LPLC, theres nothing stopping me, and I'll have all
>the information I need. If enough people like the idea, they'll support
>those efforts.
 
R

Richard Higginbotham

Thank you Gilles,
Its always nice to meet another APT enthusiast.

If your compiling into C code to be later compiled (by a standard PC compiler) and added to the LPLC, it really wouldn't be that hard (not hard doens't mean not time consuming I'm afraid). The hard part of APT is the compiler itself. If you use a object oriented compiler g++ (I think its called in Linux) it really shouldn't be a problem. You'd spend more time on
the programming/debug editors than the language structures. Devices map quite nicely into classes. SFC structure isn't that bad either. Its just a class type (step, transition, etc.) with some extra code attached (that depends on whats actually in the step or transition).

The next step after that is use to a high level language like Python to take an APT program and translate it into LPLC code in your new environment (IDE), mostly a copy and paste job. It will take a little time but shouldn't be especially difficult.

Richard Higginbotham
 
R

Ranjan Acharya

I like the discussion on APT ... I have not really seen much else that equals the power of APT's SFCs. APT for Linux ... a great reason to switch for many TI505 users especially if you throw in an integrated ladder editor (TISOFT or SoftShop style) too.

If APT for Linux supported the TI505 hardware as well as the generic Linux hardware it would be a great application.

Probably a little bit off topic though.

RJ
 
> >This is a point that the LPLC folks have to exploit. They have to make
> >us believe that their open product will have an incredibly long life
> >cycle because it will be supported no matter what.

Richard Higginbotham:
> No one is going to do that (guarentee support forever).

We can come pretty close to that, though... As you write in your other post:

> I've no doubt that if people are willing to pay money for 24 hour
> "wheres that smoke coming from" support, someone will accomodate
> them. I'm sure it will happen.

The same argument applies to any kind of support, not just 24/7, with the added advantage that the support will be provided on a competitive basis.

> If I like APT and want to put an APT IDE into LPLC, theres nothing
> stopping me, and I'll have all the information I need.

Cool! It should probably go into the logic/apt directory in the CVS.


Jiri
--
Jiri Baum <[email protected]>
http://www.csse.monash.edu.au/~jiribvisit the MAT LinuxPLC project at http://mat.sourceforge.net
 
C
Hi Gilles, Richard,

For what it's worth I would also like alternative front ends for LPLC. The more the merrier. I would like to see a state languge similar to GE's State Logic. I have no allegiance to or vesting in RLL or the other common offerings and the right language can sometimes make a huge
difference for certain tasks. A 4GL for automation would be great.

Regards

cww
 
Top