Forcing

<clip>
> > 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?
>
Actually, it is when a system has been updated with new devices.

In one case (output), engineering found a better, more reliable, higher performance, (or whatever) vacuum valve that was "on" (sucking) when the output was high, in the other when the output was low (it was more of a bypass function).

In another case (input) we were using a reflective sensor to detect paper/no paper. When we found we could mount a through-beam sensor which would be more reliable, we found that it
returned the opposite polarity true signal when paper present in the detection area.

It might even be that we use the same logic in spite of the devices used, and it would be just a matter of wiring as to which device is used. The question is, is this invert table just another bit of programming or is it the province of the device wiring person?

I guess it's a matter if you want to have different programs for each device which differ only by polarity.

I believe have a different viewpoint from most PLC-users on the list. For many PLC users, it's either a single machine, or multiple identical machines, spec'ed and programmed nearly from scratch. In this case, it's not a hindrance that
I/O addresses have fixed, absolute locations, and polarity is decided in the machine design.

In my world, we build equipment based on multiple subassemblies that can be at any point in the sequence. This means that even though the logic for each submachine remains the same, the wiring positions change (and potentially the polarity, if the individual "point size" device changes)

It's like Mexican fast food. There's only about 6-10 different ingredients, but the amount and order of application of each ingredient give you a different end product. Our machines are similar.

Actually, it was this need that prompted me to write my own RLL-to-8051 assembly language converter about 15 years ago.. I had come from a
programming background and wanted to use logical names for input and output signals and all the PLC's allowed me was symbols like I0.3 or Q110.7, which meant nothing to me. Not to mention, when I changed code I would have to redefine all my symbols or have some symbols define some distance
(numerically) from the original symbols. If I had two of the same device I would basically have to rewrite the same control logic for each additional device.

I want to program a machine function one time, and hook up the correspondence table to real world points when the configuration is done. The closest I've seen to this is Step 7 software
which has function blocks encapsulating functions,
but the left and right sides of the block had all the interfacing signals to the logic, I's, O's, numerics, etc.

I've got to cut this short...

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
I think all signals that are output to hardware require a scaling factor. In the case of a bit the scale factor is either 1 or -1 or 0.
In instances where confusion is likely use the default scale factor of 1.

I think there is also secondary need that is somewhat related. There have been many times when I wished I could invert a rungs result before
writing it to the coil. I always ended up adding another rung to do the inversion. What if we had an inverting coil that be selected instead of
a normal coil? This would also address the "invert need" in an obvious and un-hidden way.

rickj

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
M
The inverting coil is specified in the IEC1131 instruction set.

> -----Original Message-----
> From: [email protected] [mailto:[email protected]]On
> Behalf Of Rick
>
> I think all signals that are output to hardware require a scaling factor. In the case of a bit the scale factor is either 1 or -1 or 0.
> In instances where confusion is likely use the default scale factor of 1.
>
> I think there is also secondary need that is somewhat related. There
> have been many times when I wished I could invert a rungs result before
> writing it to the coil. I always ended up adding another rung to do the
> inversion. What if we had an inverting coil that be selected instead of
> a normal coil? This would also address the "invert need" in an obvious
> and un-hidden way.
>
> rickj
>

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
<clip>
> In one case (output), engineering found a better, more reliable, higher
> performance, (or whatever) vacuum
> valve that was "on" (sucking) when the output was high, in the other when the
> output was low (it was more
> of a bypass function).
>
> In another case (input) we were using a reflective sensor to detect paper/no
> paper. When we found we could
> mount a through-beam sensor which would be more reliable, we found that it
> returned the opposite polarity true
> signal when paper present in the detection area.
>
> It might even be that we use the same logic in spite of the devices used, and
> it would be just a matter of wiring
> as to which device is used. The question is, is this invert table just
> another bit of programming or is it the province
> of the device wiring person?
>
> I guess it's a matter if you want to have different programs for each device
> which differ only by polarity.
>
> I believe have a different viewpoint from most PLC-users on the list. For
> many PLC users, it's either a single machine,
> or multiple identical machines, spec'ed and programmed nearly from scratch.
> In this case, it's not a hindrance that
> I/O addresses have fixed, absolute locations, and polarity is decided in the
> machine design.
>
> In my world, we build equipment based on multiple subassemblies that can be
> at any point in the sequence. This
> means that even though the logic for each submachine remains the same, the
> wiring positions change (and potentially the polarity, if the individual
> "point size" device changes)
>
> It's like Mexican fast food. There's only about 6-10 different ingredients,
> but the amount and order of application of
> each ingredient give you a different end product. Our machines are similar.
>
> Actually, it was this need that prompted me to write my own RLL-to-8051
> assembly language converter about 15 years ago.. I had come from a
> programming background and wanted to use logical names for input and output
> signals and all the PLC's allowed me was symbols like I0.3 or Q110.7, which
> meant nothing to me. Not to mention, when I changed code I would have to
> redefine all my symbols or have some symbols define some distance
> (numerically) from the original symbols. If I had two of the same device I
> would basically have to rewrite the same control logic for each additional
> device.
>
> I want to program a machine function one time, and hook up the correspondence
> table to real world points when the
> configuration is done. The closest I've seen to this is Step 7 software
> which has function blocks encapsulating functions,
> but the left and right sides of the block had all the interfacing signals to
> the logic, I's, O's, numerics, etc.
>
> I've got to cut this short...

>

Ok, sounds like avery good reason to have this feature. I will now change my tune slightly and say that inverts are similar to forces. The normal
forces have a global activation switch which when off disables all normal forces. When normal forces are on our PLC will make this apparent in some way but this will not prevent the code from working. The same applies for inverts with a seperate activation switch and indicator.


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, 26 Jan 2000, Rick wrote:

> I think all signals that are output to hardware require a scaling
> factor. In the case of a bit the scale factor is either 1 or -1 or 0.
> In instances where confusion is likely use the default scale factor of
> 1.

What would be the purpose of this scaling factor?
What would it do to a bit, word, float, int and all other data types?

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
 
R
For a logical (bit) a scaling of -1 would invert it and a scaling of 0 would disable it.

For the other data types the scaling number would be used to convert engineering units (i.e. inches, pounds, etc.) to voltage or current.

Rick

Dave West wrote:
>
> On Wed, 26 Jan 2000, Rick wrote:
>
> > I think all signals that are output to hardware require a scaling
> > factor. In the case of a bit the scale factor is either 1 or -1 or 0.
> > In instances where confusion is likely use the default scale factor of
> > 1.
>
> What would be the purpose of this scaling factor?
> What would it do to a bit, word, float, int and all other data types?
>
> >
> > I think there is also secondary need that is somewhat related. There
> > have been many times when I wished I could invert a rungs result before
> > writing it to the coil. I always ended up adding another rung to do the
> > inversion. What if we had an inverting coil that be selected instead of
> > a normal coil? This would also address the "invert need" in an obvious
> > and un-hidden way.
> >
> > rickj

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Thu, Jan 27, 2000 at 10:39:22AM -0800, Rick Jafrate wrote:
> For a logical (bit) a scaling of -1 would invert it and a scaling of 0
> would disable it.

> For the other data types the scaling number would be used to convert
> engineering units (i.e. inches, pounds, etc.) to voltage or current.

And then we can have thermocouple linearization...

Definitely "We'll Do That Later" stuff, thermocouples. But if you happen to see the spot where it'll go later, put a comment there saying so.

This should also handle gamma-correction and anything else people dream up.


> Dave West wrote:

> > On Wed, 26 Jan 2000, Rick wrote:

> > > I think all signals that are output to hardware require a scaling
> > > factor. In the case of a bit the scale factor is either 1 or -1 or
> > > 0. In instances where confusion is likely use the default scale
> > > factor of 1.

> > What would be the purpose of this scaling factor? What would it do to
> > a bit, word, float, int and all other data types?


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
 
Top