[email protected]:
> RLL doesn't really have another software equivalent that I know of. Its
> ancestry is old contact/coil relay diagrams. It's kind of graphic binary
> program for PLC's.

Or, from another point of view, Forth.

Many RLL dialects are implemented and can be understood as stack-oriented. Think of the AND-block and OR-block instructions. However, an OUT doesn't pop the stack, and the stack doesn't overflow (discards oldest entries).


Jiri
--
Jiri Baum <[email protected]>
What we do Every Night! Take Over the World!

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

 

Hi Tim,

Would you like to start by writing a very small module mapping the keyboard keypressed state to linuxplc internal points?

Once you get the feel of the linuxplc architecture maybe you could help out with the linuxplc library itself. It shouldn't be very difficult to come to a consensus on what to include and how to write the the module launcher. This would be a nice addition to the linuxplc library.

If you want to start writing code, send me an email and I'll give you the specifics on how to interface to the library. You could start by stealing some code from the demos to get the main scan loop code, and start adding the keyboard specific code.

If you prefer something else, give us an idea of the area you would like to tackle most, and I'm sure something will come up.


Cheers,

Mario.

----------------------------------------------------------------------------
Mario J. R. de Sousa [email protected]
----------------------------------------------------------------------------

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

 

In a message dated 00-11-03 04:37:33 EST, [email protected] writes:

> [email protected]:
> > RLL doesn't really have another software equivalent that I know of. Its
> > ancestry is old contact/coil relay diagrams. It's kind of graphic binary
> > program for PLC's.
>
> Or, from another point of view, Forth.

I always liked Forth. Never did have opportunity to use it, though. (Postscript is very similar although a few years ago I remember a discussion
thread denying heritage)

> Many RLL dialects are implemented and can be understood as stack-oriented.
> Think of the AND-block and OR-block instructions. However, an OUT doesn't
> pop the stack, and the stack doesn't overflow (discards oldest entries).
>

I like it.

That's at least the second or third Excellent Insight in the past two postings!

I really HAVE to stop by here more often

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

 

Hello Fellows,

Fourth is rather neat, however, if something breaks or has a problem from what little I have done with it, I would not want to have to
rebuild the program for a small problem.

My suggestion as before does sound a bit arcane, however I think the best way to develop the user interface is to have the control logic and software separate from the user / operator (programmer) interface.

I have done a fair amount of programming on some of the GE, Modicon and Allen Bradley equipment in the past. When your having to modify
programs ->while equipment is running<- their interface makes it easier than most. The important part is not so much what language / interface to the software is in place. The most important part is having a way to debug the operation as quickly as possible. This may not sound difficult, but I have seen many a ladder logic program that was quite complex. Sometimes the way the logic was solved made a huge difference in what the program did.

There are a number of differences in how the logic is solved and propagated to the i/o that are worth some thought.

Dave


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

 

Hi Dave

We have had the ordered execution discussion before but I, for one, am glad you brought it up again as it relates to synchronization. Many RLL
programs do rely on "top to bottom, left to right, last definition wins" type rules. Whether they should or not is another discussion, but they do. Those of you who make a living with RLL can perhaps get these expectations documented or at least clearly stated?

Regards

cww

PS I was joking about FORTH although is is a cool extensible language.


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

 

I haven't really been following this discussion lately, but documenting the RLL top to bottom execution rules is a little like documenting that water freezes at 0degC. Unless otherwise specified all RLL types will simply expect top-to-bottom, with the input table read before the scan and the output table written to the actual outputs only after the scan.

Mark


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

 

Was that so hard? :^)

Actually there are other subtleties that cover ambiguities and things that good RLL programmers "just know". At least that's what I hear from RLL programmers. I know I've had some surprises.

Kinda like water boils at 100 degrees, most places except Denver or the Tower-Soudan mine.

cww

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

 

Curt Wuollet:
> We have had the ordered execution discussion before but I, for one, am
> glad you brought it up again as it relates to synchronization. Many RLL
> programs do rely on "top to bottom, left to right, last definition wins"
> type rules.

Just to forestall confusion, let me note here that "synchronization", as the term is used in the lPLC, is not necessary for the above rules to hold.

In particular, it is "last definition before plc_update() is called", regardless of what other modules may be doing simultaneously.

Similarly, each input is "as it was last time plc_update() was called", unless the program itself changes it (generally not recommended).


The RLL interpreter/compiler will call plc_update() at the top/bottom of the relay diagram, not in the middle (unless specifically requested).

Jiri
--
Jiri Baum <[email protected]>
What we do Every Night! Take Over the World!

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

 

> Mark Bayern wrote:
...
> > a little like documenting that water freezes at 0degC.
...

Curt Wuollet:
> Kinda like water boils at 100 degrees, most places except Denver or the
> Tower-Soudan mine.

Approximately 0degC, approximately 100degC. The Celsius scale is no longer defined in terms of water freezing/boiling points. It is now defined in terms of kelvins (temperature in kelvins minus 273.15), which are in turn defined by the tripple point of water (273.16K) and absolute zero.

[rearranged]
> Actually there are other subtleties that cover ambiguities and things
> that good RLL programmers "just know". At least that's what I hear from
> RLL programmers. I know I've had some surprises.

I *think* most or all the subtleties are covered by:
- stack orientation (LD = push, OUT = write top-of-stack)
- rungs are not if-then statements but calculate-write (only a few
instructions, notably SET and RST, are conditional)

Of course, neither the Japanese nor the Americans are capable of writing this in their manuals - even reference manuals - preferring instead
convoluted analogies to real relay circuits and a few simplistic examples.

I've only ever seen this explanation once, in an Eastern-European manual. I don't think I ever truly grokked it before then.


Jiri
--
Jiri Baum <[email protected]>
What we do Every Night! Take Over the World!

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

 

Excellent Jiri,

We have the important part of an RLL interpreter spec. and you've reassured me that we will have this covered. I'm still intrigued by the implications of fast and slow IO as elements of the same logic equation eg coincidental in physical space but perhaps not in the map due to prop delays etc. That will still be a source of
head-scratching. This is normally covered quite handily by a 10ms scan. As we try to go faster, many ugly physical and electronic phenomena PLC users have been free to ignore will loom large. Hook up a fast scope to some of these signals and you will marvel that they work at all. Witness the heavy filtering built into input modules, time constants sometimes exceeding a scan. Still, if they get away with it, perhaps I just worry too much. (The baggage of an ill-spent youth working with sub-nanosecond logic). Working with
a 20 usec scan and cmos logic already means that lead dress and grounding are important. Common practice, eg open wiring and long non-terminated cables are already useless. We may want to plan
to synchronize scans or at least control scan time as I doubt the automation world wants to be introduced to transmission line theory or distributed constant networks any time soon 8-P. I will look at some more common stuff to determine how fast we can go before things become too non-obvious.

regards

cww


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

 

Whoooaaaahhhhh ....

We are getting way off on a tangent here ....

Cable Dress, delays, and time constants don't really apply to the design of IPLC. We don't want some of these developer-only people freaking out about their IO signals and such.

The bottom line is that hardware should not be thought of, except in the sense that it will be handled by the drivers. Input filtering and
Fieldbus latency should be handled by the Hardware and not thought of by IPLC. OBviously, the end user needs to know that fieldbus IO is
going to be slower than backplane IO, but this is already the case in industry, and the world has adapted where necessary.

Tranasmission line theory is not needed. CE regulations, as well as common design practice says that slew rate limited output drivers should be used for this very reason. It is a hardware issue only. If someone wires up an input directly to High speed CMOS logic than they deserve the results they get!!!!!

)

I see IPLC not only being a replacement of PLCs, but also an enhancement (as I know most of you are thinking as well) As an employee of a company that produces high speed assembly machinery, it
is very important to have things like scan rates be as fast as the PC hardware can reasonably handle (Which is well under a millisecond). At
my company, an increase of scan rate from 1 to 2 ms can cost us hundreds of thousands of dollars in wasted time. While a lot of industrial users still stick to the 20ms filter constants and 10-50 ms scan rates, this is not the rule. There are an increasing number of users trying to speed up their process and reducing scan time is one
great way of doing this.

Curt says that scan time might want to be controlled ... does this mean that (currently) the logic task is running freely all the time???
What then Pre-empts logic?? Regardless of whether or not IO scans are synchronized, it is important for the logic to be on a regulated. One thing Steeplechase software does with its VLC product is monitors the logic solve time in order to see when it exceeds the scan time (VLC is a hardware interrupt based fixed scan period) and if it exceeds it for a number of times it halts the process (Which is great if you do something really screwed up, at least the machine stops!!!)

Does IPLC run the logic scan and then call the IO Driver Process at the end?? When does the linux kernel get a slice to execute ??? Wouldn't IPLC starve the rest of the linux processes????

~Ken

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

 

<clip>
> Curt says that scan time might want to be controlled ... does this
> mean that (currently) the logic task is running freely all the time???
> What then Pre-empts logic?? Regardless of whether or not IO scans are
> synchronized, it is important for the logic to be on a regulated. One
> thing Steeplechase software does with it's VLC product is monitors the
> logic solve time in order to see when it exceeds the scan time (VLC is
> a hardware interrupt based fixed scan period) and if it exceeds it for
> a number of times it halts the process (Which is great if you do
> something really screwed up, at least the machine stops!!!)

The point Curt is making is that we should think this through and know where we are going. it's not just a hardware problem if we have a 10 to 1 ratio between hardware response times, it means we can have changes in the map that never happen on the wire.

>
> Does IPLC run the logic scan and then call the IO Driver Process at
> the end?? When does the linux kernel get a slice to execute ???
> Wouldn't IPLC starve the rest of the linux processes????

Not if we are using "fair" scheduling, the norm for Linux. At this time all this runs in the normal multitasking environment. Steeplechase is using a realtime executive with win whatever as the lowest priority task and can starve the OS if the RT tasks overrun the schedule. We wait for higher priority tasks for now. This will cause irregularities but, we'll deal with that later.

Regards

cww

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

 

Ken Emmons, Jr.:
> Curt says that scan time might want to be controlled ... does this mean
> that (currently) the logic task is running freely all the time???

Yes, by default.

> What then Pre-empts logic?? Regardless of whether or not IO scans are
> synchronized, it is important for the logic to be on a regulated.

At present, nothing (we aren't real-time anyway), but either the synch library or something new could do that. One possibility would be a module
that signals on a synchpoint at regular intervals and does nothing else.

> One thing Steeplechase software does with it's VLC product is monitors
> the logic solve time in order to see when it exceeds

Sounds useful, and also fairly easy to implement.

> Does IPLC run the logic scan and then call the IO Driver Process at
> the end??

By default, the two are separate and asynchronous, with the logic module
providing/accepting its data at the end/beginning of its logic scan and the IO Driver Process providing its data whenever it does.

With the synch library, it's possible to set them to alternate, or to various other arrangements.

> When does the linux kernel get a slice to execute ???
> Wouldn't IPLC starve the rest of the linux processes????

Currently it's not real-time scheduled, so no. That'll be one of the things the real-time porters will have to worry about...


PS: could you set your mailer to quote in the usual fashion? I'm not familiar with Novell GroupWise 5.2, but it should have the option...
otherwise I'll start calling it GroupFoolish

Jiri
--
Jiri Baum <[email protected]>
What we do Every Night! Take Over the World!

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

 

The new Allen Bradley ControlLogix system updates the I/O table asynchronously, so that inputs and outputs can change in the middle of a logic scan. Do not see the advantage to this, can see lots of
disadvantages.


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

 

Actually Jiri, I am fond of calling this email system Poop-Wise. It is closer to the truth. We have not yet embraced the linux world at my
company yet. (I am used to Netscape mail, but our retarded Novell Poop-wise server has trouble with netscape and IMAP) Unfortunately I do not have a large say in the IT department (except for what we run on our industrial machine PCs)

(

So I guess the Plan is to port the core code to an RTOS eventually?? I admit this is attractive to have it run in native linux for developers.

~Ken

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

 

"Ken Emmons, Jr." wrote:

> (
>
> So I guess the Plan is to port the core code to an RTOS eventually??
> I admit this is attractive to have it run in native linux for
> developers.
>
> ~Ken

I have had the linuxplc running on a RT Linux variant (from TimeSys) without any changes. It only requires some aditional lines to specify
what priority and periodicity the module must run on. I was thinking of making this a linuxplc library function, configurable through the
linucplc.conf file, so any module could automatically be run on a RT Linux, and the user could specify the periodicity and priority in the
linuxplc.conf file.

This doesn't really require much coding, but there is soo much to do, and so few people to do it. It will have to wait for a future oportunity.

I posted my findings some time ago, but if I remember correctly I managed scan times of 500us on a 360 MHz PII.

Mario.

----------------------------------------------------------------------------
Mario J. R. de Sousa [email protected]
----------------------------------------------------------------------------
_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc

 

Yep, I just checked with my AB rep and he confirmed that ControlLogix does I/O concurrently. ...sigh...

When asked about programming issues, he said it is SO fast at the ladder solving that he hasn't seen any issues with this yet.

I wouldn't have designed it this way, but they didn't ask me.

Guess the old days of implementing your own one-shots are gone. On ControlLogix you'd better use their built-in functions. (Why would they care if the code is less portable?)

Mark

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

 

That is very dangerous. I don't understand it. I am not a big AB fan anyway.

~K

 

Interesting, I was just discussing the ControlLogix with my A-B rep Friday. We didn't cover that quirk, but it does, I think, follow
from the system architecture.

The ControlLogix has a shared, passive backplane, with no "bus master." We didn't get into this level of detail, but it sounded as if each card,
including the I/O cards, is responsible for updating "their" data. I would guess that it's implemented as a big shared memory area.
Therefore it would make sense that the I/O points would update asynchronously to the I/O scan, since they are just accessing an address on a shared memory bus.

[I suppose A-B could have done this differently by keeping a copy of an I/O table on the controller board, but that would be more memory => more $$$, wouldn't it?]


FYI,

Zach


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

 

On asynchronous updates of I/O and logic:

I had a problem with I/O completion bits on an old Reliance Electric Automate PLC. They could complete mid-cycle. The (simple) solution
after the (not simple) debugging and discovery of the problem was to simply duplicate the i/o at the top of the scan.

--| |---------------( )
Unruly Scan
Signal Stable signal

And use the Scan Stable Signal.

After this simple workaround, things worked the way I thought I had them programmed

(Note: this has to be done at the top of the scan, so transitional/edge type contacts are handled correctly)

However, on the flip-side (output) it could get a little dicier. I have had situations when I want a hard set or reset to override normal program logic. But an analogous workaround would be to use an in-memory coil to store the output, to be copied out at the *end* of the scan.

However, I have never used a system that would update outputs prior to the end-of-scan.


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