> I'm interested Dave, and we don't have a bandwidth problem. Don't
> feel you have to dive off-list, just ref the preceeding messages so
> we don't run too long and bother Ken. (Our gracious host).

Curt, (and list)

I do have some concerns what does LinuxPLC mean, you may think it is relatively simple but there is quite some scope for what is "on-topic":

a) Comunications to PLC devices
a.1) Serial communications
a.2) Ethernet communications
a.3) "Open protocols"
a.4) Proprietry procotols
a.4.1) "We will not support device xyz because..."

b) Using a Linux PC with IO modules to act as a PLC
b.1) Supported hardware
b.2) Kernel issues
b.3) Low level programming API

c) Programming languages for PLC
c.1) IEC 61131-3
c.1.1) Ladder logic (aka LD)
c.1.2) Instruction language (aka IL)
c.1.3) Structured language (aka ST)
c.1.4) Function Block (aka FBD)
c.2) Language editors
c.2.1) "vi"
c.2.2) "emacs"
Strictly personal opinion: "Emacs appears to be
the hackers editor. If you know how to use emacs
you can make it sing, dance and brew a good cup of
coffee. I have not used it (I consider my self
an old fashioned C programmer who does not have
time to learn Perl, Java or what ever today's
scripting/programming language is). But everything
I have heard about emacs suggests it could be used
as a ladder logic editor with a few extra macros.
Once the ST editor is finished I will issue a
challenge to this list regarding editors."

d) Data acquisition (data historian)
d.1) Simple historian ("snapshots")
d.2) SCADA historian (snapshots, averages, archiving)
d.3) Advanced historian (above + MMI + trending
+...+<etc>)

e) Man machine interface
e.1) Simple snapshot interface
(eg: command line "what is the current value at slot
x?")
e.2) Web interface (someone will surely do this
sometime...)

f) "Hardware discusion"
f.1) Unbiased comparison between vendors
f.2) Biased comparison between vendors
(Expect content of "f.2)" be MUCH larger than "f.1)"
)

Have I missed anything? or does an FAQ exist?

My interest in this list is to develop a system that can be used by educational institutes for training & research (eg: non-profit).

David Campbell

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc

 

David,
The list that you have out up is relatively complete. The point which seems to stand out in my mind (due to many years of associated problems with different vendors) is not the method of communication eg Ethernet or Serial, it is the protocol which sits on top. Each vendor such at AB, Seimens, Telemecanique, etc. support serial but have different message formats. The PLC should be independent of these and if someone wants to apply "XYZ" protocol, then they just have to write a device under linux which will comply to the standard. This will be the same approach as ODBC standard. All Database manufacturers have their own standard, but for external communication, they comply to ODBC which will also apply to us in near future when it comes to application of SCADA history, etc.(That will make us DB independent).

I wonder if anyone has an open protocol(message format) defined ! For a while MAP was the up coming, but I think hardware killed it. I can start writing a device for message handling based on serial (RS232, RS422, RS485, etc.) or ethernet but I don't have a clear protocol defined yet.
Does anyone have any suggestions ?
There are a few on the market now (such as CE). We need to select one or spec one which accomodates for both dum devices (local area) and
intelligent devices (other PLCs).
Any suggections are welcomed.
Thanks
Bob-

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc

 

Hi Dave
There isn't a FAQ and at this point we don't have to worry about relevence too much. There was a time when we had about 50 threads going and that
was horribly confusing. And a really useful Linux PLC will arguably touch on all of those and will go to depth on quite a few. I'm an old C hacker
myself and one of my stated goals is to produce something useful to schools or anyone who wants to learn. ( I hope I understand it when we're done). Everything in the archive should be GPL'd by agreement so it can be shared. Those things that may be legally iffy (e.g. reverse engineered
protos), I would like to keep separate so a legal challange can't shut down the whole project. The preferred language is C as the core is very much systems programming. I can see where other languages might be appropriate, for example, SCADA visualization in Tcl/Tk or Python although I don't use those enough to help out. I'm not a big believer in OOP for systems programming
and that has pissed a few people off but, that's what we've kinda settled down to in a nutshell. Strong opinions are great, but let's be kind too.
The people who are really steering the project are the ones who are writing code. I have no problem with that.

regards

cww

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc

 

Hello,

Bob wrote:
> I wonder if anyone has an open protocol(message format) defined !
...
> We need to select one or spec one which accomodates for both dum devices
> (local area) and intelligent devices (other PLCs).

Don't forget we aren't restricted to having just one protocol.

In fact one of the proposed applications for the PuffinPLC is as a traffic cop between mutually-incompatible protocols.

So in a way the answer to your question is "all of them", but that's not a useful answer.

Which protocol is implemented first will probably depend on some minor mundane detail, like a chance intersection of the coding skills, time and
the hardware on someone's desk. (And that's my useful answer.)


Jiri
--
Jiri Baum <[email protected]>
What we do Every Night! Take Over the World! Step 1 - bid for SMOFcon

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc

 

Hello,

I have a suggestion for an open protocol that defines a message structure.
How about Modbus? I work for a company that manufactures distributed I/O
modules, and we are compatible with Modbus for serial communications and I
believe we have some compatibility with Modbus over Ethernet. We are
currently researching porting the hardware OS to a Linux-based OS, so we
have interest in the PuffinPlc project, and my managers have expressed
willingness to lend (Modbus compatible) I/O modules (hardware) to your
project if needed. Anybody interested?

-Amy

----------------------------------------------------------------------------
Amy McMillen - Software Engineer
SIXNET "Programmable I/O"
E-mail me at mailto:[email protected]
-------------------------------------------------------

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc

 

Bob [mailto:[email protected]] wrote:

I wonder if anyone has an open protocol(message format) defined !
For a while MAP was the up coming, but I think hardware killed it.
I can start writing a device for message handling based on serial (RS232,
RS422, RS485, etc.) or Ethernet but I don't have a clear protocol defined
yet.
Does anyone have any suggestions ?
There are a few on the market now (such as CE). ...<clip>

If you really want interoperability with many SCADA hosts, HMI software and other PLCs, then the serial protocol to use is Modbus. It may be a bit old (heck it may be a lot old) but it's supported by more devices than any other single protocol. For Ethernet there is a version called Modbus/TCP.

Specifications for both are on the Modicon web site at:
http://www.modicon.com/techpubs/TechPubNew/index.html. The protocols are proprietary, but the specifications are freely available. The protocols are widely available.

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc

 

Amy McMillen wrote:

> I have a suggestion for an open protocol that defines a message structure.
> How about Modbus? I work for a company that manufactures distributed I/O
> modules, and we are compatible with Modbus for serial communications and I
> believe we have some compatibility with Modbus over Ethernet. We are
> currently researching porting the hardware OS to a Linux-based OS, so we
> have interest in the PuffinPlc project, and my managers have expressed
> willingness to lend (Modbus compatible) I/O modules (hardware) to your
> project if needed. Anybody interested?

Modbus is, by default, the closest thing we have to an "Open Standard". The serial stuff is somewhat standardized, the Modbus/tcp stuff much less so. I would be interested in working with a reasonable Modbus/TCP implementation. So far the one I have been putzing with only does 5 commands and takes a one second breather after 30 cycles or so. There is at least one other list member that has done some work on the serial side and perhaps TCP. I will do whatever I can to work with any IO vendor that wants to support the Linux
PLC project and can play by OSS rules. Please feel free to send information and we'll talk about hardware. At the very least I get many inquiries about Linux compatible IO. The first vendor that really supports Linux will get high
visibility in an otherwise crowded market.

> -----Original Message-----
> From: Bob [mailto:[email protected]]
> Sent: Thursday, August 31, 2000 11:07 PM
> To: [email protected]
> Subject: Re: FAQ anyone? (was RE: linuxplc: anonymous
> plc_get_pt_by_loc())
>
> David,
> The list that you have out up is relatively complete. The point
> which seems to stand out in my mind (due to many years of associated
> problems with different vendors) is not the method of communication
> eg Ethernet or Serial, it is the protocol which sits on top. Each vendor
> such at AB, Seimens, Telemecanique, etc. support serial but have
> different message formats. The PLC should be independent of these
> and if someone wants to apply "XYZ" protocol, then they just have to
> write a device under linux which will comply to the standard. This will
> be the same approach as ODBC standard. All Database manufacturers
> have their own standard, but for external communication, they comply
> to ODBC which will also apply to us in near future when it comes to
> application of SCADA history, etc.(That will make us DB independent).
>

I think a good starting point would be any common API to the Open Source databases first. I am a little concerned about interfaces that can be
manipulated for commercial purposes (the MS moving standards game ). Also I doubt that people are going to choose an expensive proprietary db
to use with their free Linux PLC. Postgress for heavy duty use and a small lightweight db selected from the OSS offerings would keep it free and open.

Regards

cww

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc

 

I am a little skeptical in regards to Modbus. I thought that Modbus required hardware which means the standard PC which has Serial port and usually an ethernet card, will not be adequate. The protocol has to fit within the realms of a
standard PC (or near enough - like ethernet for high speed requirements). Also Modbus is not an open standard which may or may not require special licensing (I am not a lawyer so this has to come from someone who knows this!) terms.

I think we should stick to the first two suggested ones by Dave (Serial and Ethernet) as most PC's have them already. Also the architecture will be in two separate parts and hardware independent (One Message Handler device - not part of the network device) which will write RAW to the network device. This will guarantee a true hardware independent protocol and
anyone can write to their hardware choice. This will be via a device name in message handler which will write to *P as set by the author (INI file of some kind). Also we can have multiple read/write to various hardware at the same time.

Any ideas ? or have I got something wrong ?
Thanks
Bob-

 

Modbus requires no hardware beyond the serial port or Ethernet interface. Perhaps you are thinking of Modbus Plus which does require special hardware.

Many people use Modbus today. There is no licensing required.

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc

 

Thanks for the correction.
Where can we get hold of Modbus message protocol
definition /documents ?
Thanks
Bob-

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc

 

> I am a little skeptical in regards to Modbus. I thought that
> Modbus required hardware which means the standard PC
> which has Serial port and usually an ethernet card, will not
> be adequate. The protocol has to fit within the realms of a
> standard PC (or near enough - like ethernet for high speed
> requirements).
> Also Modbus is not an open standard which may or may not
> require special licensing (I am not a lawyer so this has to
> come from someone who knows this!) terms.

No Modbus doesn't require special hardware, but does have some interesting requirements. And, no it isn't an Open Standard but is widely implemented and I have not heard of Groupe Schneider suing anyone although I suppose they
could. It would be great if they would formalize an Open License that we could confidently work under. See below.

> I think we should stick to the first two suggested ones by
> Dave (Serial and Ethernet) as most PC's have them already.
> Also the architecture will be in two separate parts and hardware
> independent (One Message Handler device - not part of the
> network device) which will write RAW to the network device.
> This will guarantee a true hardware independent protocol and
> anyone can write to their hardware choice. This will be via
> a device name in message handler which will write to *P as
> set by the author (INI file of some kind). Also we can have
> multiple read/write to various hardware at the same time.
>
> Any ideas ? or have I got something wrong ?

Well you don't exactly have it wrong, but we still need a protocol. If I decided today to make some ethernet or serial attached IO, I would need both pieces to agree on how data is formatted. That would be a protocol, no getting around it. I can and have done this for various applications. The reason we still need something like Modbus is that none of you have ever seen my protocols and you could only get your hardware from me. Unless we make both pieces, ( a step that I have seriously considered for lplc ) we have to use some protocol that is reasonably ubiquitous and has hardware available. Our goals demand that it be free and open. It's simply
that Modbus, whatever it's shortcomings ( and it has some) is the only one of the popular protos that comes close on the free and open part. Modbus is owned by modicon, but is published and
they have shown no interest in restricting it's use. You can find the specs on www.modicon.com for both Modbus and Modbus/TCP. They even provide example source code for Modbus/TCP. If you can't find them, I've got them. There are still issues with using Modbus but the only alternative I see is to write a GPL proto and get into the hardware business. I'm sure the world doesn't need another incompatible protocol at all, but, it would be
the _ONLY_ free and open one. If we have to do this, I've done a hardware design up to the feasibility stage, but it's hard to do free hardware and I don't have the resources to finish it. Then there's all the certifications and approvals (UL,CSA,FM). There are many alternatives, and many even have "Open" in
their name but they aren't as "open" as Modbus. Perhaps some company, seeing the futility of further fragmenting the market will open one up to see what happens, but I doubt it.

Regards

cww

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc

 

I only think you missed one point (I don't call
it wrong), that is if someone is interested in support for this, and someone (not necesarily the same person) is interested in writing it - go ahead!!!! If it takes some special hardware (as far as I have got it I don't think there is in this case) - well, where is the problem, if you want to use it you will need that hardware, if you don't have it you can either use one of the other ones or get that hardware.

There is the point of licensing, but as far as I have understood it that isn't an issue either in this case.


/Johan Bengtsson

----------------------------------------
P&L, the Academy of Automation
Box 252, S-281 23 H{ssleholm SWEDEN
Tel: +46 451 49 460, Fax: +46 451 89 833
E-mail: [email protected]
Internet: http://www.pol.se/
----------------------------------------

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc