Hi Peter,

I know we can do SNMP (most Linux distros include some of this) but I haven't seen any IO oriented stuff, perhaps I'm missing semething. I've worked with SNMP for watching terminal concentrators once upon a time. I'd like not to have to extend an established protocol. BACNET is worth revisiting. I looked at it quite a while ago.
I really don't remember what turned me off. There's also that finding obscure Open protocols for our project wouldn't be nearly as useful to the whole automation community as opening some very prevalent ones. We could really use fewer instead of more. And we are going to have to support the top 5 (10, 20? ) somehow. The very best result would be for an existing, popular
protocol owner to take a shot at becoming a cross platform standard by simply removing the barriers. Some who are very close would have very little to lose and everything to gain.

Regards

cww
--
Free Tools!
Machine Automation Tools (LinuxPLC) Free, Truly Open & Publicly Owned
Industrial Automation Software For Linux. mat.sourceforge.net.
Day Job: Heartland Engineering, Automation & ATE for Automotive
Rebuilders.
Consultancy: Wide Open Technologies: Moving Business & Automation to
Linux.

 

Hi Fred

I'm glad you replied because this is where a common misunderstanding is. I don't need much help to produce GPL code for a driver and given
the information I need for a particular card, I can probably produce a GPL loader and load whatever closed firmware is needed to a card. And
as an _individual_ or for my company, I can probably even use it and be happy by simply agreeing to a clickthrough license. But the licensing I've seen so far does not let me then contribute the code to the MAT/LPLC project for everyone to use. I don't want to change the protocol, that would be silly if a standard is the object. I'm not asking for them to write the code. And I would very likely use any existing cards if priced within reason. All I want from them is the permission to do for LPLC what I can do as an individual or company. The problems are not technical, although I agree implementation might be non-trivial. The problem is that they want someone to sign a license for each use. Since I would have no control over who uses the LPLC and wouldn't require them to license it or it's drivers in any case, we have a problem. If they want LonTalk to become ubiquitous, and since
they don't seem too obsessed with collecting big bucks from every single user, it would seem that there should be a solution to the problem. And since popularizing the protocol would yield more benefit for LonWorks vendors of various ilk than it would for us, I reason that it would be in their interest to make it possible. So I asked them if there was some way around the difficulty. I don't see it as an unreasonable request if they really want people to use their protocol and are willing to sacrifice a little control to get there. The patent issues are entirely a different matter, I think, but they would discourage
commercial entities more than OSS as we aren't trying to make a buck. I really doubt that any of the protocol owners we are after has ever even considered that someone would want to do what we want to do and there is simply no provision in their licensing to allow it. I would simply like for them to seriously consider the question and say whether we can serve the public interest and support their protocol or not. If they agree to let us do it, I will make my best effort to find the resources.

Regards

cww

 

Hi Peter

That's why I asked them if we can't find a way. I don't see there being much of a need to avoid using an $8.00 chip. Their licenses don't accomodate how we would need to work and we have no single responsible party to execute license agreements anyway. What we could use is a exception to certain provisions for non-profit,
non-commercial use or explicit permission to use it the way we need to. I think that if they are willing to seriously consider it, we could work something out that is mutually agreeable. I would be willing to put together and submit any information that we can reasonably know at this time. It would certainly be an industry first and a notable event.


Regards

cww

 

A widely supported I/O protocol would be a great way toward an open controls industry, but it's hard to imagine that happening anytime soon. Everyone addresses the problem from some particular bias, ultimately fitting the protocol to whatever architecture they have in mind, but in so doing making it a mis-fit with other system types. An example of this is the register-based protocol that Curt has mentioned; this is OK for "traditional" PLC systems, but may make no sense for other systems which might prefer to see, for example, only symbolic names.

Another roadblock (all this IMHO of course) is the perceived need for binary protocols, typically for efficiency reasons. Obviously binary is the way to go for pushing information down a pipe using the smallest bit count, but then everyone has to buy into YEBP (yet another binary protocol), and it's going to be hard to argue why this new one is better than that old one. Besides bandwidth on the pipe, such binary protocols are "needed" due to the inherent limits of the CPUs at the nodes; in my opinion this is just a technological, temporary barrier which will fall in due time.

I think BACnet is a good example of a well worked out binary protocol, very much free and open (yes, you need to pay for the standard manual) yet ignored for the most part in the wider automation industry. Perhaps that's because it comes out of the lowly HVAC segment, doesn't necessarily directly target PLCs, brings along its own architecture model to which users will have to conform, ... I've wondered before if the $120 for the manual is a sufficient barrier to account for it not being used, which would be sad if true, but other widely used standards (e.g,. POSIX) must be similarly paid for, so I'm not sure that's the reason.

IMHO one way to an open I/O protocol is to be willing to forgo binary and instead be verbose and completely unobfuscated. CPUs will then (gasp) need to parse text, the pipe will be 90% fluff/10% data (or less), but it would be obvious to some MMI that I feel like attaching to the network what's what. Such a step would not be sufficient in itself, but I think it may be necessary.

Ken (who's glad to get through that without uttering the X word)

--
Ken Irving <[email protected]>

 

Jiri Baum:
> > By the same token as the I/O not being directly connected to the CPU,
> > neither need the MMI be. Indeed, since there's often (though not in the
> > case you presented) several MMI panels, it's unclear at which of them
> > it should be, anyway.

> > Once you untie the CPU from the I/O and MMI, it'll tend to migrate to
> > whatever remaining tie is strongest. My guess would be clean power, but
> > it could be anything (cooling, protection, network/external connections).

Michael Griffin:
> Most machines probably have only one MMI panel.

I guess that depends on the physical size of the machine - if it's big, then it needs several just because people can't read it at a distance.

> Even if there are several MMI displays, the actual MMI software could
> execute in the same box, (and probably on the same processor) as the PLC
> logic. The coupling of the control logic and display logic means the two
> need to work closely together. Extra screens and keyboard could be thin
> clients.

Yeah, but then all the screens and keyboards could be thin clients. What reason to couple them thus?

> I don't see that "clearn power" would dictate location. Putting the PLC
> CPU a couple of meters closer to the power supply is no real advantage. I
> don't see your other factors making any difference either.

Putting clean power cables into the same conduit as other stuff will quickly turn it into dirty power, so it's best to make them as short as possible. Anyway, like I said, it's just a guess - it could be anything.

> > > - With the PLC, I/O and most of the terminal blocks gone from the
> > > control panel, all that would be left in many cases is the disconnect
> > > and lock-out, power supplies, fusing, and the safety controller
> > > (which implements the safety interlocks).

> > Indeed, the safety aspect may be the greatest barrier to all this - as
> > long as it needs to be interposed between the fieldbus and the actual
> > device, integration of the bus into the device will remain
> > half-hearted.

> There is no technical problem here - this is already solved.

OK.

> > > Traditional PLC manufacturers may not have the I/O market.

> > Well, if you can prise it out of their fingers... Why do you think the
> > fieldbus standard turned out the way it did?

> If the PLC manufacturers aren't selling most of the I/O, then they won't
> control the market.

Ah, but that's a big if - right now do they control the market, and therefore sell most of the I/O.

> If the I/O is built into the actuator, then the shoe may be on the other
> foot, and any potential PLC maker may have to conform to the protocol the
> actuator offers.

Indeed. Again, something of an if.

> You may possibly see another way for the market to develop.

Well, you can read the cyberpunk dystopias as well as I can... We already
have AOL-Time-Warner.

> However, I think the above is at least a possible development. The
> significance of it is that it would force various companies who are
> selling complementary products to work together.

That would be good. It's the getting from here to there that I doubt, and then it not decaying into some other pathological situation.

Jiri
--
Jiri Baum <[email protected]> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools

 

>Most machines probably have only one MMI panel.

To quote Gerry Weinberg, "things are the way they are because they got that way," not necessarily because that's the way we'd do it if we were starting today with a clean slate.

It is possible that "most machines probably have only one MMI panel" because when they were designed, it was expedient/necessary to outfit them with a panel, and cost-effective to outfit them with a single dedicated panel (rather than, say, network communications for MMI). That doesn't necessarily imply that the same design decisions would get made today, given the availability of cheaper and more easily distributed components. If a panel can be remote, then several stations could have MMI access to the same machine; if a single panel can be simultaneously connected to - or runtime software-switchable between - multiple machines, then each station could have just one panel and access to all the machines they care about.

>Once you untie the CPU from the I/O and MMI, it'll tend to migrate to
>whatever remaining tie is strongest. My guess would be clean power, but
>it could be anything (cooling, protection, network/external connections).
>
>>I don't see that "clearn power" would dictate location. Putting the PLC
>>CPU a couple of meters closer to the power supply is no real advantage. I
>>don't see your other factors making any difference either.

Clean power is one of the major selling points for colocation facilities ('server farms'). People are willing to put their network servers in someone else's building because the building has clean uninterruptable power, a T-3 connection to the Internet, temperature control, fire suppression, and 24x7 security; I don't have any difficulty imagining people using similar criteria for placing their control processors at some small distance from the machines they control. (I have even less trouble imagining it in the current climate of concern about SCADA/automation security.)


Thinking-out-loud-ly yours,

Greg Goodman
Chiron Consulting

 

On March 9, 2002 01:54 am, Jiri Baum wrote:
<clip>
> Michael Griffin:
> > Most machines probably have only one MMI panel.
>
> I guess that depends on the physical size of the machine - if it's big,
> then it needs several just because people can't read it at a distance.
<clip>

Yes, but small, inexpensive PLCs are the largest part of the market (by unit sales, if not by value). These aren't typically used on very large, complex machines. If you have a small machine, you only need one MMI panel. There would be a substantial market for one (small) MMI per (small) PLC. I'm describing this sort of application since large expensive systems don't have any difficulty justifying networked I/O today.

Putting the PLC and MMI panel in one box would seem to have a lot of cost advantages if you don't have to pack the I/O in with it. You are sharing the package and power supply, and don't have to network the MMI and PLC together. You have one box instead of two separate ones to distribute and sell. If the PLC and MMI can run on the same processor, then the cost advantages are even greater.

Products like this already exist on the market, but I don't think they are selling that well. I suspect this is because it isn't economic to network low I/O counts.

> > I don't see that "clearn power" would dictate location. Putting the PLC
> > CPU a couple of meters closer to the power supply is no real advantage. I
> > don't see your other factors making any difference either.
>
> Putting clean power cables into the same conduit as other stuff will
> quickly turn it into dirty power, so it's best to make them as short as > possible. Anyway, like I said, it's just a guess - it could be anything.
<clip>

I would rather take noisy 24VDC power out to a PLC than take noisy I/O signals (especially networked I/O) back to it. You have a better chance of filtering simple DC power than signals. Most PLC power supplies are pretty good filters to begin with. I would recommend avoiding the noise in either case though.

> > If the I/O is built into the actuator, then the shoe may be on the other
> > foot, and any potential PLC maker may have to conform to the protocol the
> > actuator offers.
>
> Indeed. Again, something of an if.
<clip>

The point of the scenario wasn't to describe what necessarily *will* happen. I am not pretending to be a market analyst who can predict the future.

I am though pointing out what I think is a market need, and what the implications of it *could* be. I think that "openess" is more likely to be
driven by the needs of the end devices with PLCs being forced to follow than by any other way.

> > However, I think the above is at least a possible development. The
> > significance of it is that it would force various companies who are
> > selling complementary products to work together.
>
> That would be good. It's the getting from here to there that I doubt, and
> then it not decaying into some other pathological situation.
<clip>

Yes, well there are alternative ways this could develop. Companies like Festo and SMC and others could simply pick a bus they favour, with each
company picking a different one. This could end up with the actuator market becoming as fragmented as the PLC market. This would not be a good development.

Right now though, they are trying to support too many different networks, which means they can't afford to support them very well. Unlike the PLC
manufacturers, they have more to gain than they have to lose by seeing most of the current networks disappear.


************************
Michael Griffin
London, Ont. Canada
************************

 

> > Michael Griffin:
> > > Most machines probably have only one MMI panel.

Jiri Baum:
> > I guess that depends on the physical size of the machine - if it's big,
> > then it needs several just because people can't read it at a distance.

Michael Griffin:
> Yes, but small, inexpensive PLCs are the largest part of the market (by
> unit sales, if not by value).

True.

> These aren't typically used on very large, complex machines. If you have
> a small machine, you only need one MMI panel.

Large doesn't necessarily mean complex, but you're right - probably most machines only need one MMI panel.

> Putting the PLC and MMI panel in one box would seem to have a lot of cost
> advantages if you don't have to pack the I/O in with it.

Yes. (Indeed, even if you do pack the I/O in with it there'll still be a lot of cost advantages.)

> > > I don't see that "clearn power" would dictate location.
...
> I would rather take noisy 24VDC power out to a PLC than take noisy I/O
> signals (especially networked I/O) back to it.

True. Anyway, like I originally wrote, it could be anything - this was just a first guess.

> > > If the I/O is built into the actuator, then the shoe may be on the
> > > other foot, and any potential PLC maker may have to conform to the
> > > protocol the actuator offers.


> > Indeed. Again, something of an if.

> The point of the scenario wasn't to describe what necessarily *will*
> happen. I am not pretending to be a market analyst who can predict the
> future.

OK (though most market analysts probably can't predict it either).


Jiri
--
Jiri Baum <[email protected]> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools

 

Peter Whalley:
> Next choice would be BACnet (ANSI/ASHRAE Standard 135-1995).
...
> As far as I can see, the only cost is for the developer to purchase a
> copy of the standard when writing the code.
...
> I have a copy of the standard if you need any specific information.

So, since this is a sunk cost for you, can we look forward to your contribution?


It should probably go in io/bacnet in the CVS.

Jiri
--
Jiri Baum <[email protected]> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools