Like about everything (too long)

Thread Starter

Johan Bengtsson

Jan 17, 2000

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

R A Peterson

Jan 18, 2000

In a message dated 1/17/00 12:40:09 PM Pacific Standard Time,
[email protected] writes:

>
> A question: if an output is forced, how is that output to be read by the
> logic? as the forced value or as the non-forced value? is the answer the
> same
> for the same control part setting it and for other control processes?
> Then answer should decide when the force table should be applied
>

Interesting question. PLC5s treat a force on an output as if it was a jumper wire on the physical output thus the actual force status of an output cannot affect other logic w/i the program. Other processors treat a forced output as being either on or off (as forced) inside the program as well. If the force is inside the I/O server, then it almost has to be done like the PLC5.
If its in the RLL engine, then it can be either way. My suggestion is to put it in the I/O task. That way its consistent with the most common PLCs.

> What about the inputs? Is there ONE force table for all inputs or one
force table per controlling process?
>
> I think any control proces should be completely unaware of the force
> tables (unless they are local to that control process - quite unlikely)
this
>
> is as I see it a core finction (or perhaps a I/O funcion)
>
> I think the analog I/O:s could have use of a force table too.
>

A nice idea.

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

Jiri Baum

Jan 18, 2000

[email protected]:
> Forcing inputs and outputs: As for the "invert" someone suggested, I
> thought of that as beeing nice too, but I see one possible disadvantage -
> performance. The assembler needed to code that will probably take some
> small fraction of more time than not allowing invert, and since it
> probably not will be used anyway - why waste, it would have been nice but
> I vote NO.

I didn't think there'll be any perfomance hit on it. Once you have force tables, it's just a question of doing (data | force) ^ invert
rather than (data | force_on) & not_force_off

> A question: if an output is forced, how is that output to be read by the
> logic? as the forced value or as the non-forced value? is the answer the
> same for the same control part setting it and for other control
> processes? Then answer should decide when the force table should be
> applied

If we let forces be applied to internal coils, there's really only one answer to that...

(But that clashes with inverts! Hmm...)

Jiri
--
Jiri Baum <[email protected]>
On the Internet, nobody knows if you are a @{[@{[open(0),<0>]}-1]}-line
perl script...

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

Stan Brown

Jan 18, 2000

On Mon Jan 17 15:46:06 2000 wrote...
>
>In a message dated 1/17/00 12:40:09 PM Pacific Standard Time,
>[email protected] writes:
>
>>
>> A question: if an output is forced, how is that output to be read by the
>> logic? as the forced value or as the non-forced value? is the answer the
>> same
>> for the same control part setting it and for other control processes?
>> Then answer should decide when the force table should be applied >>
>
>Interesting question. PLC5s treat a force on an output as if it was a jumper
>wire on the physical output thus the actual force status of an output cannot
>affect other logic w/i the program. Other processors treat a forced output
>as being either on or off (as forced) inside the program as well. If the
>force is inside the I/O server, then it almost has to be done like the PLC5.
>If its in the RLL engine, then it can be either way. My suggestion is to put
>it in the I/O task. That way its consistent with the most common PLCs.

That is the what I had in mind.

>> What about the inputs? Is there ONE force table for all inputs or one force table per controlling process?<<
>>
>> I think any control proces should be completely unaware of the force
>> tables (unless they are local to that control process - quite unlikely) this <<

I disagree. Forces need to be handled by the I/O scanner task. Therefore that are global. Therefore ONE force table per I/O scanner task.

--
Stan Brown [email protected] 843-745-3154
Westvaco
Charleston SC.

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

Johan Bengtsson

Jan 18, 2000

> I disagree. Forces need to be handled by the I/O scanner task. Therefore that are global. Therefore ONE force table per I/O scanner task.<

This is not a disagreement, I think it should be that way, I just wanted to raise the question

----------------------------------------
P&L, the Academy of Automation
Box 252, S-281 23 Hässleholm SWEDEN
Tel: +46 451 49 460, Fax: +46 451 89 833
E-mail: [email protected]
Internet: http://www.pol.se/
----------------------------------------

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

Johan Bengtsson

Jan 18, 2000

>> Forcing inputs and outputs: As for the "invert" someone suggested, I
>> thought of that as beeing nice too, but I see one possible disadvantage -
>> performance. The assembler needed to code that will probably take some
>> small fraction of more time than not allowing invert, and since it
>> probably not will be used anyway - why waste, it would have been nice but
>> I vote NO.
>
>I didn't think there'll be any perfomance hit on it. Once you have force
>tables, it's just a question of doing
> (data | force) ^ invert
>rather than
> (data | force_on) & not_force_off
>

you are of course right

>> A question: if an output is forced, how is that output to be read by the
>> logic? as the forced value or as the non-forced value? is the answer the
>> same for the same control part setting it and for other control
>> processes? Then answer should decide when the force table should be
>> applied
>
>If we let forces be applied to internal coils, there's really only one
>answer to that...
>
>(But that clashes with inverts! Hmm...)

As I see it, the logic should really not be aware of the force, meaning the I/O mapper should handle it. You are right, I didn't think of the posibility for trouble with the invert if placed elsewhere than in the I/O handler

----------------------------------------
P&L, the Academy of Automation
Box 252, S-281 23 Hässleholm SWEDEN
Tel: +46 451 49 460, Fax: +46 451 89 833
E-mail: [email protected]
Internet: http://www.pol.se/
----------------------------------------

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

Mark Hutton

Jan 18, 2000

My 2p......

Forcing sets the state of the bit/word/byte to the forced value and keeps it there. This in no way clashes with the concept of the 'invert' as it is an independent feature.

I would suggest, though, that to avoid possible confusion, that we document the point at which the force is applied in relation to when the invert is applied.

e.g.

Ouputs updated by logic engine -> Forces applied -> Inverts applied.
(example for discussion only).

-----Original Message-----
From: [email protected] [mailto:[email protected]]On
Behalf Of Jiri Baum

[email protected]:
> Forcing inputs and outputs: As for the "invert" someone suggested, I thought of that as beeing nice too, but I see one possible disadvantage -
> performance. ... A question: if an output is forced, how is that output to be read by the
> logic? as the forced value or as the non-forced value? is the answer the
> same for the same control part setting it and for other control
> processes? Then answer should decide when the force table should be
> applied

If we let forces be applied to internal coils, there's really only one
answer to that...

(But that clashes with inverts! Hmm...)

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

Johan Bengtsson

Jan 19, 2000

I agree completely to your point.

for the suggested apply order, I have currently no idea of whatever really seems to be the most logical way.

This brings up another thought:
An invert could be viewed as "rescaling the digital input to another scale", how about designing in rescaling in the analog I/O:s?
This can wait, I think it would be nice to have there but not necesary.

/Johan Bengtsson

----------------------------------------
P&L, the Academy of Automation
Box 252, S-281 23 Hässleholm SWEDEN
Tel: +46 451 49 460, Fax: +46 451 89 833
E-mail: [email protected]
Internet: http://www.pol.se/
----------------------------------------

-----Original Message-----
From: MIME :[email protected] [SMTP:MIME
:[email protected]]

My 2p......

Forcing sets the state of the bit/word/byte to the forced value and keeps it there. This in no way clashes with the concept of the 'invert' as it is an independent feature.

I would suggest, though, that to avoid possible confusion, that we document the point at which the force is applied in relation to when the invert is applied.

e.g.

Ouputs updated by logic engine -> Forces applied -> Inverts applied.
(example for discussion only).

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

Jiri Baum

Jan 20, 2000

On Tue, Jan 18, 2000 at 10:12:59PM -0600, [email protected] wrote:
> >> A question: if an output is forced, how is that output to be read by
> >> the logic? as the forced value or as the non-forced value? is the
> >> answer the same for the same control part setting it and for other
> >> control processes? Then answer should decide when the force table
> >> should be applied

> >If we let forces be applied to internal coils, there's really only one answer to that...

> >(But that clashes with inverts! Hmm...)

> As I see it, the logic should really not be aware of the force, meaning
> the I/O mapper should handle it.

Well, if the core handles it, the logic engine(s) won't really be aware of it either, except for readback. And not having true readback is a
double-edged sword, really.

Forcing internal coils may be a useful feature that you can only get with true readback.

> You are right, I didn't think of the posibility for trouble with the invert if placed elsewhere than in the I/O handler 
On the Internet, nobody knows if you are a @{[@{[open(0),<0>]}-1]}-line
perl script...

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

Stan Brown

Jan 21, 2000

On Thu Jan 20 20:01:38 2000 Jiri Baum wrote...
>
>I didn't think of it either until I wrote that.

Invert tables are something that you want. Fine I don't see that they are useful, but nothing forces me to ever use them. However i cannot accept mixing them with forces.

Bear in mind that many countries have regulatory bodies that have a say about how these machines must work if they are to be deployed in certain applications, such as flame safety systems for boilers.

One of their requirements is that no forces may be present for the system to run.

There are others we will need to talk about later in the design.

--
Stan Brown [email protected] 843-745-3154
Westvaco
Charleston SC.

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

Thread starter	Similar threads	Forum	Replies	Date
	Neutral Current is too much high	Power Generation	3	Dec 19, 2023
A	rslogix 5000 8th edition too old can't open an offline copy of the program because of error message "source not available"	General Automation Chat	3	Sep 28, 2023
Z	Question: Holding Register can do everything?	Modbus	3	Dec 17, 2020
H	Clutch Disengaging Too Early During Startup	Power Generation	1	Oct 16, 2018
G	PLC database, keeping track of everything	Programmable Logic Controller - PLC	3	Jun 12, 2012