Could we separate the open hardware discussion and the fieldbus protocol argument?? The open hardware discussion is about plug in boards, not remote IO.

I am coming to agree with Curt on the general idea of the IO bus. 74HC chips are good. )

It is my opinion that fieldbus IO packet should be in the number of bytes that I can count on one hand. I don' think you can pass around XML data and have short packets, and thus any real speed (tens of microseconds, preferably).

~Ken

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

 

I don't think anyone is advocating using XML for internal communications. For communicating with the outside world though, I believe it XML offers real possibilities.::

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

 

<ACK> (or in XML terms: <ACK/>)

I do not try to advocate XML here, I still think it's the Writing on the Wall, albeit a bracketed one...

Some collegues at the University of Stuttgart are working with tokenized XML, which they use with 8bit microcontrollers (if I'm current). It's
basically an idea derived from WML (the WAP one). Instead of <my-long-tag> they just pass a single byte representing the tag. Maybe that could come closer to your wish of counting packet lengths with your hands -- now does your left hand represent the tens and your right one the ones? Then we would have room for 29 or 30 bytes...::

--
Harald Albrecht
Chair of Process Control Engineering
RWTH Aachen University of Technology
Turmstrasse 46, D-52064 Aachen, Germany
Tel.: +49 241 80-97703, Fax: +49 241 80-92238
_______________________________________________
LinuxPLC mailing list
[email protected] http://lists.linuxplc.org/mailman/listinfo/linuxplc

 

I'm fine with almost anything where it makes sense :^).::

regards
cww
--
Free Tools!
Machine Automation Tools (LinuxPLC) Free, Truly
Open & Publicly Owned Industrial Automation
Software For Linux. mat.sourceforge.net.
Day Job: Heartland Engineering, Automation & ATE
for Automotive Rebuilders.
Consultancy: Wide Open Technologies: Moving
Business & Automation to Linux.
_______________________________________________
LinuxPLC mailing list
[email protected]
http://lists.linuxplc.org/mailman/listinfo/linuxplc

 

Has any one looked into CANOpen, as an 'open' protocol which already exists?::

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

 

Hi Mark

Yes, the only problem is that it's popular in Germany and other parts of Europe and almost unheard of here. So you have the old "one hand clapping" problem. If my hardware project succeeds we would be able to use CANOpen. Otherwise it's hard to find something to talk to. I had investigated writing a DeviceNet layer as CAN hardware is reasonably inexpensive and available. The DeviceNat folks require a pound of flesh and documents we can't execute to even think about that. And bribery to put their sticker on. It seems like anything good gets stifled in the US. Not that I would ever insinuate that the DeviceNet cartel has anything to do with the lack of CANOpen here.

Regards

cww

P.S. That's one of the reasons it's so important that we run Linux on both ends of the cable. We can then use any IO protocol we can express in C:^)

--
Free Tools!
Machine Automation Tools (LinuxPLC) Free, Truly Open & Publicly Owned Industrial Automation Software For Linux. mat.sourceforge.net.
Day Job: Heartland Engineering, Automation & ATE for Automotive Rebuilders.
Consultancy: Wide Open Technologies: Moving Business & Automation to Linux.

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

 

Hi All,

What is the right notation and encoding schema for process control data exchange? Depends!

I have been involved in the Fieldbus and MAP standardization from the very beginning. MAP (MMS - ISO 9506) applies ASN.1 as notation and BER as encoding rules. ASN.1 - who likes it? Many more than most people expect. See:
"www.asn1.org":http://www.asn1.org or just search google for "asn.1 xml aml"

Why not just use XML? Yes for some applications it is sufficient. For many other real-time applications it may not. By the way, XML is NOT a protocol. XML is just a syntax notation (not a language). Why not supporting both? Can a field device support both? Yes, of course.

Independent of the notation and the encoding schema, it is crucial to define WHAT you want to exchange (INFORMATION MODEL) and HOW you want to exchange data (SERVICES) and WHICH networks to use.

I am involved in a standadrization project (IEC 61850) that focuses on the WHAT! We have also services (abstract - to be mapped on application layers or middle ware) and we select networks like TCP/IP, OSI TP4, Ethernet, serial, ...

I expect that future intelligent devices will have standardized information models, applying standardized services, and support different applicationa layers and encoding schemas. We have a demo server package that models a wind power plant information model with some 1000 named variables (process and meta-data). The complete model including a simulation of process values, the services (get, set, reporting, logging (historical data), ..., retrieve meda-data), the mappings to http/html/XML and MMS/ASN.1, running under Windows on top of TCP/IP is just 312 KB.

The demo could be downloaded from:

"http://www.nettedautomation.com/solutions/demo/20020114/index.html":http://www.nettedautomation.com/solutions/demo/20020114/index.html

I guess that in the future many devices will support multiple mappings like in the cell phone market where you find tri-band devices, ..., and soon GSM and UMTS in one device.

Let's focus on the most crucial issue: the INFORMATION models. Encoding schemas and (fieldbus) services will change over time. But the crucial INFORMATION will be the same today and in ten years: A measurement of "Phase A voltage in Volt" will be the same in 100 years...

Regards,
Karlheinz Schwarz
[email protected]