J
Sorry for entering this late... I have been away for one week (and you have <br>
been posting a lot since.) I really want to contribute but obviously I have to <br>
catch up....<br>
<br>
I will make some kind of bunched together reply to the older posts here about <br>
my point of view about things. Here may be things you already have agreed <br>
about since I am wring this on the fly as I am reading, sorry then:<br>
I will not continue to bunch things together like this and if someone wants to <br>
complain about it you don't have to write that to the entire list.<br>
<br>
I have (so far) only reached posts including the 14:th most things may be <br>
outdated... Some (or perhaps a lot) of this is things I probably already have <br>
said while it was at automationlist...<br>
<br>
<br>
First of all:<br>
I like the mascot!<br>
<br>
<br>
Second:<br>
Great job all of you! I have surely missed a lot by not reading this for a <br>
week!<br>
<br>
<br>
<br>
<br>
True/false:<br>
I think the best option is to have one bit, not a complete byte. Using one bit <br>
makes it:<br>
1. Take less space, might not be a real problem but anyway<br>
2. unambigous, no undefined states<br>
3. some code might be slower but not significantly much slower if coded <br>
correctly, some code (mostly driver code) will be faster if it can process the <br>
complete byte in one operation (depends on the mapping)<br>
I suppose that is what everyone finally agreed to anyway but anyway...<br>
<br>
<br>
Forcing inputs and outputs:<br>
As for the "invert" someone suggested, I thought of that as beeing nice too, <br>
but I see one possible disadvantage - performance. The assembler needed to <br>
code that will probably take some small fraction of more time than not <br>
allowing invert, and since it probably not will be used anyway - why waste, it <br>
would have been nice but I vote NO.<br>
<br>
<br>
About I/O scans:<br>
Different I/O:s need to be able to be scanned / set in different rates, the <br>
fact that one I/O point is slow (and not being a problem being slow) should <br>
not interfere with really fast I/O:s.<br>
For the sake of applying force tables, copying and applying force values can <br>
be done (as someone suggested) in the same operation. Perhaps the core should <br>
have a copy inputs from the shared memory to this pointer - function, and a <br>
copy these outputs (pointer) to their shared memory. Both functions using the <br>
force-tables invisible to the (brain).<br>
<br>
A question: if an output is forced, how is that output to be read by the <br>
logic? as the forced value or as the non-forced value? is the answer the same <br>
for the same control part setting it and for other control processes?<br>
Then answer should decide when the force table should be applied<br>
<br>
What about the inputs? Is there ONE force table for all inputs or one force <br>
table per controlling process?<br>
<br>
<br>
I think any control proces should be completely unaware of the force <br>
tables (unless they are local to that control process - quite unlikely) this <br>
is as I see it a core finction (or perhaps a I/O funcion)<br>
<br>
I think the analog I/O:s could have use of a force table too.<br>
<br>
<br>
<br>
Languages:<br>
I think Ladder should be supported. My personal opinion is that it is a <br>
efficient language for pure logic. It should be supported along with IL and <br>
FBD (from 61131-3). These three languages are easy to convert any program <br>
between. The other two languages in 61131-3 should be supported too (perhaps <br>
not immediately but quite soon).<br>
<br>
Those tree languages (IL, LD, FBD) should run from some kind of byte code. The <br>
editor should work with this byte code directly.<br>
<br>
The other two languages may be best implemented with some interpreter/compiler <br>
pair of their own.<br>
<br>
The controller itself should contain some kind of loadable modules allowing <br>
parts of a program to be written in different languages than other parts. Even <br>
pure C (or C++ if anyone wants that) control parts should be possible at the <br>
same time as the IL/LD/FBD interpreter<br>
<br>
<br>
I agree to the thin core philosophy- the discussion about languages then only <br>
becomes a discussion about in what order to do the controlling parts the core <br>
does load. If someone don't like a language (or don't use it for any other <br>
reason) that module simply isn't loaded...<br>
<br>
<br>
<br>
I agree that one output is set by only one controller. There may be some kind <br>
of method to allow one controller to set it at some time and another at some <br>
other time controlled by some more top level logic, otherwise it will be quite <br>
messy.<br>
<br>
<br>
I completely agree to the statement "Platform first, then controller"<br>
<br>
<br>
Data table config files:<br>
Why not use the names as they are defined in 61131-3<br>
I = input<br>
Q = output<br>
M = memory<br>
<br>
combined with:<br>
X (or none) single bit, ie digital<br>
B byte (8 bits)<br>
W word (16 bits)<br>
D double word (32 bits)<br>
L Long (quad) word (64 bits)<br>
<br>
this meaning:<br>
IB means input byte<br>
Q and QX means output bit<br>
and so on<br>
<br>
<br>
<br>
----------------------------------------<br>
P&L, the Academy of Automation<br>
Box 252, S-281 23 Hässleholm SWEDEN<br>
Tel: +46 451 49 460, Fax: +46 451 89 833<br>
E-mail: [email protected]<br>
Internet: http://www.pol.se/<br>
----------------------------------------<br>
<br>
<br>
<br>
_______________________________________________<br>
LinuxPLC mailing list<br>
[email protected]<br>
http://linuxplc.org/mailman/listinfo/linuxplc
been posting a lot since.) I really want to contribute but obviously I have to <br>
catch up....<br>
<br>
I will make some kind of bunched together reply to the older posts here about <br>
my point of view about things. Here may be things you already have agreed <br>
about since I am wring this on the fly as I am reading, sorry then:<br>
I will not continue to bunch things together like this and if someone wants to <br>
complain about it you don't have to write that to the entire list.<br>
<br>
I have (so far) only reached posts including the 14:th most things may be <br>
outdated... Some (or perhaps a lot) of this is things I probably already have <br>
said while it was at automationlist...<br>
<br>
<br>
First of all:<br>
I like the mascot!<br>
<br>
<br>
Second:<br>
Great job all of you! I have surely missed a lot by not reading this for a <br>
week!<br>
<br>
<br>
<br>
<br>
True/false:<br>
I think the best option is to have one bit, not a complete byte. Using one bit <br>
makes it:<br>
1. Take less space, might not be a real problem but anyway<br>
2. unambigous, no undefined states<br>
3. some code might be slower but not significantly much slower if coded <br>
correctly, some code (mostly driver code) will be faster if it can process the <br>
complete byte in one operation (depends on the mapping)<br>
I suppose that is what everyone finally agreed to anyway but anyway...<br>
<br>
<br>
Forcing inputs and outputs:<br>
As for the "invert" someone suggested, I thought of that as beeing nice too, <br>
but I see one possible disadvantage - performance. The assembler needed to <br>
code that will probably take some small fraction of more time than not <br>
allowing invert, and since it probably not will be used anyway - why waste, it <br>
would have been nice but I vote NO.<br>
<br>
<br>
About I/O scans:<br>
Different I/O:s need to be able to be scanned / set in different rates, the <br>
fact that one I/O point is slow (and not being a problem being slow) should <br>
not interfere with really fast I/O:s.<br>
For the sake of applying force tables, copying and applying force values can <br>
be done (as someone suggested) in the same operation. Perhaps the core should <br>
have a copy inputs from the shared memory to this pointer - function, and a <br>
copy these outputs (pointer) to their shared memory. Both functions using the <br>
force-tables invisible to the (brain).<br>
<br>
A question: if an output is forced, how is that output to be read by the <br>
logic? as the forced value or as the non-forced value? is the answer the same <br>
for the same control part setting it and for other control processes?<br>
Then answer should decide when the force table should be applied<br>
<br>
What about the inputs? Is there ONE force table for all inputs or one force <br>
table per controlling process?<br>
<br>
<br>
I think any control proces should be completely unaware of the force <br>
tables (unless they are local to that control process - quite unlikely) this <br>
is as I see it a core finction (or perhaps a I/O funcion)<br>
<br>
I think the analog I/O:s could have use of a force table too.<br>
<br>
<br>
<br>
Languages:<br>
I think Ladder should be supported. My personal opinion is that it is a <br>
efficient language for pure logic. It should be supported along with IL and <br>
FBD (from 61131-3). These three languages are easy to convert any program <br>
between. The other two languages in 61131-3 should be supported too (perhaps <br>
not immediately but quite soon).<br>
<br>
Those tree languages (IL, LD, FBD) should run from some kind of byte code. The <br>
editor should work with this byte code directly.<br>
<br>
The other two languages may be best implemented with some interpreter/compiler <br>
pair of their own.<br>
<br>
The controller itself should contain some kind of loadable modules allowing <br>
parts of a program to be written in different languages than other parts. Even <br>
pure C (or C++ if anyone wants that) control parts should be possible at the <br>
same time as the IL/LD/FBD interpreter<br>
<br>
<br>
I agree to the thin core philosophy- the discussion about languages then only <br>
becomes a discussion about in what order to do the controlling parts the core <br>
does load. If someone don't like a language (or don't use it for any other <br>
reason) that module simply isn't loaded...<br>
<br>
<br>
<br>
I agree that one output is set by only one controller. There may be some kind <br>
of method to allow one controller to set it at some time and another at some <br>
other time controlled by some more top level logic, otherwise it will be quite <br>
messy.<br>
<br>
<br>
I completely agree to the statement "Platform first, then controller"<br>
<br>
<br>
Data table config files:<br>
Why not use the names as they are defined in 61131-3<br>
I = input<br>
Q = output<br>
M = memory<br>
<br>
combined with:<br>
X (or none) single bit, ie digital<br>
B byte (8 bits)<br>
W word (16 bits)<br>
D double word (32 bits)<br>
L Long (quad) word (64 bits)<br>
<br>
this meaning:<br>
IB means input byte<br>
Q and QX means output bit<br>
and so on<br>
<br>
<br>
<br>
----------------------------------------<br>
P&L, the Academy of Automation<br>
Box 252, S-281 23 Hässleholm SWEDEN<br>
Tel: +46 451 49 460, Fax: +46 451 89 833<br>
E-mail: [email protected]<br>
Internet: http://www.pol.se/<br>
----------------------------------------<br>
<br>
<br>
<br>
_______________________________________________<br>
LinuxPLC mailing list<br>
[email protected]<br>
http://linuxplc.org/mailman/listinfo/linuxplc