S
Stan Brown
On Sun Jan 16 06:52:55 2000 Jiri Baum wrote...
>
>Mark Hutton:
>> What shade of gray/grey?
>
>> Physical I/O impinges on the Physical world through a piece of hardware
>> which changes a physical quantity (usually voltage or current).
>
>> Internal relays are storage flags within a PLC application program. They
>> are the same as all other program variables.
>
>> Internal data memory can be accessed via communications channels, etc.
>
>All known communications channels work by changing a physical quantity
>(usually voltage or current).
>
>
>Stan was distinguishing between an internal relay, and a PLC output
>connected only to the input of another PLC. But if I interpret the wire
>between the two PLCs as a communication channel, the difference disappears!
We seem to be a long way apart on this point.
My definition is dirt simple, is it or is it not a real world output.
>
>Jiri Baum:
>> >I have no problem with `black' and `white', it's `grey' that bothers me.
>
>> >What is the difference between an internal relay inside a PLC (which
>> >does nothing but affect its control flow) and an output connected to the
>> >input of another PLC (which does nothing but affect its control flow)?
>
>> One switches a transitor to change the voltage on an opto isolated input;
>> the other doesn't.
>... (several real differences, but none conceptual) ...
>> operating times ( a relay or contactor in the real world may take upto
>> 50mS to operate).
>
>OK, I'd have probably thought of most of those given time (and "the wire
>can break" that somebody else raised).
>
>My question is: given that, as you write, "[t]he two may still perform the
>same function in the second PLCs application program", why should they be
>treated differently?
>
>> >I also don't see how you'll arrange for two modules to be able to hand
>> >control of an output to each other without sinking into a quagmire of
>> >potential problems. Certainly not in stepladder.
>
>> This is one of the big problems with softPLCs. It may not be easy, but it
>> must either be accomplished or the application developer must have
>> readback on every critical output (real or otherwise). You don't want one
>> logic processor thinking that it has stopped a motor from running while
>> another logic processor has just started it. Do that and you could be for
>> trouble.
>
>It's certainly not an easy problem, and we're going to have to solve it
>sooner or later; but I'm against putting in broken-as-designed solutions
>that we'll have to be backwards-compatible with later.
>
A design that allows multiple logic engines to set a given physical output is broken by design. I am unwilling to participate in a project with this design.
>And, on the other hand, wouldn't it be just as serious for one module to
>think it has requested that the motor stop while another just requested
>that it start? That's what an internal relay can mean, and that's why any
>interlocking mechanism should apply to internal relays just as much as to
>outputs.
>
>On the third hand, you wouldn't want the module that's supposed to stop the
>motor be deadlocked because it couldn't grab some signal light.
>
--
Stan Brown [email protected] 843-745-3154
Westvaco
Charleston SC.
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
>
>Mark Hutton:
>> What shade of gray/grey?
>
>> Physical I/O impinges on the Physical world through a piece of hardware
>> which changes a physical quantity (usually voltage or current).
>
>> Internal relays are storage flags within a PLC application program. They
>> are the same as all other program variables.
>
>> Internal data memory can be accessed via communications channels, etc.
>
>All known communications channels work by changing a physical quantity
>(usually voltage or current).
>
>
>Stan was distinguishing between an internal relay, and a PLC output
>connected only to the input of another PLC. But if I interpret the wire
>between the two PLCs as a communication channel, the difference disappears!
We seem to be a long way apart on this point.
My definition is dirt simple, is it or is it not a real world output.
>
>Jiri Baum:
>> >I have no problem with `black' and `white', it's `grey' that bothers me.
>
>> >What is the difference between an internal relay inside a PLC (which
>> >does nothing but affect its control flow) and an output connected to the
>> >input of another PLC (which does nothing but affect its control flow)?
>
>> One switches a transitor to change the voltage on an opto isolated input;
>> the other doesn't.
>... (several real differences, but none conceptual) ...
>> operating times ( a relay or contactor in the real world may take upto
>> 50mS to operate).
>
>OK, I'd have probably thought of most of those given time (and "the wire
>can break" that somebody else raised).
>
>My question is: given that, as you write, "[t]he two may still perform the
>same function in the second PLCs application program", why should they be
>treated differently?
>
>> >I also don't see how you'll arrange for two modules to be able to hand
>> >control of an output to each other without sinking into a quagmire of
>> >potential problems. Certainly not in stepladder.
>
>> This is one of the big problems with softPLCs. It may not be easy, but it
>> must either be accomplished or the application developer must have
>> readback on every critical output (real or otherwise). You don't want one
>> logic processor thinking that it has stopped a motor from running while
>> another logic processor has just started it. Do that and you could be for
>> trouble.
>
>It's certainly not an easy problem, and we're going to have to solve it
>sooner or later; but I'm against putting in broken-as-designed solutions
>that we'll have to be backwards-compatible with later.
>
A design that allows multiple logic engines to set a given physical output is broken by design. I am unwilling to participate in a project with this design.
>And, on the other hand, wouldn't it be just as serious for one module to
>think it has requested that the motor stop while another just requested
>that it start? That's what an internal relay can mean, and that's why any
>interlocking mechanism should apply to internal relays just as much as to
>outputs.
>
>On the third hand, you wouldn't want the module that's supposed to stop the
>motor be deadlocked because it couldn't grab some signal light.
>
--
Stan Brown [email protected] 843-745-3154
Westvaco
Charleston SC.
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc