K
On Fri, Feb 04, 2000 at 11:03:26AM -0500, Ralph Mackiewicz wrote: (in thread "Re: COMM: Is Siemens PPI a closed protocol")
>...
> Neglected in this argument is the fact that neither CAN nor TCP/IP are sufficiently defined by themselves to allow the manufacturer of any piece of industrial control equipment to have any hope of interoperating with anyone else. For instance, how does the commoditized version of TCP/IP using a standard TCP socket provide a
service for reading a variable? ... <
TCP/IP is good for moving packets, but an application protocol is needed on top of it to do things. What about defining a protocol to do what
you ask? Perhaps one of the many existing protocols can do this, but I'm not aware of a suitable one.
I would like to use a "generic" PLC query protocol to interact with a few different PLCs (and other systems), and I'm thinking of defining one for the purpose. XML (extensible markup language) can provide a verbose mechanism to do this in a clear and obvious way, I think, by using terms similar to what you used above, i.e., by explicitly stating the query in the message.
In a prototype server, access details for each anticipated PLC are stored in configuration files, so that the query only needs to identify the site; the type of PLC is specified in the config files. The PLC type could alternatively specified in the query protocol, as well as the
access parameters (communications channel, logon id, password, etc.)
Here's an example query:
<PLCS site="owner1/site3">
<GET type="register">4002</GET>
<GET>type="symbolic">fan13_motor_amps</GET>
<GET>a_variable</GET>
</PLCS>
In the latter GET query no type attribute is specified, so the server would provide a default one, perhaps based on the nature of the variable
name provided.
I don't know how far such a thing can be taken, but I think I can define a workable protocol for the few target controller types I'm familiar with.
One problem is that different systems may have very different conceptual models, and it is likely difficult to express the details of one in the syntax of another. However, I think it should be possible to express at least some useful queries in a generic way, i.e., to provide a generic PLC interface.
This may seem like a case of YAP (yet another protocol), but I really haven't found one that I can use as is. BACnet may be close to what I'm after, but I haven't ponied up my $119 to read it yet. ;-)
--
Ken Irving
Trident Software
[email protected]
>...
> Neglected in this argument is the fact that neither CAN nor TCP/IP are sufficiently defined by themselves to allow the manufacturer of any piece of industrial control equipment to have any hope of interoperating with anyone else. For instance, how does the commoditized version of TCP/IP using a standard TCP socket provide a
service for reading a variable? ... <
TCP/IP is good for moving packets, but an application protocol is needed on top of it to do things. What about defining a protocol to do what
you ask? Perhaps one of the many existing protocols can do this, but I'm not aware of a suitable one.
I would like to use a "generic" PLC query protocol to interact with a few different PLCs (and other systems), and I'm thinking of defining one for the purpose. XML (extensible markup language) can provide a verbose mechanism to do this in a clear and obvious way, I think, by using terms similar to what you used above, i.e., by explicitly stating the query in the message.
In a prototype server, access details for each anticipated PLC are stored in configuration files, so that the query only needs to identify the site; the type of PLC is specified in the config files. The PLC type could alternatively specified in the query protocol, as well as the
access parameters (communications channel, logon id, password, etc.)
Here's an example query:
<PLCS site="owner1/site3">
<GET type="register">4002</GET>
<GET>type="symbolic">fan13_motor_amps</GET>
<GET>a_variable</GET>
</PLCS>
In the latter GET query no type attribute is specified, so the server would provide a default one, perhaps based on the nature of the variable
name provided.
I don't know how far such a thing can be taken, but I think I can define a workable protocol for the few target controller types I'm familiar with.
One problem is that different systems may have very different conceptual models, and it is likely difficult to express the details of one in the syntax of another. However, I think it should be possible to express at least some useful queries in a generic way, i.e., to provide a generic PLC interface.
This may seem like a case of YAP (yet another protocol), but I really haven't found one that I can use as is. BACnet may be close to what I'm after, but I haven't ponied up my $119 to read it yet. ;-)
--
Ken Irving
Trident Software
[email protected]