Remote digital I/O over Ethernet

D

Thread Starter

Dale Malony

I have a project for a specialized label printer/laminator/die-cutter in the works and the supplier selected in our DA (Decision Analysis) wants to control with the PC (custom C++ app) using remote digital I/O over Ethernet. I am aware of the strengths, weaknesses and precautions to take to ensure best determinism and reliability, but I have no experience with
any of the hardware vendors for this relatively new technology. This is a relatively non-critical application to try a new technology, but I'd like to make a choice that I'd repeat again for the sake of consistency.

As best I can tell, Modbus/TCP protocol would be a wise choice, and WAGO (750series)and Modicon (Momentum) are 2 options with products I would
classify as industrial. I've also had Sixnet mentioned to me but have never heard of it.

I'd appreciate if any of you could share your experiences with these manufacturers with respect to hardware quality, documentation, support,
price/performance ratio, etc.

Has anyone out there done a first hand evaluation of different hardware solutions?

What are some opinions of WAGO "cage clamp?" Honda has been archaically fork-terminal only until recent product availability has forced acceptance of more dense termination designs.

Thanks in advance,

Dale Malony

Honda EqStaff
 
S

Steve Myres, PE

I'd look at using a packaged OPC server layer such as from Kepware (www.kepware.com). They make OPC servers for a large variety of I/O and PLC hardware, like Allen Bradley, Siemens, Simatic TI, Omron, PLC Direct, etc. With regard to Ethernet, I believe they have drivers for A-B Ethernet (PLC's, SLC's, Control Logix, etc, and PLC Direct Ethernet for either the 205/405EBC (Ethernet Base Controller) or the Ethernet I/O module (for use in conjunction with a processor in the same rack).

The C++ app then can act as an OPC client, which means you don't have to worry about comm protocols, and you can change hardware later if you like or if appropriate to a given project. Seems like pretty good stuff; I've just started using it myself.

Steve Myres, PE
[email protected]
 
D
Steve Myres wrote:
"...The C++ app then can act as an OPC client, which means you don't have to worry about comm protocols, and you can change hardware later if you like or if appropriate to a given project. Seems like pretty good stuff; I've just started using it myself.
>
> Steve Myres, PE
> [email protected]"

Could you explain to me how using a C application as the OPC client can avoid using COM/DCOM? I have a very low opinion of DCOM especially, and will avoid ever using it again. Isn't the source code to write Modbus/TCP sort of open to incorporate into custom apps? Why would you recommend OPC over Modbus?

Dale
 
A

Alex Pavloff

> Steve Myres wrote:
> "...The C++ app then can act as an OPC client, which means you don't have
> to worry about comm protocols, and you can change hardware later if you
> like or if appropriate to a given project. Seems like pretty good stuff;
> I've just started using it myself. "
>
> Could you explain to me how using a C application as the OPC client can
> avoid using COM/DCOM? I have a very low opinion of DCOM especially, and
> will avoid ever using it again. Isn't the source code to write Modbus/TCP
> sort of open to incorporate into custom apps? Why would you recommend OPC
> over Modbus?

There is massive confusion over WHAT exactly OPC is. It's very simple:

OPC is a collection of COM interfaces. That's it. An OPC server implements one or more of the OPC interfaces, and then clients connect to it, via COM (if it is on the same computer) or DCOM (if the server is running on a remote machine). COM works just fine -- it's great to be able to make interoperable apps and Windows does all the hard work for you. Using COM components from VB and C++ is pretty easy, and writing simple COM components in VB or C++ (using ATL) isn't that bad either.

DCOM isn't as great to use, because it's far too complicated. It's complicated because it's got a very big job to do (access of any objects passing any parameters over any network while attempting to tie into standard security and authentication services), and the alternative, CORBA, isn't any better.

Modbus TCP or ANY simple TCP/IP protocol will have DCOM beat hands down in the simplicity aspect. However, there IS something to be said to running an OPC server on a Windows machine that then goes and talks Modbus TCP to a remote device -- then you have the flexibility to use whatever client program you want on the Windows machine and you don't have to use DCOM.

Alex Pavloff
Software Engineer
Eason Technology
 
M
Hello,
There is a new interesting system by WAGO and Softing company. They are introducing a new system based on remote Ethernet I/O programmable by IEC61131-3 engineering tool through Ethernet. It seems that the remote modules can have shared variables automatically on Ethernet.

See on the web site of the two company

Best Regards
Mara
Software engineer
 
P

Paul Horvath

You may want to consider NOT writing a C/C++ app. If your objective is to use remote I/O over ethernet and you have a mixed point count (using momentum with large point counts isn't cost effective, WAGO 750 series slice I/O is better) definitely go with a Modbus/TCP compatible system.

As far as your application is concerned, Steeplechase software has a Modbus/TCP driver that is very robust and Steeplechase is one of the few PC based control systems that will operate despite a blue screen on NT. Steeplechase is a flowchart based programming method and you could probably have your application written in about 1/3 the time it would take you to write a custom C/C++ app.

Either way you go, I would recommend using the WAGO until Schneider/Modicon comes out with their own slice I/O (2002). Also, you will be able to expand the system by using Beckhoff/WAGO/Modicon, or anyone elses Modbus/TCP devices (vfds, etc.)

Lastly, using OPC is a great benefit if you are developing an HMI. Acuity and Iconics are two HMI's that I have used which are solely based on OPC. The only pitfall that I have come across is in trying to connect to other OPC servers across a network (DCOM method)there is some user management that needs to be done on the remote OPC servers so the calling application has rights to access.

I hope this helps, please feel free to call me if you have any questions.

Thanks
Paul Horvath
Sr. Integration Engineer
Schneider Automation
[email protected]

 
S

Steven Landau

Referring to Post above by Paul Horvath.

Can the M1e processor talk to the Wago/Beckhoff directly? What type of data translation is done?
Does it work like MB+ peer cop, or just read MB adressess from a specific modbus station #?

S. Landau
SPEC
 
D
>You may want to consider NOT writing a C/C++ app. If your objective is to
>use remote I/O over ethernet and you have a mixed point count (using
>momentum with large point counts isn't cost effective, WAGO 750 series
>slice I/O is better) definitely go with a Modbus/TCP compatible system.

It's my integrator that wants to write the C app/ He will not be doing it entirely custom, just tweaking existing apps to meet my needs. Otherwise I'd certainly use a tool like Steeplechase.

>As far as your application is concerned, Steeplechase software has a
>Modbus/TCP driver that is very robust and Steeplechase is one of the few
>PC based control systems that will operate despite a blue screen on NT.
>Steeplechase is a flowchart based programming method and you could probably
>have your application written in about 1/3 the time it would take you to
>write a custom C/C++ app.
>
>Either way you go, I would recommend using the WAGO until
>Schneider/Modicon comes out with their own slice I/O (2002). Also, you
>will be able to expand the system by using Beckhoff/WAGO/Modicon, or
>anyone elses Modbus/TCP devices (vfds, etc.)

I will only have about 16 in / 8 out per application. Probably discrete only. What do you in this sit? I guess the biggest reason I'd lean towards WAGO is that I don't have to take expansion into account so much with the initial purchase. The flexibility of slice I/O is awesome.

Thanks for the advice,

Dale
 
C

Curt Wuollet

Hi Paul and all.

I first wanted to remark that this is probably the most objective advice I've ever seen from someone with a "big automation" tag. Ethernet IO is a passion of mine as I see it as mission critical for the LPLC and hold out great hope that it can retain the good parts of ethernet without reverting to the failed model of proprietary excess.

> Paul Horvath wrote
> You may want to consider NOT writing a C/C++ app. If your objective is to
> use remote I/O over ethernet and you have a mixed point count (using
> momentum with large point counts isn't cost effective, WAGO 750 series
> slice I/O is better) definitely go with a Modbus/TCP compatible system.

Actually, it probably doesn't make sense to write an application for one time use. What does make sense is to write the application and release it under the GPL. You still get all the utility, others can make use of it, and very likely the
next time you need it, there will be enhancements. If automation folks could work together a little bit. Just four or five reuses of software like this would have it very
mature, broad and stable. Even a handfull of people doing this would provide an extremely
useful pool of solutions to draw from and cut project costs. Or you can write it and let it never see the light of day and help very few. I see that as a major waste of talent.

> As far as your application is concerned, Steeplechase software has a
> Modbus/TCP driver that is very robust and Steeplechase is one of the few
> PC based control systems that will operate despite a blue screen on NT.
> Steeplechase is a flowchart based programming method and you could probably
> have your application written in about 1/3 the time it would take you to
> write a custom C/C++ app.

Seems like damning with faint praise. Automation software should never blue screen. Using known unstable OS's for automation is madness and fraught with liability concerns. The runtime executive makes it better, but you are going to
have to reboot anyway. Having half an application running sounds more dangerous than a clean exit. At least people know how to recover from that. I'm still puzzled at how the benefits justify the risk. People who are so risk averse that they
blanch at the mention of theoretical Ethernet infelicities make their systems and their
reputations dependent on what even the computing public sees as unstable. And it's gotten to the point where there is no alternative to this dependancy. Hard to believe, but true. Truth _is_ stranger than fiction.

> Either way you go, I would recommend using the WAGO until
> Schneider/Modicon comes out with their own slice I/O (2002). Also, you
> will be able to expand the system by using Beckhoff/WAGO/Modicon, or
> anyone elses Modbus/TCP devices (vfds, etc.)

The Wago/Beckhoff stuff is a good idea. Vendor independant and even reconfigurable to a new fieldbus. It's the wave of the future and smart
investment protection. Especially when it's so cost competitive. Now if they would just support an open protocol of some sort, it would be near
perfect. I think this is not lost on even the automation vendors. Expect everyone to have a similar product soon, except for the open part.
Modbus/TCP would be my first choice for the first truly open automation protocol if Modicon would take that last little step and open it. It's very
close to that now. Five O's to Wago/Beckhoff, three to Modicon etal.

> Lastly, using OPC is a great benefit if you are developing an HMI. Acuity
> and Iconics are two HMI's that I have used which are solely based on OPC.
> The only pitfall that I have come across is in trying to connect to other
> OPC servers across a network (DCOM method)there is some user management
> that needs to be done on the remote OPC servers so the calling
> application has rights to access.

Using OPC severely limits your ability to ever get over the MS dependancy and it's inherent problems. Yes it's easy and widespread, but so is heroin. Once you start down that road, the pushers smile from ear to ear. No O's for OPC, it got a couple for interoperability, but lost them for misuse of the term "open" and one
platform limitation.

> I hope this helps, please feel free to call me if you have any questions.
>
> Thanks
> Paul Horvath
> Sr. Integration Engineer
> Schneider Automation
> [email protected]

Regards

cww
 
S

Scott Cornwall

OK Curt,
OPC provides open interoperability for software that runs on the platforms that maybe 90% of the industry uses. It would be nice to be able to cater for the other 10% as well. That would
require the use of a distributed object framework that has widespread acceptance. What would you suggest is a better choice than DCOM and still has the wide degree of acceptance required to make a commercial success out of products
based on the technology ? If there was a viable alternative then it would feasible to adapt the open OPC data access interfaces to work on top of another object framework. I think you give OPC too hard a time, given that it is one the most
significant efforts at opening up the once very proprietory automation market. DCOM and OPC on other platforms would be great - it would be a valuable feature for the LinuxPLC.

Scott Cornwall
_________________
www.sentech.co.nz
 
C
Scott Cornwall wrote:

> OK Curt,
> OPC provides open interoperability for software that runs on the platforms
> that maybe 90% of the industry uses.

And reinforces the monopoly to keep it that way. That's the dependency I was talking about. It was a bad move to get in bed with Microsoft in the first place

and it will be extremely difficult to get out. These technologies were designed with an eye towards that result. That would be odious yet beneficial if it were an engineering masterpiece. It is not, so strike the beneficial.

> It would be nice to be able to cater for the other 10% as well. That would
> require the use of a distributed object framework that has widespread
> acceptance.
> What would you suggest is a better choice than DCOM and still has the wide
> degree of acceptance required to make a commercial success out of products
> based on the technology ?
> If there was a viable alternative then it would feasible to adapt the open
> OPC data access interfaces to work on top of another object framework.
> I think you give OPC too hard a time, given that it is one the most
> significant efforts at opening up the once very proprietory automation
> market.

First I must call your attention to the fact that distributed object frameworks weren't an automation technology. They weren't drawn by any automation demand or to solve any automation problem. They are there only because that's what you need to use to deal with Microsoft's software. If you use MS tools that's the only way you can do things. If there were such technologies needed and engineered for the automation world, any number of much simpler, less
general, much more robust and easier to use technologies would suffice. MS implies OPC.OPC implies MS, you just can't get one without the other. I fail the see how tying the very proprietary automation market to the very
proprietary Evil Empire has opened anything. I still can't use anything but Microsoft. and Brand A still doesn't work with Brand B. What is this openness you are talking about? In fact, I suspect the major reason big automation is in
bed with MS is that it would do nothing to open up their strategic propriety.

Now, down the road, the trojan horse has had it's full effect, you're locked in and I can't propose much for viable alternatives because by design, it is costly and very difficult to switch. That's why it's an abuse of the word open. Open
technologies should be easily interchangeable. For an example of Open desktop object technologies, take KDE and Gnome. I can flip between them at will and most if not all applications can be run with either. And they are purpose built for the job they do and source is available. Both run on many processors and
several operating systems. I don't propose these for automation though as they are no more intended for automation than Microsoft's desktop object technology.

> DCOM and OPC on other platforms would be great - it would be a valuable
> feature for the LinuxPLC.

So I've heard. I'm not convinced. Please give me some examples of indispensible automation tasks where OPC is the best engineering solution. Give me one example where OPC is required except to use Microsoft software. These are problem
sources not problem solvers.

Regards

cww
 
C

Chiron Consulting

> OPC provides open interoperability for software that runs on the
> platforms that maybe 90% of the industry uses.
> It would be nice to be able to cater for the other 10% as well.

[snip]

> What would you suggest is a better choice than DCOM and still has the
> wide degree of acceptance required to make a commercial success out of
> products based on the technology ?

Scott,

I think you're missing an important point. For a significant portion of the 10% under discussion, DCOM has *no* acceptance. As in none, zero. If
they were willing to depend on Microsoft technology, they wouldn't be in the 10%.

If I were a Linux user interested in an open object framework (and I am) then I'd be looking at CORBA. Personally, I'm a lot more interested in CORBA on Windows than I am in OPC on Linux.

If your measure of the "commercial success of ... products" includes acceptance by Windows users, or interoperability with Windows programs in
a mixed-OS network, then I'd agree that Linux support of proprietary Windows protocols would be necessary. And let's be clear; OPC/DCOM are
proprietary. The internals are not published and freely available; the only righteous implementations of DCOM for Linux (and there are a few) are commercial products written by companies who licensed the necessary information to produce them; and any Open Source implementations of DCOM for Linux (and there are a couple in the works) are reverse-engineering
efforts subject to legal attack from Microsoft if those efforts are ever successful enough that Microsoft perceives them as a threat to revenues.
(And while I can't prove it, I maintain that Microsoft has no interest in the proliferation of its technologies in any form that Microsoft doesn't control and doesn't directly earn money from.)

> DCOM and OPC on other platforms would be great - it would be a valuable
> feature for the LinuxPLC.

I think the logical conclusion to your argument about market acceptance of DCOM/OPC is that LinuxPLC would do better if it abandoned the Linux
platform altogether and pursued an Open Source software PLC for Windows. And while I'm sure there are Windows users in the automation field who would welcome such a development, it is diametrically opposed to the project's commitment to producing a completely open and unencumbered
system.

Regards,

Greg Goodman
Chiron Consulting
 
S

Scott Cornwall

Greg,
CORBA is a sensible suggestion as an alternative to DCOM. If CORBA had wide enough acceptance then a lot of people would be using a "CORBA for Process Control" specification and building interoperable "CPC" products. It doesn't, and we have to build commercially viable products to keep our businesses alive.

You are wrong about the logical conclusion of my arguments. The LinuxPLC should not abandon Linux, it is perfectly logical for a PLC to run on top of
Linux. What the LinuxPLC does need to be successful is to be interoperable with a large number of other systems - open connectivity. That means it will need to connect with Windows based software, which raises DCOM again. We can hope for a better alternative but it is not there yet. I know that DCOM is not ideal, but that group that give it zero acceptance will have to remain an isolated group that cannot interoperate with the rest of the world until a better alternative comes along.

If the LinuxPLC projects commitment really is to a completely open and unencumbered system, then it would be open about the platforms supported,
rather than only Linux. That could be what is slowing progress - restricting (alienating?) its useful market and available development resource.

Scott Cornwall
_________________
www.sentech.co.nz
 
S

Scott Cornwall

Curt,
Is a PLC that can't interoperate with other automation software a "best solution" ?

The OPC foundation catalog lists hundreds of products from dozens of vendors that are interoperable - all providing different solutions in different ways - and none of them from Microsoft. Brand A does work with Brand B now.

Not only that but OPC has solved some problems and enabled many new vendors and products into the automation market. Many of them small, agile companies bringing fresh ideas into the industry. A manufacturer of a device can write an OPC server once and know that it opens up the ability to use a large range of OPC clients (like HMI/SCADA). Previously that manufacturer would
have had to write a separate driver for each software package. And vice versa for the developer of OPC client software.

Yeah OK, any distributed object framework could technically have achieved the same result. But for it to be successful it needs to be pervasive.

So just how are you going to solve the problem of getting the LinuxPLC to interoperate with a wide range of other software ?

Scott Cornwall
_________________
www.sentech.co.nz
 
On Fri, Jun 15, 2001 at 06:29:27PM +1200, Scott
Cornwall wrote:
> CORBA is a sensible suggestion as an alternative to DCOM. If CORBA had wide
> enough acceptance then a lot of people would be using a "CORBA for Process
> Control" specification and building interoperable "CPC" products. It
> doesn't, and we have to build commercially viable products to keep our
> businesses alive.
>
> ...
>
> If the LinuxPLC projects commitment really is to a completely open and
> unencumbered system, then it would be open about the platforms supported,
> rather than only Linux. That could be what is slowing progress - restricting
> (alienating?) its useful market and available development resource.

My take is that the LinuxPLC project is open to contributions, and if someone were to make the effort to realize an interface via DCOM to existing (Windows) systems, then it would be there. This argument has a long history in the project archives, but the folks who are doing the work, contributing code and making things
happen, tend to have more say in the nature of the project. You're not going to win this argument unless you can back it up with code
and make it so.

Ken

--
Ken Irving <[email protected]>
 
C
Scott Cornwall wrote:

> Curt,
> Is a PLC that can't interoperate with other automation software a "best
> solution" ?

No but that goes both ways. I don't see anyone making an effort to go outside a windows only world. I can talk to almost any automation equipment, it's just Office and Windows applications I would need OPC for. I have said that if some wants to write it and can work around the licensing issues and can release it under the GPL, we'll put it in the archive. We can't put proprietary code into our project in any case. Then we would be subservient to Microsoft and nothing would have been accomplished. The sole automation port I know
about is Labview. It runs better under Linux. I expect that's why they did it. I would be curious as to how they solved this problem. I'll make a
note to look when I have $1200.00.

> The OPC foundation catalog lists hundreds of products from dozens of vendors
> that are interoperable - all providing different solutions in different
> ways - and none of them from Microsoft. Brand A does work with Brand B now.

I still don't think you get the point. I get dozens of CD's with demos of this and that. I put them in my CD drive and they don't work. I would have to buy hundreds or thousands of dollars worth of buggy software from people I don't want to support simply to make them work. And by the time I had an equivalent environment with all the programming tools, languages, applications and utilities I use every day, that first OPC tool would be more expensive than this whole cell I'm working on. From your viewpoint that may make sense, but from mine, I'm gonna have to pass. Brand A on Microsoft works with Brand B on Microsoft. Usually they don't work with each other, they are simply interchangeable. None of those products is of any use to me, I don't use them obviously and yet, I do state of the art
automation.

Hmmm. I don't even know what problem I have that they might solve. I'm doing automation for many thousands less and I certainly don't feel I'm missing anything. What is it I'm missing?
Of course this is my personal situation. From my experience so far, the better solution might be for those folks to get rid of Microsoft. Then they wouldn't need all those thousands of dollars worth of black box software and nasty licenses. They could still do the same things for a whole lot less. And I'll bet the reliability would be an order of magnitude better. Now, why should I do that again? And if I can't possibly justify OPC for my own use, what business do I have suggesting it to others? I do evangelize but only those things I use and believe in. I challange you to duplicate the cell I'm completing for twice the price, programming time included. And I'll go double or nothing on which
one goes down first.

There are people in the LPLC project that do want OPC and DCOM and MS connectivity. I have rather carefully avoided doing anything to discourage them. They have perhaps, made the huge investment in proprietary software and tools it takes to work with it and are not adverse to shelling out thousands more. Your arguments might prove much more persuasive to them and motivate them to write tributes to Bill and perhaps even some OPC and DCOM code. I haven't seen any yet, I'll keep you posted.

> Not only that but OPC has solved some problems and enabled many new vendors
> and products into the automation market. Many of them small, agile companies
> bringing fresh ideas into the industry. A manufacturer of a device can write
> an OPC server once and know that it opens up the ability to use a large
> range of OPC clients (like HMI/SCADA). Previously that manufacturer would
> have had to write a separate driver for each software package. And vice
> versa for the developer of OPC client software.

Sounds like a good idea, but none of them do anything for me. They do however sell millions of dollars in software for Microsoft, I'm sure they love you. Why don't you have them write software for Linux and GPL it and then we can all agree on the Open part. I might even use it if I ever need to talk to Windows.

> Yeah OK, any distributed object framework could technically have achieved
> the same result. But for it to be successful it needs to be pervasive.

Indeed any communication means, even non-object, even RS232, could do the part that has anything to do with automation. As to why none of those are
pervasive, you'll have to ask the vendors who invent a new one for each new product line. If it were my choice what to standardize on, I'd pick the Internet suite of protocols in a second. At the bottom of the list of sound, efficient
ways to achieve that goal would come proprietary general office automation protocols kludged into serving for our important projects. I could build a lot stronger case for my choice and it is much more pervasive and ubiquitous, As well as Open and free. So perhaps we shouldn't talk
technology either.

> So just how are you going to solve the problem of getting the LinuxPLC to
> interoperate with a wide range of other software ?

I'm not sure, but DCOM and OPC are a tiny slice of the interoperability and connectivity problems we face in this industry. And requiring everyone to have an extra Windows machine in the mix is not gonna help much.

> Scott Cornwall
> _________________
> www.sentech.co.nz

Regards

cww
 
J

Joe Jansen/ENGR/HQ/KEMET/US

Scott,

You sound like you are very convinced. Now show us some code to do this. LinuxPLC, like all other open source projects, is based on contributions.
If you really think that an OPC implementation belongs in there, write one up and submit it. Provided that it can be made compliant with the GPL, I am sure that the project would welcome you contribution.

--Joe Jansen
 
Ken:
> My take is that the LinuxPLC project is open to contributions, and if
> someone were to make the effort to realize an interface via DCOM to
> existing (Windows) systems, then it would be there.

That's right - in fact if somebody *ported* it to Windows, that would be cool too.

> You're not going to win this argument unless you can back it up with code
> and make it so.

Yeah, that's the trick - the current contributors don't have the capacity to do everything, and a DCOM interface sounds like a fair bit of work and
lot of headaches.

But we're open - anyone can join us and things will move forward that much faster...


Jiri
--
Jiri Baum <[email protected]>
"In my opinion, the GPL is optimized to build a strong software community
at the expense of a strong commercial software business model."
--Craig Mundie, Senior VP, Microsoft; 17 May 2001
 
S

Scott Cornwall

Yes Ken, unfortunately you are right. Unless you are contributing code to the project your comments are considered worthless (except if you are jumping on the anti-Microsoft bandwagon).
I do not consider my comments to be an argument, it is fact. If the LinuxPLC is not going to interoperate with most of the rest of the world it will be worthless.

Why would any developer feel enthusiastic to contribute time and code to this project when the main people driving the project make comments like
this :
"I personally am not at all enthusiastic about anything Microsoft creeping into the project and polluting it."
(That is about the summary of recent discussions on DCOM I could find in a quick search)

The more interesting and productive discussion that could come out of this thread would be on what alternatives technologies to DCOM would be
"acceptable" to the LinuxPLC project - the only one raised so far is the old and tired CORBA. Not a single mention of anything XML related.

Scott Cornwall
_________________
www.sentech.co.nz
 
C
Scott Cornwall wrote:

> Yes Ken, unfortunately you are right. Unless you are contributing code to
> the project your comments are considered worthless (except if you are
> jumping on the anti-Microsoft bandwagon).

Oh please. We have had the most open and far ranging debate ever seen in the automation universe. Everyone's comments have about equal worth. Source code in the archive does much more to further the project and obviously takes development in that direction. If you can't code then you can commision someone to write the code and influence the direction in exactly the same way as anyone else. Demanding I write COM/DCOM
is sub-optimal as I have neither interest or the secret knowledge to do so. No I am not a shill and don't believe or repeat the FUD MS is spreading about Linux and I think their ethical standards are deplorable. Does that make me a bad person? I have found their products unreliable and ill suited to automation and I am doing something about it. How about you? This is _your_ project, and you are free and encouraged to add what you will. We have bandwidth left on our mailing list as well.

> I do not consider my comments to be an argument, it is fact. If the LinuxPLC
> is not going to interoperate with most of the rest of the world it will be
> worthless.

To Microsoft. I have found even the very early explorations useful, I'm using it now. I suggest you ask them to make it possible to GPL code written to their standards or , for that matter open up their standards. That is a far greater barrier than my lack of enthusiasm for Trojan Horses.

> Why would any developer feel enthusiastic to contribute time and code to
> this project when the main people driving the project make comments like
> this :
> "I personally am not at all enthusiastic about anything Microsoft creeping
> into the project and polluting it."

That was me and I am adamant about licensed and proprietary content being dissallowed for the simple reason that we will distribute our code freely and in accordance with the GPL. Nothing that Microsoft controls will ever be legally unencumbered to the point where we can do that and we have no bevy of lawyers to even withstand a challange. If you can see how I can do that, I'm very open. If you want to rail on about things we can't do because of Microsoft's licensing policies, your comments are less than constructive. You are free to decide if our license or their license is in your best interest.

> (That is about the summary of recent discussions on DCOM I could find in a
> quick search)
>
> The more interesting and productive discussion that could come out of this
> thread would be on what alternatives technologies to DCOM would be
> "acceptable" to the LinuxPLC project - the only one raised so far is the old
> and tired CORBA. Not a single mention of anything XML related.

We have had quite some debate about XML, My personal view is that it is an extremely inefficient way to communicate data, a least common denominator. Even ASCII Modbus carries more data in less bandwidth and is better suited.
Nothing ever proposed has more overhead and I doubt that it will ever be supported on automation hardware simply due to lack of resources on your typical PLC. Technical aspects aside, it does seem to be relatively Open
and supportable across platforms. That means we can use it, I'm just not sure what for.

In summation, Microsoft connectivity is not a priority right now as we don't have the people and using their protocols is legally questionable without licensing, which we can't do if we wanted to. To the extent that this is unreasonable, I apologize. If you can solve those problems it will climb higher on the priority list. If they open their protos and such we'll get right on it.


Regards

cww
 
Top