Forcing

G

Thread Starter

Gerry Hagberg

Hi again,

My initial reaction to the "invert" idea was, I guess, negative. It seemed to come from 'way out in left field. After consideration, though, I concede that it could be useful in some situations. e.g. when commissioning and you want to keep a machine or process running while
you correct the program.

Bear in mind that the 'Force Invert(s)' are enabled and disabled in toto along with the on and off forces. Forces should only ever be enabled
temporarily.

In theory, it should only be necessary to be able to force points in the I/O image tables. The rest of the data table is derivative.

Gerry
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Wed, Jan 19, 2000 at 07:08:23AM -0500, Stan Brown wrote:
> On Wed Jan 19 05:47:46 2000 Gerry Hagberg wrote...
...
> >Bear in mind that the 'Force Invert(s)' are enabled and disabled in toto
> >along with the on and off forces. Forces should only ever be enabled
> >temporarily.

> That is not how I see it. If we do that, then the inverts are
> useless for the purpose jiri wants them for. The need to
> independent of the forces, so that the inverts can be left active,
> while the forces are not. Otherwise the are useless IMHO

Why in the world would they be useless?

What's the problem with removing all the on/off forces and leaving the invert forces in?

(That's what user-interfaces are for - to translate between your point of view as a user and the program's convenience. In this case, the program's convenience would be on and invert forces only; off forces would be handled
as an invert+on force.)

> >In theory, it should only be necessary to be able to force points in the I/O image tables. The rest of the data table is derivative. < <

> Is that not already clearly understood?

No, not really.

- sometimes it may be easier to force a single internal coil rather than numerous I/O points
- some internal coils work as latches, keeping their value over multiple scans
- especially data registers, timers and counters may be difficult to affect other than by direct force

You know that yourself, hence the "persistence" discussion.


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
 
S
On Thu Jan 20 20:14:41 2000 Jiri Baum wrote...
>
>On Wed, Jan 19, 2000 at 07:08:23AM -0500, Stan Brown wrote:
>> On Wed Jan 19 05:47:46 2000 Gerry Hagberg wrote...
>...
>> >Bear in mind that the 'Force Invert(s)' are enabled and disabled in toto
>> >along with the on and off forces. Forces should only ever be enabled
>> >temporarily.
>
>> That is not how I see it. If we do that, then the inverts are
>> useless for the purpose jiri wants them for. The need to
>> independent of the forces, so that the inverts can be left active,
>> while the forces are not. Otherwise the are useless IMHO
>
>Why in the world would they be useless?

Because it is _very poor_ practice to leave a machine or process with the "forces enabled" light on. Not only is it bad practice. At many sites it is just plain a violation of the safety rules.
>
>What's the problem with removing all the on/off forces and leaving the invert forces in?
>

Jiri, you still are not relating to the way things are done in the real world. Please get a copy of say an AB programming manual, and read the section on forces. As has been said by several people here, who clearly do real world PLC code for a living, they are the equivalent of putting a wire jumper on the i/O. That's all.

For instance a forced output is never seen by the logic engine. Look this is a safety issue here, and we need to very closely model
existing practice.

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

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

Johan Bengtsson

As I see this about inverting - it should not be visible as a force to anyone. It is a completely different thing defined wherever the inputs and outputs are defined. It is however implemented using the very same instructions implementing the forces. That don't make it a force it is just
a way of having a possibility to define a input or output as inverted and implement it in a way that don't loose any processor time.

You do not force a I/O to be inverted, you force it to be 0 or 1. When you remove the force it goes back to whatever mode it was in before (inverted or not inverted) (as defined in the I/O
definiton wherever and whatever that is).

If you don't like inverts - don't define the I/O:s as inverted and you will *never* see them.

One point to remember is to be REALLY clear about in what order forces and inverts are applied when they both exist. This have nothing to do with the actual implementation but is more a logical thing about how the flags are to be set. My suggestion is that the forces either be "outside" or "inside"
the inverts.



/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]]

On Thu Jan 20 20:14:41 2000 Jiri Baum wrote...

>What's the problem with removing all the on/off forces and leaving the invert forces in?
>

Jiri, you still are not relating to the way things are done in the real world. Please get a copy of say an AB programming manual, and read the section on forces. As has been said by several people here, who clearly do real world PLC code for a living, they are the equivalent of putting a wire jumper on the i/O. That's all.

For instance a forced output is never seen by the logic engine. Look this is a safety issue here, and we need to very closely model
existing practice.

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Fri, Jan 21, 2000 at 08:36:02AM -0500, Stan Brown wrote:
> On Thu Jan 20 20:14:41 2000 Jiri Baum wrote...
> >On Wed, Jan 19, 2000 at 07:08:23AM -0500, Stan Brown wrote:
...
> >> That is not how I see it. If we do that, then the inverts are
> >> useless for the purpose jiri wants them for. The need to
> >> independent of the forces, so that the inverts can be left active,
> >> while the forces are not. Otherwise the are useless IMHO

> >Why in the world would they be useless?

> Because it is _very poor_ practice to leave a machine or process
> with the "forces enabled" light on. Not only is it bad practice. At
> many sites it is just plain a violation of the safety rules.

Oh, you're confusing the outside representation and the implementation.

How it's implemented and how it's presented to the users are two different matters. The user supplies three tables: force on/off tables and an
inversion table. Something will take them and combine them into quite a different pair of tables: a force-on table and an invert table.

> >What's the problem with removing all the on/off forces and leaving the
> >invert forces in?

> Jiri, you still are not relating to the way things are done in the
> real world. Please get a copy of say an AB programming manual, and
> read the section on forces.

We aren't at the "writing-the-manual" stage. We are discussing the implementation. In the implementation, it may be convenient to combine the two functions (forces and inversions).

Neither you nor I have access to the details of AB's implementation of forces. Getting the manual is pointless, because it explains how it looks
from the outside, not necessarily what goes on under the bonnet.


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
 
S
<clip>
>> >Why in the world would they be useless?
>
>> Because it is _very poor_ practice to leave a machine or process
>> with the "forces enabled" light on. Not only is it bad practice. At
>> many sites it is just plain a violation of the safety rules.
>
>Oh, you're confusing the outside representation and the implementation.
>
>How it's implemented and how it's presented to the users are two different
>matters. The user supplies three tables: force on/off tables and an
>inversion table. Something will take them and combine them into quite a
>different pair of tables: a force-on table and an invert table.

OK, but to the user the force off/on needs to be represented on the same screen, and enabled/disabled and cleared (as a set) all at once. It of course is edit-able at the bit level. So to a user he sees the forces as 0 - force off 1 - force on . - pass unchanged.
>
>> >What's the problem with removing all the on/off forces and leaving the
>> >invert forces in?
>
>> Jiri, you still are not relating to the way things are done in the
>> real world. Please get a copy of say an AB programming manual, and
>> read the section on forces.
>
>We aren't at the "writing-the-manual" stage. We are discussing the
>implementation. In the implementation, it may be convenient to combine the
>two functions (forces and inversions).

If you say so. It worries me though.

>Neither you nor I have access to the details of AB's implementation of
>forces. Getting the manual is pointless, because it explains how it looks
>from the outside, not necessarily what goes on under the bonnet.
>
Actually it should be easy enough to upload one and look t it, given Ron's code.

Right Ron?


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

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
>How it's implemented and how it's presented to the users are two different
>matters. The user supplies three tables: force on/off tables and an
>inversion table. Something will take them and combine them into quite a
>different pair of tables: a force-on table and an invert table.
>

Pardon me, but what is an "invert table?"

Ron Davis
[email protected]



_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
S
On Mon Jan 24 09:48:51 2000 Ron Davis wrote...
>
>Pardon me, but what is an "invert table?"
>

Jiri's baby :) It allows for inverting the state of an input before it gets to the logic engine.

He's to lazy to hook it up to the right contact on the field device :) :) :)

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

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
In a message dated 1/24/00 10:46:28 AM Eastern Standard Time, [email protected]
writes:
> On Mon Jan 24 09:48:51 2000 Ron Davis wrote...
> >
> >>How it's implemented and how it's presented to the users are two different
> >>matters. The user supplies three tables: force on/off tables and an
> >>inversion table. Something will take them and combine them into quite a
> >>different pair of tables: a force-on table and an invert table.
> >>
> >Pardon me, but what is an "invert table?"
> >
> Jiri's baby :) It allows for inverting the state of an input before it
> gets to the logic engine.
>
> He's to lazy to hook it up to the right contact on the field device :) :) :)
>
Inversions may be useful on the output side as well.

This way field devices can be changed without changing the program logic. I've dealt with changes in vacuum valves which required inverted the output. When we've gone from reflective
to through-beam sensors, we changed the "senses material" state of the input.

(Actually, when I've done higher level language program, I've define point objects as having an
ActiveHigh/~ActiveLow characteristic, which would pass/invert IsOn() or TurnOn() calls...same idea)


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Tue, 25 Jan 2000, Gerry Hagberg wrote:

> >How it's implemented and how it's presented to the users are two different
> >matters. The user supplies three tables: force on/off tables and an
> >inversion table. Something will take them and combine them into quite a
> >different pair of tables: a force-on table and an invert table.
>
> If I recall, the idea of "inverts" came up because there was an unused
> combination of bits in the proposed force tables. Now it seems that a
> whole new table is proposed. Let's see...3 bits... that's 8 possible
> states.... we've only defined 4....what to do with all those unused combinations? <

From the sequence the posts arrived here it was the other way round. Someone said we need force tables and someone said inversion would be nice
and someone said NO! and someone said why not there is a spare combination in the force table bits and someone said...................

Dave West E-Mail: [email protected]
Semiras Projects Ltd. PGP public key available on request.


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Tue Jan 25 00:08:05 2000 wrote...
>
>In a message dated 1/24/00 10:46:28 AM Eastern Standard Time, [email protected]
>writes:
>> On Mon Jan 24 09:48:51 2000 Ron Davis wrote...
>> >
>> >>How it's implemented and how it's presented to the users are two different
>> >>matters. The user supplies three tables: force on/off tables and an
>> >>inversion table. Something will take them and combine them into quite a
>> >>different pair of tables: a force-on table and an invert table.
>> >>
>> >
>> >Pardon me, but what is an "invert table?"
>> >
>> Jiri's baby :) It allows for inverting the state of an input before it
>> gets to the logic engine.
>>
>> He's to lazy to hook it up to the right contact on the field device :) :) :)
>>
>Inversions may be useful on the output side as well.

This is getting out of control here. When an application programmer sees an output on, he should be able to have confidence that we intend to have the real output on. Else we will be changing lots of output modules :-(

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

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
<clip>
> >Inversions may be useful on the output side as well.
>
> This is getting out of control here. When an application programmer sees
> an output on, he should be able to have confidence that we intend to
> have the real output on. Else we will be changing lots of output modules :-( <

Good Point Stan. We'd gotten to that conclusion when designing the HMI. Not only did I/O signal have a polarity, but they also had a "how do I show this?" which didn't necessarily jive with the I/O Led's, which IS a problem.

But there have been several times when I wished I/O modules had a polarity switch.

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

Gerry Hagberg

If I recall, the idea of "inverts" came up because there was an unused combination of bits in the proposed force tables. Now it seems that a
whole new table is proposed. Let's see...3 bits... that's 8 possible states.... we've only defined 4....what to do with all those unused
combinations?

This show's getting silly! Does anybody have the rubber chicken?

Gerry

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Tue, Jan 25, 2000 at 08:40:07AM -0500, [email protected] wrote:
> In a message dated 1/25/00 7:02:13 AM Eastern Standard Time, [email protected] writes:
(snip)
> >
> > This is getting out of control here. When an application programmer sees
> > an output on, he should be able to have confidence that we intend to
> > have the real output on. Else we will be changing lots of output
> > modules :-(

The application programmer could check the output configuration to see if the output is inverted. Inverts (if supported) would be optional, and presumably would be used for some reason which the application programmer should certainly be aware of. I'm not advocating inverts necessarily, but if some find them useful, then dumbing-down the design for the benefit of a lowest-common-denominator end user does not strike me as sound reasoning.

>
> Good Point Stan. We'd gotten to that conclusion when designing the HMI. Not
> only did I/O signal have
> a polarity, but they also had a "how do I show this?" which didn't
> necessarily jive with the I/O Led's, which
> IS a problem.

I/O polarity should not be hidden, and the HMI may need to take steps to clarify where things are inverted. I have used inverts on both I and O, but only for a good reason. They can definitely be confusing, and perhaps the wise choice might be to not use them in the average application (whatever that is).

> But there have been several times when I wished I/O modules had a polarity
> switch.

--
Ken Irving
Trident Software
[email protected]


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

Johan Bengtsson

The two bits originally proposed are the ones used each scan the other three bits are used to make the two bit table and the unused combinations are not really that unused all of them

like this:

force table invert table force/inv table
high low force invert
0 0 0 0 0
0 0 1 0 1
0 1 0 1 1
0 1 1 1 1*
1 0 0 1 1
1 0 1 1 0*
1 1 0 illegal state
1 1 1 illegal state

*this depends on if the force is applied before of after the invert In this example the calculations done are: (value|force)^invert
and is one way to solve it.

Forcing high and low at the same time is illegal
The force table are changed form one place and the invert table is changed from a completely different place. Whenever anyone changes the force/inv table have to be changed according to the new state.


/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]]

If I recall, the idea of "inverts" came up because there was an unused combination of bits in the proposed force tables. Now it seems that a whole new table is proposed. Let's see...3 bits... that's 8 possible states.... we've only defined 4....what to do with all those unused
combinations?

This show's getting silly! Does anybody have the rubber chicken?

Gerry


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


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Tue, 25 Jan 2000, Stan Brown wrote:

> On Tue Jan 25 00:08:05 2000 wrote...
> >
> >In a message dated 1/24/00 10:46:28 AM Eastern Standard Time, [email protected]
> >writes:
> >> On Mon Jan 24 09:48:51 2000 Ron Davis wrote...
> >> >
> >> >>How it's implemented and how it's presented to the users are two different
> >> >>matters. The user supplies three tables: force on/off tables and an
> >> >>inversion table. Something will take them and combine them into quite a
> >> >>different pair of tables: a force-on table and an invert table.
> >> >>
> >> >Pardon me, but what is an "invert table?"
> >> >
> >> Jiri's baby :) It allows for inverting the state of an input before it
> >> gets to the logic engine.
> >>
> >> He's to lazy to hook it up to the right contact on the field device :)
> >>
> >Inversions may be useful on the output side as well.
>
> This is getting out of control here. When an application programmer sees
> an output on, he should be able to have confidence that we intend to
> have the real output on. Else we will be changing lots of output modules :-(

I agree with Stan here. I think this invert thingy is OK as a force where a new application is being installed and you find the programme does not behave properly. You realise that some I/O has been wired backwards and as a confidence check you apply an invert. Everything works ok. The very next thing you do is change the wiring or the programme to work without the invert and update the documentation. I would not accept any plant that had an active invert during normal production runs. There is no need for them in a production run and they only add complication (read confusion). Impliment the inverts by all means but they are a force!!!!!!!!!!!!!!!!!!

Dave West E-Mail: [email protected]
Semiras Projects Ltd. PGP public key available on request.


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Tue, 25 Jan 2000 [email protected] wrote:
<clip>
> > >Inversions may be useful on the output side as well.
> >
> > This is getting out of control here. When an application programmer sees
> > an output on, he should be able to have confidence that we intend to
> > have the real output on. Else we will be changing lots of output
> > modules :-(

> Good Point Stan. We'd gotten to that conclusion when designing the HMI. Not
> only did I/O signal have
> a polarity, but they also had a "how do I show this?" which didn't
> necessarily jive with the I/O Led's, which
> IS a problem.
>
> But there have been several times when I wished I/O modules had a polarity
> switch.

Why? Is this because you got to site and found the information you had been given was inverted?

Dave West E-Mail: [email protected]
Semiras Projects Ltd. PGP public key available on request.


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Tue, 25 Jan 2000, Ken Irving wrote:

> On Tue, Jan 25, 2000 at 08:40:07AM -0500, [email protected] wrote:
> > In a message dated 1/25/00 7:02:13 AM Eastern Standard Time, [email protected] writes:
> (snip)
> > > This is getting out of control here. When an application programmer sees
> > > an output on, he should be able to have confidence that we intend to
> > > have the real output on. Else we will be changing lots of output modules :-(
>
> The application programmer could check the output configuration to see
> if the output is inverted. Inverts (if supported) would be optional,
> and presumably would be used for some reason which the application
> programmer should certainly be aware of. I'm not advocating inverts
> necessarily, but if some find them useful, then dumbing-down the design
> for the benefit of a lowest-common-denominator end user does not strike
> me as sound reasoning.

How many times does an application get a visit and of those how many of those visits are done by the original application programmer. Not to
mention what happens when he goes on holliday for a few weeks.

All applications should be written to the lowest common denominator. IE. blatantly obvious what it does. Inverts will hide this.

> > Good Point Stan. We'd gotten to that conclusion when designing the HMI. Not
> > only did I/O signal have
> > a polarity, but they also had a "how do I show this?" which didn't
> > necessarily jive with the I/O Led's, which
> > IS a problem.
>
> I/O polarity should not be hidden, and the HMI may need to take
> steps to clarify where things are inverted. I have used inverts
> on both I and O, but only for a good reason. They can definitely
> be confusing, and perhaps the wise choice might be to not use them
> in the average application (whatever that is).

I can see where an HMI may want to invert an I/O point but cannot see where the PLC in a production run would need to. As such I say an invert IS a force and should be treated as such!!!!!!

> > But there have been several times when I wished I/O modules had a polarity
> > switch.

Dave West E-Mail: [email protected]
Semiras Projects Ltd. PGP public key available on request.


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Wed, Jan 26, 2000 at 10:03:17AM +0000, Dave West wrote:
>
> I can see where an HMI may want to invert an I/O point but cannot see
> where the PLC in a production run would need to. As such I say an invert
> IS a force and should be treated as such!!!!!!

There might be some uses for this sort of controller that do not involve industrial production runs. Some controllers, for instance, are doomed to forever control normally-open zone heating valves, and inverting the output sense wrt the tagname sense can make sense, as a convenience.

In any case, I'm not writing the I/O code for the LinuxPLC, just trying to offer another perspective. I won't lose any sleep if the I/O system doesn't handle inverts.

--
Ken Irving
Trident Software
[email protected]


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