Design (long)

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
 
On Sun Jan 16 11:00:25 2000 Stan Brown wrote...
>
> 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.

After I sent this, I realized how harsh it sounded, so let me elaborate a bit.

To the best of my knowledge, no commercial vendor of PLC's allows multiple logic processors to share control of a real output. As a controls engineer who uses this stuff daily, I would never allow such a system to be installed in my facility. Even if I did, both my manager,
and the electrical engineering group, and the maintenance force would reject of out of hand.

It is _very_ poor practice, and will cause a system that allows it to have very minimal acceptance in the filed.

This is a very basic design issue, that I am afraid, I am unwilling to compromise on, sorry thats just what 25 years of real world experience
has taught me.

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

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

Unless the engines are coordinated by a single user view, becoming effectively one engine with multiple processes, the state of that output is indeterminate to any particular engine/user view. That breaks many design rules for control.
While that can and has been done, eg. wire oring outputs, I fall in on the side of it being a remarkably bad idea, particularly if it is hidden at all to the user. A solution, if we must have one, might be to allow this as a special option where you must explicitly state you want this behaviour. Otherwise it would be extremely hard to troubleshoot/certify/prove. If coordinated/understood, it becomes an or.
Just my .02 worth.

cww


Stan Brown wrote:
>
> On Sun Jan 16 11:00:25 2000 Stan Brown wrote...
> >
> > 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.
>
> After I sent this, I realized how harsh it sounded, so let me elaborate a bit. ...<clip> <

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
M
Even in a single logic engine (traditional PLC) duplicating of outputs in the ladder would often cause a lot of trouble. It is only the use of cross reference tools that make this manageable (it is still arguable as to whether or not it is a good idea).

If you want to be able to licence the 'PLC' for use in those industries where licencing is required, or to install into Europe (i.e. comply with EC legislation) the thing has to be SAFE.

Having more than one process control an output means the likelyhood of unpredictable behaviour is increased.

-----Original Message-----
From: [email protected] [mailto:[email protected]]On
Behalf Of Curt Wuollet

Hi, all

Unless the engines are coordinated by a single user view, becoming effectively one engine with multiple processes, the state of that output is
indeterminate to any particular engine/user view. That breaks many design rules for control.
While that can and has been done, eg. wire oring outputs, I fall in on the side of it being a remarkably bad idea ...<clip

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

Actually, I've just realised where a big source of misunderstanding might be: the difference in philosophy between monolithic programs
common on platforms where interfaces are poor and modular programs common in Linux.

Consider: in Linux, word-count is done by a separate program.

If that's the case, then the argument whether stepladder should or should not be a part of the core is really an argument between
monolithic programs and modular programs. Because in a good modular system, the core is very small and all the functionality is elsewhere, obviously it can't includestepladder (or any other language).

I'm firmly in the thin-core camp: the core should be little more than a set of interfaces; on one side (left-hand in a diagram) there hang
the PLC drivers; on the other (right-hand) there hang stepladder interpreters, compiled C programs, HMIs and WWW and PLC servers.

One thing that I would put in the core (or perhaps the drivers should do it) is that each point should be individually mappable. If you
stick your screwdriver in the wrong way and burn out one output, switch the wires to a spare one and change one value in a config table.


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
 
> On Sun Jan 9 19:46:49 2000 Simon Martin wrote...
>...I would like to say the following on the design:
>
>1) IO
>
>Let's define an IO model. As far as I can see (please correct me if I'm >wrong) the type of IO that is available is analog (12/16 bit)/digital, =
>periodic/immediate update. If these are the only requierements then I >would suggest that an IO node would be defined adequately by: <

In addition many intelegent I/O modules return data, and require configuring with data, that resemnles structs. For an example look at
the block transfers to configure an A/B anaolg I/O module, or the blocks from a servo positionig module.

>enum io_update_type { io_update_periodic, io_update_immediate };
>
>struct tag_io {
> enum io_update_type update;
> long value;
>};
>
>2) PLC engine.
>
>The PLC engine runs a set of rules on the IO to generate the output. =
>Again, let's define a model. A simple model I can think of is the status =
>of one or more outputs is defined the status of one or more inputs, this =
>would translate as: <

To really be credible here, it's got to execute ladder code, you have to be able to look at the states of this ladder in real time (statuses,
forces etc), and you have to be able to edit this ladder on line.

>enum comparison_type { comparison_equals, comparison_greater, =
>comparison_greater_equal,
> comparison_less, comparison_less_equal }
>
>struct tag_condition {
> struct tag_io *io;
> long value;
> enum comparison_type comparison;
>};
>
>enum conjuntcion_type { conjuntion_and, conjunction_or, conjuntion_none =
>};
>
>struct tag_rule {
> struct tag_condition lcondition;
> enum conjunction_type conjunction;
> struct tag_condition rcondition;
>};
>
>struct tag_list_io {
> struct tag_io io;
> struct tag_list_io *next;
>};
>
>struct tag_step {
> struct tag_rule *rule;
> struct tag_list_io *set
>}
>
>The io may be physical or virtual. The IO is stored in shared memory.
>
>3) IO to Physical IO mapping
>
>A set of processes map the virtual IO to physical IO and feed the =
>corresponding drivers. This process is user configurable via the file =
>/etc/iomap.conf, which defines IO range, IO driver responsible and any =
>other data required by the driver to identify the physical IO module. <

I still think that the relationship between the physical location of the I/O card, and it's logical address is an important feature of a
PLC.

>4) The PLC Engine knows nothing about programming languages.
>
>A set of middleware translators are written to go between the PLC engine >representation and any programming language (Ladder, etc). This has the
>advantage of being able to see the program as I like it, if I understand >IL, I see it as IL, if I understand Ladder, I see it as ladder. A >standard annotation format must be developed to be able to transport >non-executable information from one format to another. <

See real time monitoring & editing above.
 
Top