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