May someone tell me where can i find a comprenhensive comparison between Profibus and Lonwork Networks? including profibus and lontalk protocol.

I'm working on a selection of the most reliable protocol and network to use in a fielbus enviroment substation.

Thanks in advance...

Jose Calzadilla

 

You can find some information here http://ourworld.cs.com/rahulsebos/
and here
http://www.synergetic.com/education/index.html

 

I am not sure you can find a good side by side comparison of LonWorks vs Profibus. As a side note I would be cautious of anyone who does try to give you a comparison. Someone might have experience in one or the other but usually not both. Just as I have a lot of experience in LonWorks, I would never try to give you a comparison since I haven't worked with Profibus. You need to understand the bias of the individual or company that is providing you with information.

You can find an overview of LonWorks on my Website (shown below). You will likely see some who will proclaim that LonWorks isn't suited for industrial applications but that is a false statement. I have worked with and seen many industrial applications using LonWorks. Granted, Echelon as a company focuses its attention on building automation and home automation as markets but that does not preclude its use in industrial applications. The one area of industrial controls where LonWorks falls short is in the very fast response times or where a message must be delivered in repeatedly in a fixed amount of time.

Some examples of actual industrial applications can be found at Echelon's website - http://www.echelon.com/solutions/industrial/segments.htm

If you have specific questions about LonWorks, feel free to email me and I'll do my best to answer.

Regards,

Fred Graham
Graham Controls Consulting
http://www.grahamcontrols.com
770.330.9123

 

I know of no direct comparison between Profibus and LONtalk protocols. Both are standards for different markets. Look at http://www.profibus.org and
http://www.echelon.com.

Profibus is used as a master/slave protocol, even though it does have token passing capability.

LONtalk is usually used in master/slave mode as well since in native form it is a peer-to-peer CSMA/CA protocol. Collision avoidance is OK, but not as rapid as master/slave.

Personally, I prefer Foundation Fieldbus that is based on an international standard. See http://www.fieldbus.org

Dick Caro

 

Hello Jose,

I've used the comparison tables from Synergetic on similar research. It is a good start:

http://www.synergetic.com/compare.htm

Hope this helps,
Daniel Chartier

 

I do not know if you could find information on http://www.profibus.com or http://www.echelon.com.
As far as I know the main difference between them is that PROFIBUS is a Master-Slave protocol while LONworks is not. This means that traffic network
load could be less in a LONWorks network.

If you plan to take information from the network just for showing it PROFIBUS would be more suitable (I guess also cheaper). If devices need data from other devices this fits better to LONworks.

Hope I can help you.

You can contact me (also on Spanish) on [email protected]

 

Hi all,

On May 30, 2003, Dick Caro wrote:
>I know of no direct comparison between Profibus and LONtalk protocols.

A comparison at media level is available at
http://www.steinhoff-automation.com/fb_comp.htm

> Both are standards for different markets.

PROFIBUS is an open international standard and is free from any propriatory rights. The PROFIBUS standard doesn't cover a special market.

The LONTALK standard is a 'standard' for the market of ECHELON

> Look at http://www.profibus.org and http://www.echelon.com.
>
>Profibus is used as a master/slave protocol,

PROFIBUS FMS is a master/ master and master/slave protocol. This functionality is also available fo PROVIBUS-DP by the DPV1 and DPV2 protocol.

>even though it does have token passing capability.

PROFIBUS-DP is using a hybrid token passing protocol and allows master/master, master/slave and slave/slave (DPV2) communication.

>LONtalk is usually used in master/slave mode as well since in native form it
>is a peer-to-peer CSMA/CA protocol. Collision avoidance is OK, but not as
>rapid as master/slave.
>
>Personally, I prefer Foundation Fieldbus that is based on an international
>standard. See http://www.fieldbus.org

Yes ... and they share the same international standard as PROFIBUS. However, I prefer a field bus which fits to the requirements of my application ...

Best Regards

Armin Steinhoff

 

Dick,

While I respect your opinion and expertise in the industrial automation market, your comments illustrate something I said in an earlier post. Be aware of who is giving you information and understand their bias or knowledge before excepting a statement as fact.

I acknowledge your expertise in the industrial market but your comments regarding LonWorks are either misleading or wrong. In the spirit of full disclosure, I will say that I worked for Echelon for 8 years as a Field Applications Engineer. I don't currently work for Echelon but I do consulting in the LonWorks community. I do have a vested interest in LonWorks technology but I hope you would agree that my expertise in LonWorks far exceeds yours. I would like to address your comments below :

"I know of no direct comparison between Profibus and LONtalk protocols. Both are standards for different markets."

Actually LonWorks wasn't developed for one specific market in mind. When you look at control networks, regardless of the market, there are a lot of commonalities. Echelon developed the LonTalk protocol to address a wide range of needs. LonWorks is a capable technology of addressing many industrial needs. The fact that Echelon doesn't pursue that market is more due to the vast number of competitors and size of market, not lack of capability. As I have said earlier there are aspects of industrial control where LonWorks does not fit. But you can also find a good number of real industrial applications where LonWorks is being used today.

"LONtalk is usually used in master/slave mode as well since in native form it is a peer-to-peer CSMA/CA protocol."

This statement is partially incorrect - LonTalk is NOT usually used in master/slave mode. The protocol itself is inherently peer-to-peer. You can develop applications that force the protocol to look like a master/slave network, just like you could develop IP applications that mimic master/slave over IP. If you look at the vast majority of LonWorks products available, almost 100% of them are peer-to-peer. The only master/slave LonWorks networks that I know of are proprietary implementations from a single company. The open, interoperable market is entirely peer-to-peer.

"Collision avoidance is OK, but not as rapid as master/slave."

I am not a fan of blanket statements like this because the true answer depends on so many factors. While this may be true in very small networks, what happens as the number of nodes expand? The more nodes a master has to poll, the longer the scan or cycle time. As the network grows in size I would argue that peer-to-peer and CSMA/CA (carrier sense multiple access/ with Collision Avoidance) could be faster. I say "could" because again without knowing the application and network configuration it is impossible to say with certainty. But if all nodes are reporting only on exception instead of a master having to poll each and every one, then its reasonable to assume a faster response time if the network is fairly large.

I think it is only fair that if you make statements, you acknowledge when they are opinion versus fact or at least not make blanket statements without stating the underlying assumptions.

Regards,

Fred Graham

 

Hi Fred

I find your use of "Open" to be more misleading than any of Mr. Caro's remarks. The interoperable part is subjective as well. Every proprietary protocol is interoperable with licensees.

Regards

cww

 

Dear me Fred, I always express my own opinion. Don't you? LonWorks is the protocol for the LonTalk system. I know it well. Many years ago Echelon approached me to add LonWorks to the list of candidate protocols that ISA SP50 was considering for Fieldbus. At the time, we had a core technology that supported Profibus, WorldFIP, and MIL-1553. I was open to LonWorks, but a basic ANSI and IEC requirement was for it to be an OPEN specification, which in 1992, it was not. It is now ANS/EIA standard 709.1.

As I remember, LonWorks originated to solve Mike Markkula's problem in automating his lawn sprinklers. It has evolved to dominate the HVAC market, and become a major factor in all of building automation and in the water and waste treatment markets. Few of these applications have the critical timing required for process control, factory automation, and materials handling operations.

The major automation project for which LonWorks was selected in 1995 attempted to use LonWorks in native peer-to-peer CSMA/CA mode. They were basically satisfied that it would work, but for the same reasons that collision domain Ethernet has not been accepted for industrial automation, they were unsure how its potential non-deterministic behavior would behave in heavily loaded emergency situations. Since their previous application used a master/slave polling process, they decided to use the master/slave option available for LonWorks. This gave them the guaranteed determinism they desired for public safety, and the low cost and efficiency of LonTalk. A decision in which I concurred.

Profibus is a great example of a peer-to-peer protocol using token passing. This is a different and highly deterministic solution to network access. However, the distributed nature of the access control was too complex and Profibus-DP was defined to use Master/Slave protocol for its time-critical data transfer operations. Master/Master is also used, mostly for master backup and failover. Determinism wins again.

Now full duplex switched Ethernet dominates industrial automation control level buses with upper layers like Foundation Fieldbus HSE, EtherNet/IP, iDA, Modbus/TCP, and PROFInet. Again, determinism wins.

Dick Caro
============================================
Richard H. Caro, CEO
CMC Associates
2 Beth Circle, Acton, MA 01720
Tel: +1.978.635.9449 Mobile: +1.978.764.4728
Fax: +1.978.246.1270
E-mail: [email protected]
Web: http://www.CMC.us
============================================

 

In what way were my statements misleading? I made no claims about or against another protocol which I know little about. Obviously from your comment you disagree with Echelon's definition of "open", but that does not make it wrong and it doesn't make it misleading. LonWorks is an EIA standard and by EIA's definition and standard it is open. Perhaps I should have defined Open in my statement but at the time I didn't think of it.

To many, something isn't "Open" unless it is open source - ie source code et. al. is available for public consumption and modification. Very few standards meet that level of openness. The protocol is available as an EIA standard. The protocol is already implemented in silicon from 3 different vendors. You can buy or develop your own transceiver for any media you care to. Some argue that you have to buy network management from Echelon but that isn't true. There are some third party solutions and I know of at least one company that developed their own for a Linux based solution. So what part of all this isn't "open"? What level would satisfy your definition of open?

As for interoperability, I have first hand experience in connecting products from multiple companies and having the products communicate with each other - this is without having custom code or special company support. Granted, it isn't always perfect but then no technology is. Having a common protocol is only one part of interoperability. It ensures that messages can be delivered among the nodes but it doesn't mean they will understand each other. For interoperability to really work, there needs to be a standard defined at the application layer for data exchange and that is what the LonMark Interoperability Association has worked on. Hundreds of companies have worked to define this layer and again while not perfect it does an admirable job at making communication among multiple vendors work. And this interoperability has nothing to do with licenses. On the flip side, I have seen non-interoperable LonWorks networks but those are usually by design - ie a company has designed all their LonWorks products deliberately to be proprietary. Because the technology is "open" (sorry couldn't resist), they have the right to do so. It is up to end users to request or demand interoperability. OEMs by their nature will always deliver proprietary solutions if possible to lock their customers into their own products.

Your comments reflect your bias which I understand, after all everyone has a bias one way or another. But to me your comments also indicate that you have either been burned by Echelon or you just simply have made up your mind against LonWorks. Obviously I concentrate on LonWorks because that is where my expertise is, but GCC as a company has started expanding beyond LonWorks where and when it makes sense. We look at the strengths and weaknesses of any technology and use what is appropriate for a given project. I don't expect you to change your attitudes about LonWorks but it never hurts to understand the true positives and negatives of any technology and use the best choice that meets the technical and financial needs of a given project.

Regards,

Fred Graham Graham Controls Consulting http://www.grahamcontrols.com

770.330.9123

 

Hi Fred,

Having LONTalk defined in an EIA standard sure looks "open" on the surface until you read the test of the standard. Some items which might be considered detrimental to considering it open:

1. LONTalk is subject to a number of Echelon owned patents

2. implementation by manufacturers not using Neuron chips involves signing license agreements with Echelon and agreeing to give Echelon access to your sales figures and a whole lot of other information.

3. implementation by manufacturers not using Neuron chips involves purchasing a set of node ID numbers (like MAC addresses) from Echelon and whilst they are relatively low cost per number, you must purchase something like a minimum of 10,000 numbers per lot which is a lot of money if you only want to sell a few boxes. It also effectively precludes use of a LONTalk protocol stack being developped to run under Linux say and distributed under GPL.

Compare the above to say TCP/IP and LONTalk is a lot less open.

Regards

Peter Whalley
Magenta Communications Pty Ltd
Melbourne, VIC, Australia
e-mail: peter*no-spam*@magentacomm.com.au
delete *no-spam* before sending

 

Hi Peter,

Hope everything is going well down under. I want to address the points you brought up as I am familiar with them. I don't know if you are basing your comments on an old license agreement or just a misunderstanding of the license agreement. I will say that Echelon does have a history of Draconian licensing agreements and they haven't done much to endear themselves to their customers. I have put my comments below, along with your comments.

On June 2, 2003, Peter Whalley wrote:
>Hi Fred,
>
>Having LONTalk defined in an EIA standard sure looks "open" on the surface
>until you read the test of the standard. Some items which might be
>considered detrimental to considering it open:
>
>1. LONTalk is subject to a number of Echelon owned patents <

I am not sure if you are referring to the use of LonWorks with the Neuron or the implementation of the LonTalk protocol in your own processor. I am assuming it's the latter. If you look carefully at the license agreement, they give you a no charge license to use those patents. The license does restrict someone to implementing a complete and compatible version of the LonTalk protocol. This is an attempt to maintain interoperability and not have 37 flavors of "LonTalk" protocol - an example is Microsoft taking Java and making their own slightly modified version that ties you into Microsoft.

>2. implementation by manufacturers not using Neuron chips involves signing
>license agreements with Echelon and agreeing to give Echelon access to your
>sales figures and a whole lot of other information. <

That's a little misleading. Basically if you license the protocol, then you are putting them in your own processors and then Echelon relies on the honesty of the company to report how many they use for distribution of the Neuron IDs. Echelon does reserve the right to audit a company. They have never done this but if they feel a company is distributed a non-compatible version or is shipping a lot of product without IDs, then they can audit them. As part of the license they do ask for test data to show that you have implemented a 100% compatible version of LonTalk but considering the goal of interoperability I don't think that is outrageous.

>3. implementation by manufacturers not using Neuron chips involves
>purchasing a set of node ID numbers (like MAC addresses) from Echelon and
>whilst they are relatively low cost per number, you must purchase something
>like a minimum of 10,000 numbers per lot which is a lot of money if you
>only want to sell a few boxes. It also effectively precludes use of a
>LONTalk protocol stack being developped to run under Linux say and
>distributed under GPL. <

I can't argue this one. You are right in that it isn't much - for that 10,000 IDs = $1,500.00. But it certainly isn't for someone who is just playing. But then if you are going to that much trouble to port the entire protocol you probably aren't out to ship just one! If you are in low volume and running under Linux, then why not just develop a Neuron based plug in board - or buy one - there are USB, serial, and PCI, PCMCIA cards available, many from 3rd party companies. The software on your Linux machine then wouldn't have any license restrictions.

>Compare the above to say TCP/IP and LONTalk is a lot less open. <

I never said that LonTalk was "as open" as TCP/IP, but it is open. It is available to anyone on an equal basis - no charge license, the only fee is the small one for the IDs and that's only if you are shipping a product. I think that is a pretty fair deal for a protocol that was developed as a proprietary protocol from one company. It just illustrates that there can be many different opinions as to what "open" means. And just because you disagree with one version doesn't make you right or wrong it is just a different view. But if everyone has equal access to the protocol, I think you could agree that it is open - at least on some level.

Fred Graham
Graham Controls Consulting
http://www.grahamcontrols.com

770.330.9123

 

Of course I express my opinion as should anyone. I was only making the point that some of your comments came across as facts and not opinion and that they weren't entirely correct. As for LonWorks origination, thats not entirely correct. The actually germ of the idea came when Markkula was teaching John Scully (at the time the new President of Apple) about the history of computing and showing him how as price and size came down the volumes of smart devices increased dramatically. As he was drawing the curve and looking at existing technologies he noticed a hole. He hired a group of engineers to investigate the possibility of creating a low cost network of devices. His thinking was that if they could build it low cost enough then it would penetrate the home automation market and the volumes would be huge. Of course like any new technology, it was over hyped and they didn't understand the complexities in reaching that goal. The result was that it has taken a lot longer to get to where they are today than they originally thought.

As for your comment about determinism, I won't argue that point with you. I have always said that LonWorks isn't suited for all applications. There are a class of industrial applications where LonWorks can fit - those that don't require determinism, or very high speed message delivery.

Regards,

Fred

Fred Graham
Graham Controls Consulting
http://www.grahamcontrols.com

770.330.9123

 

Yeah, what Pete said!

Actually I wanted to wait until I had the time to address Fred's points properly. And I would be very interested in Echelon's definition of "open" but I doubt we'll hear it, there's a lot more wriggle room if that can of worms isn't opened. Ask any of the vendors who throw around the term open to state how they define it and it gets really quiet. But, long time listers will recall that I did get interested in LONWorks soon after hearing about it. IIRC, there was some announcement about free and open software or something. I took it at face value and hit the website I'm sure you could verify this as data was duly collected. I didn't get very far before I realized that I would have to make several agreements not in my best interest to even try anything, and of course Linux wasn't supported. So, regardless of any bias I might have, my perception is based on actual experience. And I'm willing to use the old tort standard of what a preponderance of reasonable people might think.

Rather than debate definitions, I think an example would be useful.

Let's say that Curt Wuollet of WOT developed a low cost multichannel virtual chart recorder for balancing room temperatures. (I did) and that I decided it would be useful to add a proto stack, etc. to talk to other HVAC type stuff. (I have) We'll use my favorite, Modbus/TCP, as the open comparison even though it isn't, since it's about the closest to open.

To use Lontalk I have to sign licenses, buy chips or boards from parties that cut Echelon in, perhaps buy a block of addresses, etc. etc. Then start developing code which can't be released with my product. And if this all were possible. I would encumber each and every customer. And I am encumbered far beyond the value of the project. Forever.

To use Modbus/TCP I write the code and release it with the rest of the product. Nothihg special is required. There are some very remote concerns to be fair, but I think GS etal. have indicated the desire for Modbus/TCP to be widely used. It would be difficult to stuff the genie back in the bottle.

Now, even without debating the absolutes of open and closed, I think the preponderance of reasonable people could pick which they think is open and which is closed.

Regards

cww

 

Hi Fred,

I agree that "open" can mean many things. One of my colleagues refers to it as "open as in a door". If you just want to listen to a conversation on the other side, a 5mm gap is open. If you want to drive a truck through it may never be open enough for you.

From ccw's point of view and others on the MATplc project for example, if they can't sit down and write a driver from the ground up and then distribute it freely under GPL without any payments, licenses, etc then for them it's not even a bit open. If you're happy to go out and buy a hardware card or pay the IP owner some money and sign a license agreement then just about anything is open including Modbus Plus for example.

Not withstanding the above, I do specify LONMark based system under the heading of "open systems" but must admit that it's not quite as open as say BACnet. Their are however hundreds of LONTalk products available from many dozens of manufacturers which is a lot more than can be said for many other protocols.

BTW, the license agreement you sign with Echelon also prohibits you from saying any bad things about the protocol or Echelon or their products. I still see it as too draconian for most potential developers. The test being how many independent implementations of the protocol stack exist on the market. I'm only aware of one and that was done by the company that Echelon employed to write the EIA standard.

Regards

Peter Whalley
Magenta Communications Pty Ltd
Melbourne, VIC, Australia
e-mail: peter*no-spam*@magentacomm.com.au
delete *no-spam* before sending

 

Hey Curt, apparently either you or I have a disconnect. Perhaps we are talking about 2 different things or aspects but there must be a fundamental misunderstanding because your statements don't make much sense to me. Let's say that Fred Graham of GCC used to work for Echelon (I did) and then let's say he started his own business to provide consulting for LonWorks (I have). Then let's say that GCC decided to start designing, manufacturing and selling LonWorks based control products (I do).

Because of the nature of the products we produce, we use the Neuron chip available from Cypress, Toshiba and Echelon. There is one, no charge license that I signed but it doesn't burden GCC or my customers. There are no royalties, license fees etc. I could have designed my own transceiver and then I wouldn't have to buy anything else from Echelon, but because I wanted to interface directly to other common devices already on the market I decided to purchase FTT-10s (free topology twisted pair transceiver) and PLT-22s (power line transceiver) from Echelon. Again, there is no license fee - I am buy the transceiver, but there is no fee to pass on to the customer or any burden to the customer. Because I am using the Neuron chip, I don't buy ID's - they are built into the Neuron chip already. Any code I develop for our Neuron based products are released with the product and I can choose whether I want to release the source code for those applications or not - its my business decision not Echelons. Again, I don't burden or as you put it "encumber" my customer with anything. So I am not sure what you are referring to when you state "I would encumber each and every customer".

Now, lets pretend for a moment that I decided to port the protocol to my own processor. Realistically that isn't likely because most applications can be accomplished without doing this but for grins lets say I have nothing better to do than to port the protocol and test it to make sure it works on my processor. Again, there isn't much of a burden here (except for the actual development) and certainly nothing to burden my customer with. I simply sign a no charge license with Echelon which basically restricts me to porting a complete and compatible version of the protocol to my processor. I must provide Echelon with testing results to show that I have a compatible version of the protocol and then I buy IDs (equivalent to the MAC address in a NIC card). That ID adds $0.15 per device and if I am making a lot of these then I will negotiate with Echelon to get a volume discount. Then I make my products and release it and sell millions upon millions (a guy can dream can't he?). Other than the IDs, I pay no other royalty or license fee. You state "Then start developing code which can't be released with my product." I am not sure what you mean by that. Of course any code you develop for your product can be released with your product.

While I don't intend to port the protocol for any of my products, I have contacts at companies who have and do sell products with a ported version of the LonTalk protocol and they don't have any issues burdening them or their customers. So I don't understand where the disconnect is. I work with this stuff every day and there are no license concerns or fees or royalties that I have to burden my customers with. I would be interested to understand if you have different issues that I am not aware of, but considering my history with Echelon I find that hard to believe.

Regards,

Fred

Fred Graham
Graham Controls Consulting
http://www.grahamcontrols.com

770.330.9123

 

Peter,

I agree with you that the "can't say bad things" portion of the license is a bit ridiculous. Part of me can understand it. They were trying to prevent competitors from getting all the information and then bad mouthing LonWorks. But as with most lawyers they end up pissing off everyone trying to solve one potential problem. Plus, what ever happened to free speech and open discussion that would help improve the whole technology.

By the way, I am aware of at least 3 companies who have ported the protocol - Adept, Loytec and one other I can't think of right now. There may be others as well but without researching it those are the ones I remember with my limited brain function.

Regards,

Fred

Fred Graham
Graham Controls Consulting
http://www.grahamcontrols.com

770.330.9123

 

Hi Fred

I think I know where the disconnect is. Did you read the three (I think) licenses you signed? I'm willing to cut and paste them here for public perusal but, in deference to our host, I'll refrain. But, taking those documents and reconciling them with another, The GPL,under which I would release the code, one detects a certain incompatibility. And I would prefer to retain my first amendment right to mention that Lonworks or Echelon suck, IFF that were the case. One wouldn't want to libel. But, I don't think I could comply with both the GPL and the licenses. And at the very least, requiring any changes to be submitted to Echelon might be a problem. Many OSS customers might suggest what they could do with their license. This would however, be much more comfortable with virtual licenses than their physical counterparts. And then _I_ would be in breach (no pun intended).

And don't get me wrong, if I thought there was any validity in this concept of variable and subjective definitions of convenience for the word open, I would mention that LonWorks is somewhat less impossible for me to deal with than most protos popular here. But that would require variable and subjective definitions of the word impossible. That would tire our readers and smack of Clintonism.

I sincerely wish that those who offer the "Let them eat cake" argument would actually try what they suggest I can do. It would give them a much greater appreciation of all those "click through" and "shrinkwrap" licenses they are legally bound by, but don't read or remember. The only way I can oblige is to structure my practice in much the same way as the license holder and that wouldn't accomplish anything for OSS.

Regards

cww