Shared memory / persistence / io polarity

B
Thinking back on it, I remembered that we actually only recovered from the same state after an E-Stop. A think a power cycle did reset the logic. On an E-Stop, we killed outputs, but kept track of which outputs were on with internal coils. The inputs always remained active, so that certain conditions could reset the system.

Bill Sturm
Applied Grinding Technologies

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

Scott Jensen

Hi List,
I think Bill Sturm laid out the obvious idea about the system always restarting in an E-Stop condition. This gives you a chance to match existing conditions with what you have on your screen. A lot of the restart safety is
inherently written into the "ladder" program. We have a huge burner system that would never restart with the gas on because there's no flame, so it automatically starts from square one. While on another system that moves huge aircraft skins through a multistage process, it would be a nightmare to lose all the information for each piece and where it is. I think the software should always retain all the information and let the "ladder" program deal with it accordingly.
My 2 cents worth from the factory floor,
Scott Jensen
Boeing

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
S
Just to throw in another interesting example, I have a system that controls power generation, and distribution for a paper mill (approx. 85MW). In the power world everything is upside down from the machine control works. All inputs (including trips) are N. O., all outputs must come on to change the state of a breaker (open or close). However this is critical data that MUST be preserved over power failure.

On the other and I have systems control paper machines. These have N. C. stop buttons,and permissive interlocks, and hold an output on to
cause motors to run.

So the moral of the story s that there a wide variety of diverse applications for PLC's, and we need to try to bear this in mind as we
design this project.

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

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
S
>I don't think there's any reason it can't be done in a number of ways,
>whether using battery-backed RAM or write to the journalling file system.
>The particulars of how it's done might be left up to a persistent memory
>driver or component, but the interface/hooks can be the same.
>
>IMHO, instead of I or O (which has been discussed), a better
>example for retention of information might be for run-timers, statistical
>data on the process, etc.

That is exactly what I have been trying to say.

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

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
S
>A couple observations/questions.
>
>1. How fast does the scan need to be to be viable in most applications? 100
>msec? I'd guess the overwhelming majority of PLC applications do not require
>much more then this.

Very few of my PLC projects would work with a scan time this slow. Most I work on require at least a 35MS (faster is better) scan time.


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

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
M
One design issue (which is obviously fundemental to this list) is the fact that no matter how you skin the cat, a machine (PC) designed as a general
purpose tool is just one big compromise and is never going to be as good as purpose designed/built tools (PLC).

You have to look for the benefits elsewhere, and this list (or the Automation list) has made some good arguments, which is part of the reason
atleast, that this project exists.

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Guys,
In regards to scan times; As a long time PLC user, I always try to keep PLC scan time below 20 msec. On large processes this is not always possible and I've had a few scan time as large as 50 msec. But remember that a PLC is emulating relays which can operate in 1 power cycle, so let's try to maintain that speed as a point of reference.

Dave Hurd
GE Appliances

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

Simon Martin

Personally I would be against using anything like this. If we have MySQL up and running we have another daemon on the competing for CPU time, another set of complexities inherent in the LinuxPLC, how robust the database to non-orderly shutdowns, amongst other reasons I can think off. Let's keep the PLC machine as simple posible. I see it running the OS, inetd (maybe telnet, maybe ftp, but very little else), the PLC daemons and that's about it.

Well that's my opinion

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

There is a chasm of carbon and silicon the software cannot bridge

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
M
<clip>
one thing I do want to see in the RLL engine (if we can call it that) is the capability of using function blocks. Being able to create a piece of code and then reuse it over and over again is a very powerful way of organising your code. In fact, its probably the only PLC thing they really "should" have put in that is missing.
</clip>

missing from what?

Function Blocks are included in IEC 1131-3 and are one of its most important features.

If you mean they are missing from the LinuxPLC, they are not because there has not been much published on the logic engine(s) yet (I hope to remedy that in the near future).

Regards
Mark Hutton
Software Engineer
Vogal Software Services
Regent House, Welbeck Way, Peterborough. UK PE2 7WH
Tel: +44 (0)1733 370789 Fax: +44 (0)733 370701
[email protected]

============P-P-Puffin' Power=======


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