S
Dan wrote...
> It would be easier on all of us if there were as few of these abstract machines as possible, but the minumum realistic number is probably greater than one. <
IEC1131 provides Instruction List as a base language. Should a virtual machine for IL be the run time engine for this project ? The JVM is becoming some sort of industry standard in the IT world, maybe an ILVM could be the standard for the automation world. It does not (should not) restrict the languages that compile for the virtual machine.
> This is really a key question:
> If the definition of "PLC" is limited to something with a fixed:
>
> scan inputs
> compute logic (maybe with function block kludges)
> set outputs
>
> Then I see this project as limiting itself to technology that was at least obsolecent when Linux was invented. While it's important to
support that technology, and I realize that some members of this list are interested in nothing else, it's at least equally important to provide for evolution to more modern and effective approaches. Yes, we at Control Tech believe that we have one of these. I *do not* believe that it's the only possible one, nor am I trying to push it as part of the LinuxPLC, but I think that it would be a serious long term mistake to make such approaches excessively difficult to fit into this project.<
Yes.
This project (starting in 2000) needs to be careful about making the direct comparison of LinuxPLC == PLC circa 1970's. We are seeing this influence the concept already with people being adamant that Ladder is the only important language. Ladder is important, but so are other languages which have more power and flexibility and other advantages. Also the memory map being considered is pushing the project down a
particular design path. I know Modbus is important, but what about the complex structured variables you will want in your LinuxPLC for the future. Those Modbus extensions mentioned earlier could be extremely important (are the details available). Some consideration should be given to an object model for the user programs at an early stage also. IEC1131 provides a framework where Function Blocks
are the objects.
Scott Cornwall
www.psc.fp.co.nz
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
> It would be easier on all of us if there were as few of these abstract machines as possible, but the minumum realistic number is probably greater than one. <
IEC1131 provides Instruction List as a base language. Should a virtual machine for IL be the run time engine for this project ? The JVM is becoming some sort of industry standard in the IT world, maybe an ILVM could be the standard for the automation world. It does not (should not) restrict the languages that compile for the virtual machine.
> This is really a key question:
> If the definition of "PLC" is limited to something with a fixed:
>
> scan inputs
> compute logic (maybe with function block kludges)
> set outputs
>
> Then I see this project as limiting itself to technology that was at least obsolecent when Linux was invented. While it's important to
support that technology, and I realize that some members of this list are interested in nothing else, it's at least equally important to provide for evolution to more modern and effective approaches. Yes, we at Control Tech believe that we have one of these. I *do not* believe that it's the only possible one, nor am I trying to push it as part of the LinuxPLC, but I think that it would be a serious long term mistake to make such approaches excessively difficult to fit into this project.<
Yes.
This project (starting in 2000) needs to be careful about making the direct comparison of LinuxPLC == PLC circa 1970's. We are seeing this influence the concept already with people being adamant that Ladder is the only important language. Ladder is important, but so are other languages which have more power and flexibility and other advantages. Also the memory map being considered is pushing the project down a
particular design path. I know Modbus is important, but what about the complex structured variables you will want in your LinuxPLC for the future. Those Modbus extensions mentioned earlier could be extremely important (are the details available). Some consideration should be given to an object model for the user programs at an early stage also. IEC1131 provides a framework where Function Blocks
are the objects.
Scott Cornwall
www.psc.fp.co.nz
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc