Remote digital I/O over Ethernet

J

Joe Jansen/ENGR/HQ/KEMET/US

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).

It is not that they are considered worthless, just less important. Let's face it. If you are not willing to put the effort into helping the
project, why should you have a voting seat on the board? If these guys listened to evry single persons wish list, nothing would get accomplished.
You want it bad enough, do it!


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.

The disagreement is on what you consider to be "the rest of the world". The Linux PLC guys are concerned with connecting to *equipment*. PLC's, drive controllers, Vision systems, etc. You are concerned with connecting to desktop computers. It is simply a difference of priority. As I hear your side, you want the LinuxPLC to be able to send data to HMI and
Database software. (Note, tho, that there are several good *nix db packages out there.) From Curt, Jiri, and the rest of the guys making this
work, their priority is on talking to I/O, other PLC's, loop controllers, etc. Once they get the low level functioning out of the way, they may have time for the higher level stuff. Again, the *ONLY* way to change that priority is to get involved. It is too easy for many (including myself) to say "You guys HAVE to include feature XYZ, or your project is a waste of time". Think of how motivated it would make you if someone from a non-paying customer walked into your office and told you that what you were working on was a waste of time unless it had some feature, but then refused to even lay out a specification or put any effort into getting that feature
into your project. You'd probably tell them to shove off! (I would!)



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)

Because again, history shows the "embrace and extend" method of dealing with competition. The matter is moot, anyway, because you will never get
anything MS that will be compliant with GPL.



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.

Then join the group, and get something started! Armchair quarterbacks are a dime (USD) or less a dozen. Get in there, write an XML parser, and
submit it. Evangelize the benefits of your XML system. Tell us why we should use it! What will the benefit be? and most important:

SUBMIT YOUR CODE!

Nothing, and I mean nothing, will convince anyone as easily as a functioning piece of code. That is fact.


Or ignore the whole LinuxPLC project entirely. The choice is yours, obviously. But stating "You're all completely wrong, have no idea what your doing, and wasting all your time." without caring enough to get involved, is not the way.

--Joe Jansen
 
On Mon, Jun 18, 2001 at 08:47:43AM +1200, 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).

I think you miss the point. The project is strictly and entirely run by volunteers, each scratching their own itch. Trust me, this (DCOM and other MS interfaces) has been the subject of more than one thread on the project mailling list,
and you are simply restating a point of view that is shared by some and not by others. I don't think that's the same as being "worthless", just old and tired. You could breath new life into the DCOM thing if you either contributed code or offered to pay someone to do so.

> 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.

If that's your position then I'd suggest just dropping the subject, because the LinuxPLC project is apparently not of interest to you. To the contrary, this "rest of the world" that you are concerned about is really no concern to the
project; they are trying to create a working machine, and it doesn't _need_ to deal with Windows to work. If you want to use it, and you must use it with Windows, then that's your
problem to solve. Again, this has been discussed. A path that makes sense to me is for the LinuxPLC to have well defined interfaces; DCOM, CORBA, and other cross-platform schemes can deal with those interfaces, and do not need to steer or mold the innards of the project. This stuff _is_ being very actively defined and designed by Jiri, Mario, et al, and there is no conspiracy for it to _not_ work with Windows; Windows is simply irrelevant to the effort.

> 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's someone's personal opinion, but I don't disagree; why can't the project just aim to be the best machine it can be in its own right? The Windows interfaces should be able to talk politely with it without having to dictate how it's built. After all, every last detail of this PLC's nature is open for study, quite unlike the typical PLC or HMI system. As to the feelings of potential contributors, I guess they just need to
tough it out, or find something else to do.

> 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.

Been there, done that. Have you looked at the project's archives? A "generic" PLC protocol has been a sort of pet hobby of mine, and XML seemed natural for it, and I've put some effort into it, enough to see a few of the difficulties faced by a new protocol. Other interface ideas have been discussed, and I think some folks are working on new schemes (OPC?).

I don't think things are necessarily as grim as you seem to think they are.

Ken

--
Ken Irving <[email protected]>
 
Scott Cornwall:
> > 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.

Joe Jansen:
> The disagreement is on what you consider to be "the rest of the world".
> The Linux PLC guys are concerned with connecting to *equipment*. PLC's,
> drive controllers, Vision systems, etc. You are concerned with
> connecting to desktop computers. It is simply a difference of priority.

This is a key point: The LinuxPLC right now is at the stage of making it work at all, which means getting at least one each of I/O, logic language,
HMI and communication protocol. The more the better, of course, but at least one of each.

We're getting very close to that, btw.

Talking to anything and everything out there has been a stated project goal from the very beginning (in fact one of the primary goals).

However, each protocol takes time to implement, varying depending on the protocol and the kind of documentation available for it (if any). In
addition, for protocols originating with one of the big companies, we must be careful not to get our head bitten off by them. This changes the order in which we do things --- first we implement the easy protocols (and/or protocols which we happen to know) --- but doesn't change the intention to eventually interoperate with everything.


Jiri
--
Jiri Baum <[email protected]>
"[Microsoft] cleverly associate the word 'open' with XML. What they don't mention is that to see the XML file definitions for Microsoft Word, you
have to sign a file license that says you will never use the code."
-- http://www.itworld.com/Man/2685/IDG010503source2/
 
About a week ago...

> Curt Wuollet:
> > Demanding I write COM/DCOM is sub-optimal as I have neither interest or
> > the secret knowledge to do so.

I wrote:
> I think part of the problem is that we don't have a formal `wish list' on
> which things such as COM/DCOM could be placed.

We now have a formal wish list.

Go to our new web site at http://mat.sourceforge.net and click on Tracker
(in the nav bar), then Feature Requests, Submit New.


Jiri
--
Jiri Baum <[email protected]>
"[Microsoft] cleverly associate the word 'open' with XML. What they don't
mention is that to see the XML file definitions for Microsoft Word, you
have to sign a file license that says you will never use the code."
-- http://www.itworld.com/Man/2685/IDG010503source2/
 
M

Marco Savegnago

Hello, I've used Beckhoff BK9000 TCP/IP ethernet coupler (similar to WAGO
750-342 series) with TCP/MODBUS to make a real time control of a machine
with custom C++ application running on a dedicated SBCC.
The Beckhoff BK9000 has implemented the MODBUS function 23 that allow a
read/write of the whole input and output process images in a single modbus
frame request.
The BK9000 has a 10/100Mb ethernet controller but the internal tcp/ip stack
don't allow more that 45 frame exchange per second (approx 21~22ms), so I've
used as timebase for the scanner 25ms (40 fps).
The coupler that I've used comes with the first firmware that has the
tcp/modbus implemented and my opinion is that the tcp/ip stack
implementation must be optimized to reduce dead time.

I've not tried extensively (in the same configuration and conditions) the
WAGO Ethernet 750-342 coupler but my colleague that have made some testing
on it report that it is fast more than Beckhoff BK9000.

Bye.

Marco Savegnago
 
Top