Design (long)

S

Thread Starter

Simon Martin

Hi all:

This is a RFC (Request For Comment). I apologize for writing C code, but I think better in code than in any natural language (it's a sorry life). After reading quickly through all the mail from this list (it is a busy list isn't it), and weaving in a bit of my own experience 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:

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:

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.

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.

5) Keep everything isolated via abstraction models.

OK we all bash MS Windows NT, but I think one of the greatest things to come out of it is the HAL (Hardware Abstraction Layer). This presents all the rest of the operating system with a "concept of a computer", filling in the blanks where required, translating where required. I would hope that this would be one of the goals. The PLC just understands conditions and io, other processes understand Ladder, ModBus, DH, DH+, etc.

(Flame shields are up and at full strength, Mr Spock)

Debian GNU User
Simon Martin
Project Manager
Isys
mailto: [email protected]


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
S
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.

--- Huge mess of HTML sniped.

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


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
A
Simon Martin wrote: >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 requirements then I would suggest that an IO node would be defined adequately by:
>
>enum io_update_type { io_update_periodic, io_update_immediate };
>
>struct tag_io {
> enum io_update_type update;
> long value;
>}; <

With the many specialty modules in common use today, there needs to be a variety of data types available for data from I/O modules, at minimum float, int and bool. Many I/O modules have a variety of information to pass between them and the PLC engine beyond just the actual physical I/O - configuration data, status attributes etc. Consider a servo or stepper module that has loop
status to report, position to report as well as several actions that can be initiated such as homing, moving to position, jogging at a speed, etc. Even simplier modules like a thermocouple input card can have data scaled in engineering units and can internally generate user defined alarms.

>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:<

Could this be expanded to also process higher level ladder blocks (a motion control block or file arithmetic block for instance)?

>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.<

I like the concept, but translating between a machine integrator program written in different languages on-demand could be a very tall order. Taking a ladder program (or other type of program for that matter) to a native language used by
the PLC logic engine can be done, but "de-compiling" a native program back into a ladder program could be very difficult.

Alan Locke
Controls Engineer, Boeing

"My opinions are my own and not necessarily those of my employer"

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Mon, Jan 10, 2000 at 11:02:45AM -0500, Stan Brown wrote:
> On Mon Jan 10 07:40:50 2000 Simon Martin wrote...

> >If we create an IO block to represent a different PLC, how would we
> >express it in terms of what we have got above, just as another 1000
> >points?

> How about PLC_ID:MEMORY_LOCATION ?

I disagree, I think the virtual IO should not distinguish PLC_IDs.

That way you can move virtual points between physical PLCs without changing the program, and replace PLC groups with different combinations (ie, swap three PLCs for two slightly larger ones, or ones with different mixes of I/O).

> This used to be common. What happens, is that if physicall inputs have
> been maped to this area, the user writen vaule is overwriten on the next
> input scan. If however, there is no maping of that particular input
> address to physical inputs the value will stay ther.

Actually, it might be useful in some cases to have the outputs written only if they've been explicitly set by the program! Otherwise, read them back in case something else changed them.

That way, you can have two programs cooperating, as long as you ensure they don't both try to control the same output.

> >>2) PLC engine.
...
> >Please correct me in this, this is the shakiest bit of my knowledge as I
> >work in R&D in motion control, a combination of input values will cause
> >an action. The action can be set outputs, perform a function. This
> >function can be an internal function block written by us for the
> >LinuxPLC, or an external binary written by the user for the LinuxPLC.
> >Either way it resolves to a bit of code. Are there any more variants to
> >be taken care of?

Yes - rising edge, counting, user action, timed action and no doubt many others I've forgotten right now.

All of those can be done by logical ANDs and ORs, of course, but only in the sense that that's how the computer ultimately works - it is not a
practical way to program anything.

> Just please don't forget the run time statuses must be visible in the
> language that they were programed in (ladder for instance), and that it
> must be possible to edit this application code, in the original language
> at run time.

Yes, but I don't think there's a practical way of doing this in a uniform manner, so we'll have to settle for doing it on a language-by-language
basis.

In extremum, consider the case where someone writes (part of) the control program in C. It would be very difficult to do anything but pass it to gcc to compile and run the resulting binary.

In other languages, such as stepladder, it is trivial to re-load the program at the beginning of a scan.

If you can come up with a unified scheme for doing on-line edits, it will be excellent. But until then I'm afraid we should settle for implementing it separately in each front-end where it makes sense.

(Even if you do have a unified scheme for on-line edits, I wouldn't put it in the core - partly to keep the core small, partly because some
applications simply don't need it, or need far too much of it. If there's to be an on-line edit in the HMI front-end, it shouldn't touch the core nor the controler front-end. An on-line edit in a state language must be prepared to do garbage collection. And so forth.)

> >This is a set of external programs that precompile the incoming code to
> >a standard set of rules run by the PLC. They are not to be seen as
> >"interpreters", they are "compilers". This is one of the reasons why we
> >must create a very good rule model, as everything interfaces with this.

> I don't see how they can be compilers, and give the run time viewing, and
> editing that is required. I don't object to compiling the code, I just
> want to make certain we don't miss the basic functionality here.

Three points:
- I'm afraid the functionality is not as `basic' as it sounds at first sight.
- Compilation doesn't matter for run-time viewing, as long as you have the source code and debugging tables (ie, foo.c line 57 corresponds to addresses 0x1234 through 0x1240).
- If we *do* manage to make on-line edits to C code (and I can see that it's only an SMOP), we should do this in a general way rather than limiting it to the PLC application.

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]linuxplc.org
http://linuxplc.org/mailman/listinfo/linuxplc
 
S
On Mon Jan 10 22:19:03 2000 Jiri Baum wrote...
>
>Actually, it might be useful in some cases to have the outputs written only if they've been explicitly set by the program! Otherwise, read them back in case something else changed them.<
>
>That way, you can have two programs cooperating, as long as you ensure they don't both try to control the same output.<

Having more than one PLC have control of any give output (as opposed to several reading the same input). Is unacceptable. Agiven output _must_ be tied to a particulat PLC in a fashion that is easy to determine at run time.

>
>> Just please don't forget the run time statuses must be visible in the language that they were programed in (ladder for instance), and that it
must be possible to edit this application code, in the original language at run time.<<
>
>Yes, but I don't think there's a practical way of doing this in a uniform manner, so we'll have to settle for doing it on a language-by-language
basis.<
>
>In extremum, consider the case where someone writes (part of) the control program in C. It would be very difficult to do anything but pass it to gcc to compile and run the resulting binary.<

Not true. There is at least one impementation of a run time interpreted C. taht allows display of variables. Take a look at ddd for inspiration.

>In other languages, such as stepladder, it is trivial to re-load the program at the beginning of a scan. <
>
>If you can come up with a unified scheme for doing on-line edits, it will be excellent. But until then I'm afraid we should settle for implementing it separately in each front-end where it makes sense.<

I don;t care where it's implemented, its just basic PLC funcationality. Without it you really can't call your system a PLC.
>
>> >must create a very good rule model, as everything interfaces with this. I don't see how they can be compilers, and give the run time viewing, and editing that is required. I don't object to compiling the code, I just want to make certain we don't miss the basic functionality here.<<
>
>Three points:
> - I'm afraid the functionality is not as `basic' as it sounds at first sight.<

I lost what you think isn't basic here?

> - Compilation doesn't matter for run-time viewing, as long as you have the source code and debugging tables (ie, foo.c line 57 corresponds to addresses 0x1234 through 0x1240).<

Lease get a reality check with people that actually use this stuff. If you try to explain hex notation to you maintenance persoanel, good luck!

One of the fastest ways to cause those of use with real applications for this sort of project, is to turn it into a hackers delight,
computer control system. I am not going to deploy, nor would I have any acceptance of such a project.

It's going to be dificult enough to overcome the "no vendor support" without the project giving the existing support people the
warm fuzzy of looking, and feeling like the tools they have grown confortable with.

After we do that, then we can tall extensions.


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

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Tue, Jan 11, 2000 at 07:16:00AM -0500, Stan Brown wrote:
> On Mon Jan 10 22:19:03 2000 Jiri Baum wrote...
...
> >That way, you can have two programs cooperating, as long as you ensure
> >they don't both try to control the same output.

> Having more than one PLC have control of any give output (as opposed to
> several reading the same input). Is unacaptable. Agiven output _must_ be
> tied to a particulat PLC in a fashion that is easy to determine at run
> time.

Well, I can think of three ways in which this might be used:

- a diagnostic tool with a "force output" function. Don't forget that "internal relays" in most PLCs can be intended for reading or writing, depending on what each one is being used for, and a diagnostic tool should display their current status *and* allow them to be changed. Same for timers and counters.

- cooperation between two modules, possibly written in different languages.
These might be as different as "production mode" and "maintenance mode".

- sloppy programming. That's what you were afraid of, I assume.

All of these could be achieved by letting each module grab and release outputs, but I'm not sure if the advantages will outweigh the disadvantages
(not just the extra functions in the interface, but also handling of two modules attempting to grab the same output).

Diagnostic tools included with the suite will be able autodetect if two modules seem to be fighting over an output.

[about on-line edits]
> >Yes, but I don't think there's a practical way of doing this in a
> >uniform manner, so we'll have to settle for doing it on a
> >language-by-language basis.

> >In extremum, consider the case where someone writes (part of) the
> >control program in C. It would be very difficult to do anything but pass
> >it to gcc to compile and run the resulting binary.

> Not true. There is at least one impementation of a run time interpetd C.
> taht allows display of variables. Take a look at ddd for inspiration.

Yes, I know of ddd. It uses compiled C, by the way.

As I wrote, it'd be an SMOP - certainly doable, but a substantial project in its own right, of limited relevance to industrial control. [1]

> I don;t care where it's implemented, its just basic PLC functionality.
> Without it you really can't call your system a PLC.

OK. As I said, for stepladder it's trivial.

> >Three points:
> > - I'm afraid the functionality is not as `basic' as it sounds at
> > first sight.

> I lost what you think isn't basic here?

Language-independent on-line edits.

> > - Compilation doesn't matter for run-time viewing, as long as you
> > have the source code and debugging tables (ie, foo.c line 57
> > corresponds to addresses 0x1234 through 0x1240).

> Lease get a reality check with people that actually use this stuff. If
> you try to explain hex notation to you maintenance persoanel, good luck!

Oops, I think we're having a different-backgrounds problem here...

I naturally assumed that there would be a tool that takes the debugging table and shows you the source code, with a nice arrow next to it saying
"you are here".

That's how ddd works.

> After we do that, then we can tall extensions.

It would be good to have an architecture that will serve well for the foreseeable extensions, though.


Jiri

[1] You'd compile the line again and insert it - that's the easy bit. If it's too large, you put it somewhere else and jump to and from. The hard
bit is if you don't want to lose performance, replace the whole function and then put in some kind of trampoline to check the caller and snap the pointer if it's a plain call. For extra credit, handle function pointers and/or optimization. As usual, the department will disavow any knowledge should you be captured or killed. Good luck, Jim!
--
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 Tue Jan 11 09:06:47 2000 Jiri Baum wrote...
>
>On Tue, Jan 11, 2000 at 07:16:00AM -0500, Stan Brown wrote:
>> On Mon Jan 10 22:19:03 2000 Jiri Baum wrote...
>...
>> >That way, you can have two programs cooperating, as long as you ensure
>> >they don't both try to control the same output.
>
>> Having more than one PLC have control of any give output (as opposed to
>> several reading the same input). Is unacaptable. Agiven output _must_ be
>> tied to a particulat PLC in a fashion that is easy to determine at run
>> time.
>
>Well, I can think of three ways in which this might be used:
>
>- a diagnostic tool with a "force output" function. Don't forget that
> "internal relays" in most PLCs can be intended for reading or writing,
> depending on what each one is being used for, and a diagnostic tool
> should display their current status *and* allow them to be changed. Same
> for timers and counters.
>
>- cooperation between two modules, possibly written in different languages.
> These might be as different as "production mode" and "maintenance mode".
>
>- sloppy programming. That's what you were afraid of, I assume.

Hmm, I am not certain you and I are speaking the same language here. If you say "output" to me I read it as a real physical hardware output conected to something. This would live in the I/O image table.

If what you mean is other data table locations or holding registers, can be shared, then I agree with you.

If you mean "real outputs" It's just not an aceptabnle practice. How do you troubleshoot it?

>All of these could be achieved by letting each module grab and release
>outputs, but I'm not sure if the advantages will outweigh the disadvantages
>(not just the extra functions in the interface, but also handling of two
>modules attempting to grab the same output).
>
>Diagnostic tools included with the suite will be able autodetect if two
>modules seem to be fighting over an output.
>
>[about on-line edits]
>> >Yes, but I don't think there's a practical way of doing this in a
>> >uniform manner, so we'll have to settle for doing it on a
>> >language-by-language basis.
>
>> >In extremum, consider the case where someone writes (part of) the
>> >control program in C. It would be very difficult to do anything but pass
>> >it to gcc to compile and run the resulting binary.
>
>> Not true. There is at least one impementation of a run time interpetd C.
>> taht allows display of variables. Take a look at ddd for inspiration.
>
>Yes, I know of ddd. It uses compiled C, by the way.

Yes, but there are C interpreters, I was just pointing to ddd for a reference on nice debugin features. There are several comercial C
interpreters that offer similar functionality.

>As I wrote, it'd be an SMOP - certainly doable, but a substantial project
>in its own right, of limited relevance to industrial control. [1]
>
>> I don;t care where it's implemented, its just basic PLC funcationality.
>> Without it you really can't call your system a PLC.
>
>OK. As I said, for stepladder it's trivial.
>
>> >Three points:
>> > - I'm afraid the functionality is not as `basic' as it sounds at
>> > first sight.
>
>> I lost what you think isn't basic here?
>
>Language-independent on-line edits.
>
>> > - Compilation doesn't matter for run-time viewing, as long as you
>> > have the source code and debugging tables (ie, foo.c line 57
>> > corresponds to addresses 0x1234 through 0x1240).
>
>> Lease get a reality check with people that actually use this stuff. If
>> you try to explain hex notation to you maintenance persoanel, good luck!
>
>Oops, I think we're having a different-backgrounds problem here...
>
>I naturally assumed that there would be a tool that takes the debugging
>table and shows you the source code, with a nice arrow next to it saying
>"you are here".

Look, if you want to build a PLC, as oposed to an "automation controler" you need to get in touch with how these things are supported in the real world.

>That's how ddd works.
>
>> After we do that, then we can tall extensions.
>
>It would be good to have an architecture that will serve well for the
>foreseeable extensions, though.
>
>Jiri
>
>[1] You'd compile the line again and insert it - that's the easy bit. If
>it's too large, you put it somewhere else and jump to and from. The hard
>bit is if you don't want to lose performance, replace the whole function
>and then put in some kind of trampoline to check the caller and snap the
>pointer if it's a plain call. For extra credit, handle function pointers
>and/or optimization. As usual, the department will disavow any knowledge
>should you be captured or killed. Good luck, Jim!

--
Stan Brown [email protected] 843-745-3154
Westvaco
Charleston SC.
--
Windows 98: n.
useless extension to a minor patch release for 32-bit extensions and
a graphical shell for a 16-bit patch to an 8-bit operating system
originally coded for a 4-bit microprocessor, written by a 2-bit
company that can't stand for 1 bit of competition.
-
(c) 1999 Stan Brown. Redistribution via the Microsoft Network is prohibited.

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Tue, Jan 11, 2000 at 04:37:45PM -0500, Stan Brown wrote:
> On Tue Jan 11 09:06:47 2000 Jiri Baum wrote...
> >On Tue, Jan 11, 2000 at 07:16:00AM -0500, Stan Brown wrote:
> >> On Mon Jan 10 22:19:03 2000 Jiri Baum wrote...
> >...
> >> >That way, you can have two programs cooperating, as long as you ensure
> >> >they don't both try to control the same output.
> >
> >> Having more than one PLC have control of any give output (as opposed to
> >> several reading the same input). Is unacaptable.
...
> >Well, I can think of three ways in which this might be used:
> >
> >- a diagnostic tool with a "force output" function. Don't forget that
> > "internal relays" in most PLCs can be intended for reading or writing,
> > depending on what each one is being used for, and a diagnostic tool
> > should display their current status *and* allow them to be changed. Same
> > for timers and counters.
> >
> >- cooperation between two modules, possibly written in different languages.
> > These might be as different as "production mode" and "maintenance mode".
> >
> >- sloppy programming. That's what you were afraid of, I assume.

> Hmm, I am not certain you and I are speaking the same language her. If
> you say "output" to me I read it as a real physical hardware output
> conected to something. This would live in the I/O image table.

True; basically I'm not sure whether it's possible to define `real physical
hardware output' strictly enough for it to be programmable. It seems to me
it'd depend on how it's used. Consider:
- an output connected to a motor
- an output connected to a light signal
- an output connected to a tester point or blinkenlight
- an output connected to the input of another PLC
- an internal relay inside a PLC
- an internal relay inside another linuxPLC
- an internal relay inside this linuxPLC

The first one is obviously a real physical output; but what about the others?

(Even the first one can be made dubious by the phrase "motorised pot".)

> If you mean "real outputs" It's just not an aceptabnle practice. How do
> you troubleshoot it?

With difficulty, and the practice should be discouraged.

I just don't see any way of programming this exclusion which wouldn't bring its own significant problems.

Used sparingly, it might occasionally be useful; and the `force output' function is really obligatory in the diagnostic tool.

If the core keeps track of which module last modified each output, a troubleshooting tool can flag any time that changes for a particular
output. (The main use would be identifying which module handles each output, but it'd have the additional function of detecting this.)


> >> > - Compilation doesn't matter for run-time viewing, as long as you
> >> > have the source code and debugging tables (ie, foo.c line 57
> >> > corresponds to addresses 0x1234 through 0x1240).
> >
> >> Lease get a reality check with people that actually use this stuff. If
> >> you try to explain hex notation to you maintenance persoanel, good luck!
...
> >I naturally assumed that there would be a tool that takes the debugging
> >table and shows you the source code, with a nice arrow next to it saying
> >"you are here".

> Look, if you wnat to build a PLC, as oposed to an "automation
> controller" you need to get in touch with how these things are
> supported in the real world.

I'm not sure what the disagreement is here.

In the real world, most people don't care about debugging tables; that's internal to the various tools and for the most part invisible. The only
thing most people ever see of them is the diskspace, and they only realise that because they're optional.

However, seeing as we'll be implementing the thing, I assumed that we need to worry about them - where they'll be stored, what they'll contain, in what format - and that's what I was talking about. Once the they are implemented, they'll become invisible again.


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
 
K
First, I agree with the comment in another thread about the language issue being a storm in a teapot -- of course we will have to support a variety of languages to be successful, and of course one of these must be Ladder Diagram (although not my favorite :).

I'd suggest we acknowledge the following "givens":
1. We will need to support a broad range of I/O types including digital, analog, and complex (such as motion axes), both local and remote.
2. We will need to support a range of languages with *widely* divergent flow models (combinatorial languages such as LD, procedural languages such as C, and state languages).
3. The platform will be whatever the code gets ported to, in short, "who knows". But count on a broad range from desktop Win32 machines to
board-level Linux systems to architectures yet to be invented.

If the above is accurate, the question of what represents the core "PLC" (substitute your favorite designation) gets interesting. It begins to look like the core consists mostly of programming interfaces to link these replaceable pieces together.

For instance, I think that the previously stated assumptions of a conventional PLC flow model (scan inputs / scan program / update outputs)
tends *not* to support procedural and state languages very well.

Now, there's no reason we couldn't have a baseline implementation consisting of several components (I/O drivers, LD engine, Linux support) that work according to a specified interface definition, but where each of which may
be swapped out for other components. If the one constant is the programming interface, then this thing can be extended pretty dramatically and see
widespread application as a result.

Ken Crater
Control.com Inc.
[email protected]



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

Sage, Pete (IndSys, GEFanuc, Albany)

I agree and have been saying from the start that identifying the interfaces is crucial for the projects success.

Pete
 
On Wed Jan 12 09:00:14 2000 Jiri Baum wrote...
>
>On Tue, Jan 11, 2000 at 04:37:45PM -0500, Stan Brown wrote:
>> On Tue Jan 11 09:06:47 2000 Jiri Baum wrote...
>> >On Tue, Jan 11, 2000 at 07:16:00AM -0500, Stan Brown wrote:
>> >> On Mon Jan 10 22:19:03 2000 Jiri Baum wrote...
>> >...
>
>True; basically I'm not sure whether it's possible to define `real physical
>hardware output' strictly enough for it to be programmable. It seems to me
>it'd depend on how it's used. Consider:
> - an output connected to a motor
> - an output connected to a light signal
> - an output connected to a tester point or blinkenlight
> - an output connected to the input of another PLC


All teh ones above hee are "real outputs" Taht is the conect to a peice
of hardware that is wired to a real world device, even if that other
device is anothe PLC.

> - an internal relay inside a PLC
> - an internal relay inside another linuxPLC
> - an internal relay inside this linuxPLC

All of these a "sata table values" The distinction between internal PLC
memory, and data table thst is mape tp physical I/O is basic to the
concept of understanding a PLC.

>
>The first one is obviously a real physical output; but what about the
>others?
>
>(Even the first one can be made dubious by the phrase "motorised pot".)
>
>> If you mean "real outputs" It's just not an aceptabnle practice. How do
>> you troubleshoot it?
>
>With difficulty, and the practice should be discouraged.
>
>I just don't see any way of programming this exclusion which wouldn't bring
>its own significant problems.
>
>Used sparingly, it might occasionally be useful; and the `force output'
>function is really obligatory in the diagnostic tool.
>
>If the core keeps track of which module last modified each output, a
>troubleshooting tool can flag any time that changes for a particular
>output. (The main use would be identifying which module handles each
>output, but it'd have the additional function of detecting this.)
>
>
>> >> > - Compilation doesn't matter for run-time viewing, as long as you
>> >> > have the source code and debugging tables (ie, foo.c line 57
>> >> > corresponds to addresses 0x1234 through 0x1240).
>> >
>> >> Lease get a reality check with people that actually use this stuff. If
>> >> you try to explain hex notation to you maintenance persoanel, good luck!
>...
>> >I naturally assumed that there would be a tool that takes the debugging
>> >table and shows you the source code, with a nice arrow next to it saying
>> >"you are here".
>
>> Look, if you wnat to build a PLC, as oposed to an "automatin
>> controlere" you need to get in touch with how these things are
>> supported in the real world.
>
>I'm not sure what the disagreement is here.
>
>In the real world, most people don't care about debugging tables; that's
>internal to the various tools and for the most part invisible. The only
>thing most people ever see of them is the diskspace, and they only realise
>that because they're optional.
>
>However, seeing as we'll be implementing the thing, I assumed that we need
>to worry about them - where they'll be stored, what they'll contain, in
>what format - and that's what I was talking about. Once the they are
>implemented, they'll become invisible again.


I really think you ust have never worked on real world PLC project. You seem to not have the basic concepts of real world control. I really don't mean this as an insult, so please don't take it that way. But if you _really_ don't see the diference between an internal memory location, and a memory location that is mapped to a peice of hardware that turns on say a 500HP motor then we need to get to the point where you do understand this.

Please take this in the spirit of helpful education that I intend it.


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

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

Phil Covington

----- Original Message -----
From: "Ken Crater" <[email protected]>

<snip>

> 3. The platform will be whatever the code gets ported to, in short, "who
> knows". But count on a broad range from desktop Win32 machines to
> board-level Linux systems to architectures yet to be invented.

<more snipped>

>If the one constant is the programming interface, then this thing can be
extended pretty dramatically and see
> widespread application as a result.
>
> Ken Crater

I think that this ties in with your previous post concerning the need for a unique project name. While I do think that Linux will make the best
platform for development of this project I, for one, will be interested in porting the code to Win32. < ...putting heat retardent jacket on > I think it would be a good idea to abstract the major parts of the code so that this project isn't too tied to the OS. A unique name other than "LinuxPLC" will allow the code ported to different OSes to fall under the same project name.

For a while now, I've been using Real Time Linux ver .0( http://www.rtlinux.org ) with the RTCom serial module to communicate with RS485 networked devices. The control program is written in C and is specific to the application. The PC is now basically a dedicated controller and works well for its purpose. But it is useless for any other task in that it would have to be re-coded for a different control purpose. This was just a quick and dirty solution and was an excuse for me to learn how to use RTLinux in a practical control application. Linux works so well here with
the Real Time patch that I see all kinds of applications for it. What I don't want to do is re-invent the wheel every time I come up with a use for it!

Defining the interfaces are the key...

For those who are interested, besides "hard" RTLinux there is a "firm" real time Linux effort at: http://hegel.ittc.ukans.edu/projects/kurt/ and
http://hegel.ittc.ukans.edu/projects/kurt/old-index.html which is KURT Linux- The KU Real Time Linux. It would be great if RTLinux and KURT were
merged into one effort ( I think that there has been some discussion among those groups about doing just that..)

Phil Covington
vHMI




_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Wed, Jan 12, 2000 at 04:16:01PM -0500, Stan Brown wrote:
> On Wed Jan 12 09:00:14 2000 Jiri Baum wrote...
> >On Tue, Jan 11, 2000 at 04:37:45PM -0500, Stan Brown wrote:
> >> On Tue Jan 11 09:06:47 2000 Jiri Baum wrote...
> >> >On Tue, Jan 11, 2000 at 07:16:00AM -0500, Stan Brown wrote:
> >> >> On Mon Jan 10 22:19:03 2000 Jiri Baum wrote...
> >> >...
> >
> >True; basically I'm not sure whether it's possible to define `real physical
> >hardware output' strictly enough for it to be programmable. It seems to me
> >it'd depend on how it's used. Consider:
> > - an output connected to a motor
> > - an output connected to a light signal
> > - an output connected to a tester point or blinkenlight
> > - an output connected to the input of another PLC

> All teh ones above hee are "real outputs" Taht is the conect to a
> peice of hardware that is wired to a real world device, even if
> that other device is anothe PLC.

> > - an internal relay inside a PLC
> > - an internal relay inside another linuxPLC
> > - an internal relay inside this linuxPLC

> All of these a "sata table values" The distinction between internal
> PLC memory, and data table thst is mape tp physical I/O is basic to
> the concept of understanding a PLC.

> >The first one is obviously a real physical output; but what about the
> >others?
> >
> >(Even the first one can be made dubious by the phrase "motorised pot".)
...
> I really think you ust have never worked on real world PLC project. You
> seem to not have teh basic concepts of real world control. I really don't
> mean this as an insult, so please don't take it that way. But if you
> _really_ don't see the diference between an internal memory location, and
> a memory location that is maped to a peice of hardwre that turns on say a
> 500HP motor then we need to get to the point wher you do understand this.

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)?

It seems to me a really arbitrary division. From the wide point of view, both are internal to the control system: one stays within the one PLC, the
other connects two PLCs, but neither has any direct connection to 500HP motors or hydraulic valves.

Obviously anything that controls 500HP motors is a Real Output.


As I wrote above, it's the greys that bother me. Obvious outputs and obvious internal relays are, well, obvious.

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.

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 Wed, Jan 12, 2000 at 11:52:24AM -0500, Ken Crater wrote:
> If the above is accurate, the question of what represents the core "PLC"
> (substitute your favorite designation) gets interesting. It begins to
> look like the core consists mostly of programming interfaces to link
> these replaceable pieces together.

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
 
M
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.



-----Original Message-----
From: [email protected] [mailto:[email protected]]On
Behalf Of 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.
The two may still perform the same function in the second PLCs application program, but the former has reduced the number of inputs that the remain available to the PLC. It also has a number of other considerations such as hardware configuration (sink/source), voltage compatibility and hardware operating times ( a relay or contactor in the real world may take upto 50mS to operate).


>Obviously anything that controls 500HP motors is a Real Output.

Anything that acts on a physical entity (e.g. an opto-22 signal conditioner) is a physical output.

>As I wrote above, it's the greys that bother me. Obvious outputs and
>obvious internal relays are, well, obvious.

What is not obvious about a volt (or 24 of them DC)?

>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.

A traditional, physical PLC does not have the same problem. There is not usually more than one logic processor in the rack (redundant systems usually only allow one processor at a time to control the I/O. Usually the I/O map is only written to the physical I/O at predetermined intervals, often only at the begining or end of the scan.

The I/O Driver/Server should allow for a lock to be placed on a given I/O point/group/module/channel. Only the logic controller with the lock can write to those outputs.


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Thu Jan 13 07:57:36 2000 Mark Hutton wrote...
>
>>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.
>
>A traditional, physical PLC does not have the same problem. There is not
>usually more than one logic processor in the rack (redundant systems usually
>only allow one processor at a time to control the I/O. Usually the I/O map
>is only written to the physical I/O at predetermined intervals, often only
>at the begining or end of the scan.
>
>The I/O Driver/Server should allow for a lock to be placed on a given I/O
>point/group/module/channel. Only the logic controller with the lock can
>write to those outputs.
>

This is exactly how it is handled in AB Controlenet. Multiple PLC's can access a given real I/O rack. Each one can read teh status of the Inputs. Each can force inputs, since that force is applied before the PLC uses the status.

Outputs must be assigned to _one_ and only one PLC. This is done at network configure time.


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

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
D
> -----Original Message-----
> From: Jiri Baum [mailto:[email protected]]
> Subject: Re: LinuxPLC: Design (long)

> 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)?

You may have to debug the later by replacing the damaged wire. This really is an important difference.

_______________________________________________
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!


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.


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.


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
 
Jiri Baum:
> > >That way, you can have two programs cooperating, as long as you ensure
> > >they don't both try to control the same output.

Note the bit where I said "as long as you ensure they don't both try to control the same output"... I know it's a problem, but I didn't want to deal with it right now, so I thought I'd shift it off onto the implementor for the time being.

Often enough you will only have one program anyway, and then none of this matters.


Stan Brown:
> > Having more than one PLC have control of any give output (as opposed to
> > several reading the same input). Is unacaptable.
...
> Well, I can think of three ways in which this might be used:
...
> - sloppy programming. That's what you were afraid of, I assume.

A (somewhat belated) suggestion: call it the "Red Dwarf" method of programming.

As in: "The red, blue *and* white lights are flashing - either we're having a disco, or we're under attack." Or: "All the hazard approach lights are on ... can mean anything from `we are under attack' to `the baked potatoes are
burning'."

Hopefully that'll embody both a spirit of disparagement and a playful sense of when it might be appropriate.


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 16 07:12:45 2000 Jiri Baum wrote...
>
>Jiri Baum:
>> > >That way, you can have two programs cooperating, as long as you ensure
>> > >they don't both try to control the same output.
>
>Note the bit where I said "as long as you ensure they don't both try to
>control the same output"... I know it's a problem, but I didn't want to
>deal with it right now, so I thought I'd shift it off onto the implementor
>for the time being.
>
>Often enough you will only have one program anyway, and then none of this
>matters.

I feel that there _must_ be a locking of real outputs to a particular logic processor task. I also feel that this needs to be defined in the I/O data table configuration files.

>Stan Brown:
>> > Having more than one PLC have control of any give output (as opposed to
>> > several reading the same input). Is unacaptable.
>...
>> Well, I can think of three ways in which this might be used:
>...
>> - sloppy programming. That's what you were afraid of, I assume.
>
>A (somewhat belated) suggestion: call it the "Red Dwarf" method of
>programming.
>
>As in: "The red, blue *and* white lights are flashing - either we're having
>a disco, or we're under attack." Or: "All the hazard approach lights are on
>... can mean anything from `we are under attack' to `the baked potatoes are
>burning'."
>
>Hopefully that'll embody both a spirit of disparagement and a playful sense
>of when it might be appropriate.

Think of it as the implodeing galaxy style of programming, the results are equally catastrophic, they just take seconds to occur instead of cosmic times :)

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

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