Some random observations... (kinda long rant - sorry)

R

Thread Starter

Ron Gage

Hi folks.

I hope you all don't mind me jumping in with my humble opinions here...

First, might I suggest that we all work on BUILDiing a project, instead of the finished product. There has been a lot of really good discussion here and there about the advantages and disadvantages of this and that. This is
wonderful, but without much purpose at this point. I am basically suggesting that we need to work FIRST on the basic problem - solving ladder logic or a logic engine if you prefer that nomenclature. This is not a trivial problem.
Consider the problem of how to solve parallel contacts. Now add in parallel outputs. Now add in the 'data handling' instructions (MOV, COP, FAL, etc). Let's not forget our friends, the Timers and Counters. This problem must be
solved first, "how to solve the ladder". Without this solution FIRST, all other considerations are irrelevent!

As for the conversation about Nxxx:xxx versus SomeAddrLabel for I/O and data table labels. Have you given any thought to how to do this from a programming standpoint? Sure, it's nice to have an i/o point tell you immediately what it
is (GateClosedLS versus I:002/03) but the implementing labels like that will complicate the coding effort. Again, I say, FOR NOW, concentrate on the basics - making it work. We can always add in an OPTION for using text instead of addressing for I/O (and memory) points.

Regarding having some form of retentive memory. Basically, I think we will need a hardware solution for this if you want RELIABILITY. A battery backed SRAM board. This will be an easy design, simple address decoder, a couple of
SRAM chips, a couple of diodes, a few caps, maybe a pullup resistor or 2, and a lithium battery. ISA boards are real easy to design for things like this. Remember that any system that out project goes into WILL see unexpected (and
improper) shutdowns. It WILL see hardware failures. It WILL be abused to the point of failure. It MUST be able to handle it or we will be no better than any other PC based PLC out in the real world.

Regarding the ladder versus any other language of your choice, the answer here is simple. You must always keep in mind WHO will be using the machinery that this is attached to. It isn't some engineer up in the front offices, it isn't
the manager who oversees the engineering, it isn't the plant manager. It is the machinery operators AND the maintenance electricians who will ultimately be the ones using this project. The machine operators have to be able to start up
and use the machinery from a cold power on. The electricians must be able to diagnose problems with a reasonable amount of accuracy and speed. As such, it is in OUR best interest to keep things as familiar as possible. What does just
about every maintenance electrician know - ladder. Unless you want to be the one who introduces new technology to the masses (and train them as well), let's keep things simple (and focused) here. There may be some debate about AB style vs Modicon vs GE vs whatever. With apologies to our comrades who are in
Modicon or GE 'houses', I would suggest staying with AB style (IEC 1131-3) ladder. At least here in the states, AB is the most popular PLC out there in terms of numbers.

As for data table configs, I would recommend (and fight for) using the AB PLC3/PLC5-250 style of addressing (without the module ID that the 5/250 tacks on). Why? This method of addressing allows multiple file types (Counter, Timer, iNterger, Binary, Float, etc) to share the same file number. For example: on a 5/250, you can have N7:0, T7:0, C7:0 and even B7:0 (if you are
so inclined) in the same program, these all address SEPERATE data tables/adresses. In a PLC 5/80, this is not possible - once file 7 is made
into an iNteger, it can be nothing else.

Ok, I'm off the soapbox now. I hope this isn't considered a flame! That certainly wasn't the point! I'm just trying to push the project towards gettiing something workable!

Ron Gage - Saginaw, MI
([email protected])

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
S
On Mon Jan 17 12:05:17 2000 Ron Gage wrote...
>
>Hi folks.

Excelent post!
>
>I hope you all don't mind me jumping in with my humble opinions here...
>
>First, might I suggest that we all work on BUILDiing a project, instead of the
>finished product. There has been a lot of really good discussion here and
>there about the advantages and disadvantages of this and that. This is
>wonderful, but without much purpose at this point. I am basically suggesting
>that we need to work FIRST on the basic problem - solving ladder logic or a
>logic engine if you prefer that nomenclature. This is not a trivial problem.
>Consider the problem of how to solve parallel contacts. Now add in parallel
>outputs. Now add in the 'data handling' instructions (MOV, COP, FAL, etc).
>Let's not forget our friends, the Timers and Counters. This problem must be
>solved first, "how to solve the ladder". Without this solution FIRST, all
>other considerations are irrelevent!

I agree. However I feel like we need to define the intercommunication between the logic engine, timer engine, I/O scanner etc, and get the access libraries for this done, before much coding of say a ladder logic solving engine can be done. After all, what is it to solve?

>As for the conversation about Nxxx:xxx versus SomeAddrLabel for I/O and data
>table labels. Have you given any thought to how to do this from a programming
>standpoint? Sure, it's nice to have an i/o point tell you immediately what it
>is (GateClosedLS versus I:002/03) but the implementing labels like that will
>complicate the coding effort. Again, I say, FOR NOW, concentrate on the basics
>- making it work. We can always add in an OPTION for using text instead of
>addressing for I/O (and memory) points.

That's my feeling also.
>
>Regarding having some form of retentive memory. Basically, I think we will
>need a hardware solution for this if you want RELIABILITY. A battery backed
>SRAM board. This will be an easy design, simple address decoder, a couple of
>SRAM chips, a couple of diodes, a few caps, maybe a pullup resistor or 2, and a
>lithium battery. ISA boards are real easy to design for things like this.
>Remember that any system that out project goes into WILL see unexpected (and
>improper) shutdowns. It WILL see hardware failures. It WILL be abused to the
>point of failure. It MUST be able to handle it or we will be no better than
>any other PC based PLC out in the real world.

You are probably correct here. I brought this up to get some thinking going on about it, and to make certain we do not make design decisions that would make implementing this hard.

>Regarding the ladder versus any other language of your choice, the answer here
>is simple. You must always keep in mind WHO will be using the machinery that
>this is attached to. It isn't some engineer up in the front offices, it isn't
>the manager who oversees the engineering, it isn't the plant manager. It is
>the machinery operators AND the maintenance electricians who will ultimately be
>the ones using this project. The machine operators have to be able to start up
>and use the machinery from a cold power on. The electricians must be able to
>diagnose problems with a reasonable amount of accuracy and speed. As such, it
>is in OUR best interest to keep things as familiar as possible. What does just
>about every maintenance electrician know - ladder. Unless you want to be the
>one who introduces new technology to the masses (and train them as well), let's
>keep things simple (and focused) here. There may be some debate about AB style
>vs Modicon vs GE vs whatever. With apologies to our comrades who are in
>Modicon or GE 'houses', I would suggest staying with AB style (IEC 1131-3)
>ladder. At least here in the states, AB is the most popular PLC out there in
>terms of numbers.

Agreed. However by using the "logic engine" concept, we are not locking out any style of programming language that anyone wants to implement. Perhaps even one not yet thought about!

>As for data table configs, I would recommend (and fight for) using the AB
>PLC3/PLC5-250 style of addressing (without the module ID that the 5/250 tacks
>on). Why? This method of addressing allows multiple file types (Counter,
>Timer, iNterger, Binary, Float, etc) to share the same file number. For
>example: on a 5/250, you can have N7:0, T7:0, C7:0 and even B7:0 (if you are
>so inclined) in the same program, these all address SEPERATE data
>tables/adresses. In a PLC 5/80, this is not possible - once file 7 is made
>into an iNteger, it can be nothing else.

Again, I agree.
>
>Ok, I'm off the soapbox now. I hope this isn't considered a flame! That
>certainly wasn't the point! I'm just trying to push the project towards
>gettiing something workable!

I am glad someone else posted this. I was trying to think of how to do it politely :)
>
>Ron Gage - Saginaw, MI
>([email protected])

AKA the AB PLC Ethernet man.

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

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

Jack Gallagher

I completely agree with your point on professionalism. No need to tear anyone up that disagrees or does not see things your way.

I do disagree with your approach. I believe that some small amount of documentation should be generated which provides some set of requirements
and a modular look at the system. Then split up the modules and write some code. When problems arise discuss them as soon as possible. Lack of
documented requirements is the number one reason software projects fail. :(

>Remember that DIPLOMACY is the art of telling someone to go to hell and
>making them look forward to the trip.

>Dave Pryor
>[email protected]




_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
D
On Tue 1/25/2000 Jack Gallagher wrote . . .
>I do disagree with your approach. I believe that some small amount of
>documentation should be generated which provides some set of >requirements
and a modular look at the system. Then split up the >modules and write some
code. When problems arise discuss them as soon >as possible. Lack of
documented requirements is the number one reason >software projects fail. :(

I have to agree with your point! There is where someone needs to step forward and get the ball rolling. It is also something I am not very
qualified to do, and I realize that. My concern is with the members who have volunteered to do the coding. We need to keep them from losing interest in this project. I've seen some very good debate among them, and it looks like they are doing a good job of sorting things out. I just don't want to see talent drift away before we get started.

Dave Pryor
[email protected]


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