XML and the Evil Empire

J

Thread Starter

jackh

Hi,

I can see that there is some controversy over the XML stuff. First, XML is a structure, not a format. The users pick the format. This does means
that there isn't one universal format. This is also why Microsoft likes it because it divides efforts and makes another HTML killer app (read
Mosaic) less likely. But, we are not developing browsing software. And, those who are developing it for us, Mozilla and Apache, are behind XML
and have a substantial project underway called Xerces. It is available in Java and C++ forms, among others. You can find it at;

http://www.apache.org

In its present state the Puffin PLC does not need XML yet. But, as it matures and users want more features, the need for a good file format will grow. In particular, communications between peers and servers will demand some structure to the data. Some points to think about,

-- The puffinPLC uses compiled programs. This requires all of the processor time and delay before execution. And, changes can't be made while the PLC is running, so the time to parse the XML file is not important during the execution.
-- If communications are to be added to the PuffinPLC, then add them as separate low priority clients talking to the SMM. This means that the
speed of the XML parser will not make the logic engine unstable.
-- The Puffin PLC memory is not reconfigurable after compilation, so the memory definition and transfer becomes trivial. But eventually users
will want to redefine the structure of the memory in the SMM. A complex file format will be needed.
-- The IO and communication issue has not been addressed yet. When it is added the data will then become very structured. One approach is to
define options at compile time, but this will required some type of structured definition file. As an exercise, try to determine how a user
will identify the differences between an 8255 based card (eg Metrabyte DIO-24) and a card that has and 8255 and analog IO on one card (eg
Computer Boards DAS08). They also need to indicate the based addresses, how they map into PLC memory, etc. How about devicenet, and all of the
definition there also?
-- As for the size of the files - they are not much larger than a highly compact file. We have entered an age where 1MB of memory/disk is very
low cost, and network bandwidth makes a 1MB file transfer in a fraction of a second on the same subnet. But the file size for a reasonable piece
of equipment would only be 100K.

Finally, to say this one more time - I am using this for >another< PLC project which uses >interpreted< operations - not compiled. So a file
format like this becomes extremely useful for transfering the data between the PLC software and a remote programing client (and eventually an HMI). I can also transfer small segments of information to update the PLC while it is running, on-line. I initially wrote a flat file
structure for transferring programs, memory definitions and IO scans. For the PLC I wrote my own parser. This simplifies the issues of space,
speed, and interruptability. On the client end I started to write my own parser in Java, but then switched to an XML parser. To transfer the files I am using both serial lines and TCP/IP sockets. The transfer time is relatively short on the network. (Note: In a couple of weeks I will post a username and password for the PLC so that you can call in with telnet and talk to it.)

Hugh
email: [email protected]
web: claymore.engineer.gvsu.edu/~jackh


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

Hennig Harden

> Hi, ... > > Finally, to say this one more time - I am using this for >another< PLC project which uses >interpreted< operations - not compiled. So a file > format like this becomes extremely useful for transfering the data between the PLC software and a remote programing client (and eventually an HMI). I can also transfer small segments of information to update the PLC while it is running, on-line. I initially wrote a flat file > structure for transferring programs, memory definitions and IO scans. For the PLC I wrote my own parser. This simplifies the issues of space, > speed, and interruptability. On the client end I started to write my own parser in Java, but then switched to an XML parser. To transfer the files I am using both serial lines and TCP/IP sockets. The transfer time is relatively short on the network. (Note: In a couple of weeks I will post a username and password for the PLC so that you can call in with telnet and talk to it.) Hi I think you already did a lot of things we want to do. We are working on a automation projekt using the IEC61131, trying to get it run on at least two hardware systems. Searching for a portable HMI we decied to use XML, generated in structured text (IEC61131). The HMI (embedded linux) should use an XSLT Processor, working with serial line or TCP/IP socket to display and control process. XSL and DTD files located at flash memory on HMI. Is there a industry specific DTD you are using? Is it a open source projekt you are working on? We would like to work on too.
 
Top