ControlLogix Learning Curve?

Paully's5.0 said:

I am confused by the "straight logic" remark, are you saying that a single sub-routine of 1000 rungs of logic is easier to follow than 10 sub-routines of 100 rungs each? I certainly don't agree with that, but then it's personal preference at that point.

Click to expand...

I agree with you! In this instance, for a test run I replaced the code that set up the subroutine, and put the applicable rungs in instead, and used far less rungs that was initially involved in both the setup and the subroutine. The setup rungs were longer than the subroutine. There was seemingly a lack of brains involved.

While I like a "package", in this environment it needs to fit a little better. We also have the "bible", a set of SAFE charts that HAS to be followed. On other platforms I've seen this set apart as a program section, and it's easy to check and follow. Here, it's shotgunned throughout. I couldn't tell you where any particular function is without searching.

I like simple. Here we don't have process control like other places, and the need to troubleshoot and put the system back online is hindered by the way the code is written. That's just an observation of mine... other programmers who have worked on this have also called it "bad" so maybe it's not just me.

Interesting discussion....

I have worked with programmers who right from the start deliberately set out to make things as confusing as possible...I think that they are probably insecure in their job....

I have also saw a company policy of locking access to as much as possible and making it impossible for the poor end user to even do routine fault finding for maintenance....

... this attitude seemed to be driven by a fear that the end users are all out to "steal" the PLC code...

My suggestion that the end users that we work with (very large international companies)easily have the resources to programme their own code for our systems if they chose too, it is just cheaper for them to pay someone else to do it, ...did not go down very well at all.....

peterjung said:

Interesting discussion....

Click to expand...

+1

I have seen systems that have been written very quickly by SI's because they have automatic code generators, so all of the JSR setups are coded for the programmer. I am with tomalbright The programs need to be written so that they are easy to fault find through. I have been paid four times in the last 2 years to re-write PLC programs for large companies that have been delivered on machines written in "standard code", 1/3 of the program did not even apply to the delivered machine! The cost justification for the rewrite was good shift electricians were taking ages to find the problem (1/2 day), the program was sometimes locking up and the coding method used made it very hard to fix without breaking something else. (Multiple OTU OTL and AOI's that indirectly OTE the same bits yuck)

It's a sick twisted world we work in isn't it!?

ULTIMATELY, it's up to the end customer to specify a standardized method of programming to an OEM/SI to be used in the project that they feel is appropriate for their facility. If the end customer cannot supply a programming standard, and will not PAY the premium for those standards to be implemented by an OEM/SI, than not much will change. The OEM/SI has a bottom line to feed as well.

I guess, this is just advice for those who maintain equipment, if you don't like the methods you see being used, then it is up to you to push-back to management, push to develop internal standards to be specified on new projects and have the data ready to justify the added cost of doing that.

If you've had to bring in a guy like MichealG to re-write a system, it's pretty easy to justify internal standards.

SLC/PLC........................................ Logix Platform
Data table Address .............................Tag
Symbol ......................................Tag/Alias Tag
Ladder File 2 ............................A Main Routine in a given program
Ladder (3-255)/(3-999) .................A subroutine in a given program
STI .......................................Periodic task
DII/PII .....................................Event Task
Data Table/File...............................Array

Tags are nothing new. They've been in processors since the beginning. A tag is simply an alphanumeric string pointing to a location in memory. Be it...M012....N12:30...or Oven_Setpoint.

The difference is, different manufactures have referred to them as "register"...or "data table addresses"..or (now) "tags"...

Where the "tags" were predefined in the SLC500/PLC-5...we can now name them anything we want in the Logix platform. Long tag names do make for bad display on rungs with severial instructions in series.

Nitpick - Logix tags are different, in a sense. In the old-style AB PLCs, you had set data registers, then you could make your own. All of them had to be predefined to be used, and essentially make "blocks" out of your data tables.

GE 9030s have an entire memory setup predefined, but still a block.

Logix has tags, true, but no "blocks". You make what you need. It works exactly the same way, but you don't have to worry about defining blocks to make your stuff work.