LinuxPLC

R

Thread Starter

R A Peterson

I am unlikely to make any significant contributions code wise as I am not well versed in C anymore, having forgotten most of what i did years ago due to no longer using it. I'd like to approach some issues from a user prospective.

1. I' d generally agree that a PLC and an HMI "ought" to be seperate machines. However, I don't think it is appropriate for the LinuxPLC group to restrict it so that it has to be done that way. That should be a decision made by the implementor of the control system.

2. Before people go crazy and start writing code perhaps some thinking should be put into what the implementor of the control system is going to
need. I would like to see something readily usable by me as a PLC replacement, not some hacker's delight (no offense intended). The thing will never get any wide acceptance unless it is usable by people who are not C programmers or Linux experts, much the way people who are not WinNt experts can still implement projects using commercial packages.

I'd like to see something that:

a) Runs ladder logic

Because it is the most commonly used language for industrial control. Perhaps IEC1131 since it is already a standard.

b) Allows for unlimited online programming

Because it is near impossible to shut down most processes to make a minor change. Continuous processes are not continuous if you have to shutdown to add a temperature switch.

c) Allows for user defined functions

Because once you do something, its nice to not have to do it over. With many people writing user defined functions, if they choose to make them public, in a short period of time we could have thousands of functions available to cut
and paste as needed.

d) Supports many different I/O structures.

Regardless of some people in this effort who dislike proprietary I/O structures, the fact is that there are lots of 1771 I/O racks out there with old processors on them. It would be nice to retrofit an old AB installation without having to replace the existing I/O.

Towards this end, instead of pointing people towards I/O buses that have a small percentage of the market, why not open up and as a very high priority make drivers available for cards to interface to AB RIO and DH, Modbus+, and Genius, along with Devicenet, profibus, interbus, etc. (I didn't mean to leave anyone out, just gave a few examples).

e) supports some form of Netdde or other straightforward way of communicating with existing SCADA systems. These things can't operate in a vacuum.

g) needs drivers to communicate with existing common PLCs. AB/Modicon/GE, etc. The fact is that the PLC companies are not going to go away. The LinuxPLC will need to have a way to deal with them. In fact, it maybe ought to have the communications capablity to act as a traffic director for multiple brands of PLCs simultaneously.

3. high speed may not be that important. most automation projects do not involve this requirement. (more an observation then anything else).

Just a few random musings.


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

Pete Cleaveland

I agree with Bob ([email protected]). If the new system is not compatible with existing equipment in as many ways as possible, and if guys with dirty thumbs can't program it in the field, it will fail.

Another thought: In addition to allowing user-defined functions, it should have sufficiently modular application programming that a user can build a library of subroutines.

Keep up the good work,

Pete Cleaveland
Senior Technical Editor
I&CS
 
L
> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> Sent: Friday, January 07, 2000 8:18 AM
>
> 2. Before people go crazy and start writing code perhaps some thinking should be put into what the implementer of the control system is going to need. I would like to see something readily usable by me as a PLC replacement, not some hacker's delight (no offense intended).
The thing will never get any wide acceptance unless it is usable by people who are not C
programmers or Linux experts, much the way people who are not WinNt experts can still implement projects using commercial packages.<

Just to twist the focus a bit - there is a literal explosion of 5 inch square "network" or "web-in-a-box" boxes these days (PC-104 stack anyone?).
Even things like particle counters and other high-end sensors have them now.
All of these come pre-loaded & ready to run. Most of them use Linux or another UNIX-like fairly free OS. GPL code? Probably exists somewhere inside or on a CD-ROM, but that doesn't mean your given even a clue as to how to muck-around inside.

There is no reason someone couldn't market the LinuxPLC core in such a form. A 5 inch box with a few LED on front and a few ports on the back. Some
IEC1131 tools creates the code & downloads it by Modbus/TCP. Some HMI shows what's going on by Modbus/TCP. Any PLC user could handle that.

Best Regards
- Lynn Linse

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

> Towards this end, instead of pointing people towards I/O buses that have a small percentage of the market, why not open up and as a very high priority make drivers available for cards to interface to AB RIO and DH, Modbus+, and Genius, along with Devicenet, profibus, interbus, etc. (I didn't mean to leave anyone out, just gave a few examples).<

I like all of your thoughts, but think this one is probably not possible. AB won't release the specs to DH+/DH-485 without one signing a
Technology Transfer Application, and getting it approved. Then you're stuck in a proprietary relationship with AB. Not possible for this
project.

The XFree86 project had a similar problem with Diamond VGA cards for years.

Mark

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

Curt Wuollet

I agree whole heartedly, the GE's and AB's of the world will be less enthusiastic and may make it difficult, but I see this as a great go-between to fix the interoperability problem. Unfortunately the usability things almost have to come last. If the focus is on making it the best rather than the most marketable, it'll be worth waiting for.

cww

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
S
>1. I' d generally agree that a PLC and an HMI "ought" to be seperate machines. However, I don't think it is appropriate for the LinuxPLC group to restrict it so that it has to be done that way. That should be a decision made by the implementor of the control system. <

Mmm, I don't think you are going to get much acceptance for a combined unit on projects of any size.

>I'd like to see something that:
>
>a) Runs ladder logic <

Absolute, non-negotiable, minimum requirement.

>b) Allows for unlimited online programming<

Also, absolutely required. Including expansion of data table, and program files on the fly.

>c) Allows for user defined functions <

Nice, but not rquired. In todays PLC's you can use subroutines for
this.

>d) Supports many different I/O structures.<

Right, huge ammount of money invested in I/O BTW this is where the A/B's of the world make thier money, not on processors. They will be a
whole lot less upset about this project, if the forsee continuing to sell I/O.

>e) supports some form of Netdde or other straightforward way of communicating with existing SCADA systems. These things can't operate in a vacuum.<

Corba?

>g) needs drivers to communicate with existing common PLCs. AB/Modicon/GE, etc. The fact is that the PLC companies are not going to go away. The LinuxPLC will need to have a way to deal with them. In fact, it maybe ought to have the communications capablity to act as a traffic director for multiple brands of PLCs simultaneously.<

Sounds greats!

>3. high speed may not be that important. most automation projects do not involve this requirement. (more an observation then anything else).<

Usually there are at most, a few functions that need to be done at high speed. We need somthing like Selectable Timed Interupts.

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

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

R A Peterson

> That depends... What is your definition of high speed?<

I have a hard time defining it myself, but i consider any normal PLC5 or SLC500 program not to be particularly fast. If you need sub-millisecond response a PLC is probably not a good choice anyway. of course response is also a function of program complexity and size.


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

Phil Covington

> I have a hard time defining it myself, but i consider any normal PLC5 or SLC500 program not to be particularly fast. If you need sub-millisecond response a PLC is probably not a good choice anyway. of course response is also a function of program complexity and size.<

I agree and would be happy with scan times in the 5 - 10 ms range. But to get down in that range, as a minimum, you would have to modify the linux
kernel so that the resolution of the software timer is greater than 10ms (ie. UTIME patch). I have done work with both RT-Linux and KURT and find this all very interesting...

Phil Covington
vHMI


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

R A Peterson

<< I agree and would be happy with scan times in the 5 - 10 ms range. But to get down in that range, as a minimum, you would have to modify the linux kernel so that the resolution of the software timer is greater than 10ms (ie. UTIME patch). I have done work with both RT-Linux and KURT and find this all very interesting...>>


I'd be perfectly happy with timers that had a 1 millisecond resolution. my suggestion would be to store the system time (to 0.001 seconds) when the timer is enabled then each scan check to see how much time has elapsed since then versus the timer preset. that ought to simplify the timer function. if a faster timebase was required the timed interrupt routine as suggested by
another poster would make sense.

BTW - I seem to recall there is some kind of public domain or open source CNC project in the works. Perhaps it would make sense to see if that effort would be compatible with this one.

A question for Ken Crater.

Would your company consider making its controller available under LinuxPLC, perhaps as a commercial add-on?




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

Phil Covington

> >2. Before people go crazy and start writing code perhaps some thinking
> >should be put into what the implementor of the control system is going
> >to need. I would like to see something readily usable by me as a PLC
> >replacement, not some hacker's delight (no offense intended). The thing
> >will never get any wide acceptance unless it is usable by people who are
> >not C programmers or Linux experts, much the way people who are not
> >WinNt experts can still implement projects using commercial packages.

A very useful thing would be to design some sort of architecture for the whole thing, so that the individual parts will fit together once they are
all ready.

I'd suggest something resembling SANE: there's a bunch of back-ends, a middle-end and a bunch of front-ends.

A back-end talks to an I/O device, either directly or via a bus or network driver (note: bus drivers are not back-ends unless the whole bus is to be treated as a single device).

The front-ends should include:
- C interface
- stepladder interpreter
- (any other languages as desired)
- monitoring software
- HMI [1]
- SCADA [2]
- PLC server (ie, emulate a PLC on a bus)
- Corba server
- a redirector (copies inputs to outputs, usually between different
backends)

I would suggest that the front-ends use addressing that is completely independent of the actual I/O device (to be called the "logical address"). The middle-end would translate these into actual device designations.

Either the middle-end or a special back-end would also provide "internal relays" for simple communication between the parts. (Complex communication is up to the parts involved, at least for the time being.)

Any number of front-ends can run at the same time.


Comments?


Jiri

[1] if control and HMI are to be separate (and both implemented in linuxPLC), each box runs its own middle-end and the appropriate front and
back ends. As far as the HMI box is concerned, the other box is just a PLC (the only PLC it can see, if it's done properly). Alternatively, some of the HMIs can use a client-server architecture where the server is thin enough not to get in the way.

[2] does this actually mean anything or is it just a buzzword?
--
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

Sage, Pete (IndSys, GEFanuc, Albany)

>e) supports some form of Netdde or other straightforward way of communicating with existing SCADA systems. These things can't operate in a vacuum.<

The OPC Foundation is building a spec for XML for OPC, which should be out soon. I'd look at using this for interoperability between LinuxPLC and
Win32 platforms.

Pete

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Mon Jan 17 17:06:54 2000 Jan Krabbenbos wrote...
>
>Hi all,
>
>Since last week I've been reading through the messages on the LinuxPLC mailinglist. I've got the few questions about the project, before I jump
>into the discussions:
>- Is there a summary or a document that states all the decisions made on
>the design of the LinuxPLC? All the information is fragmentated in the
>load of messages on the list.

No, I have been thinking of sketching out a preliminary design spec, but have not found the time.

>- How are things organized within the group of people attending the
>list? At the moment I've got the feeling some people have their own
>LinuxPLC already up and running. This might not be true, but that how
>_I_
>see it at the moment.

Unfortunately, it only exists in our minds.
>
>I hope to be usefull for the project, both in helping with the design
>and programming (If my boss leaves me some time :). I have programmed
>PLCs for approx. 10 years, mainly Siemens S5, S7. Had a few projects
>with AB and Modicon. Further I did a lot of HMI and SCADA project. I
>have designed and programmed compilers for a subset of the IEC1131-3
>Structured Text language to Instruction List language and from
>Instruction List to 2 different Siemens S5 PLCs. I still have the YACC,
>Lex and C code for that, although I know for Bison and Flex I have to
>adapt it (and solve a few bugs). Currently I am employed as a C/C++
>programmer for Unix.

Wonderful, sounds like a useful combination of skills to contribute to
the project.

Welcome to the fray :)


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

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