SLC 505 V Compactlogix L35E

[hooey]

[font=&quot]I would like to hear some opinions on the relative merits of both platforms. Does the 1.5m memory in the compactlogix have 20 times the program/data table usage of say a 64k SLC505 or is the memory allocated in some other way. Any known limitation with devicenet i/o in regards both platforms.


hooey[/font]

 

[PhilipW]

In general the Logix platform uses memory at about 10-12x the rate for SLC. There are a bunch of perfectly good reasons why, so a 1.5M L35E is about the same as a 5/5 with say 120k of program.

In general I would transition to the CompactLogix unless there is some compelling reason to stick with the SLC.

1. For most systems the CompactLogix will likely be cheaper.

2. Programming will typically be about twice as productive.

3. The SLC is in the last 25% of it's commercial life, whereas the CompactLogix is established enough not to be bleeding edge, but is about 12 years younger.

The only real downside is that the 1769 IO system has fewer 3rd party specialist modules available, and is by comparison the to 1746 IO system, a little less physically robust.

 

[theDave2]

1. For most systems the CompactLogix will likely be cheaper.

Quite true. A lot cheaper in many cases.

2. Programming will typically be about twice as productive.

HUH ?

I find that it takes me 2 - 3 times longer to program / debug a CLX system:

1. Less logic on the screen due to tag names causing less contacts to be displayed in a view. Maybe they have (post v11) made tagnames use multiple lines ?

2. Slower screen update of contacts & registers. I'm talking direct serial from my laptop.

3. Have to scroll back & forth in the tag file (monitor mode) to see tag values that are not being displayed in the logic vs either see a lot of values in a SLC data table or custom monitor. Is there something in CLX I'm missing ?

4. Having to type in / define a tag for every bit & register & I/O point (besides the standard description & comment I put in regardless of system) vs just having them all predefined as something like N7:12

In fact, in the next CLX system I do, I'm going to make my tags in Excel in the form of N7xxx, since I'll have a multi-line description too, an import them to CLX. That should save on typing, screen real estate, ... No Flames on this, my mind is made up. Did the same for Siemens S7 and saved loads of time. And yes I program in many computer languages so I know about variable names & typing them , ...

 

[TimWilborne]

I'm the opposite. I've done so many Logix 5000 projects now I have a hard time going back to Logix 500. But there is one heck of a learning curb.

1. I'll agree with you on this one if you use descriptive tag names, but something short like TAG1 is same size. Have you looked at using user defined tags?
2. Haven't noticed this but you could be right
3. Go to View, Watch. Then click Quick Watch and see if that helps
4. What is the difference between N7 data file in RsLogix 500 with a size of 100 and a N7 tag in RsLogix 5000 type INT[100]. N7:51 = N7[51]. Don't see much difference. Plus the third dimension is very nice when indexing

Quite true. A lot cheaper in many cases.



HUH ?

I find that it takes me 2 - 3 times longer to program / debug a CLX system:

1. Less logic on the screen due to tag names causing less contacts to be displayed in a view. Maybe they have (post v11) made tagnames use multiple lines ?

2. Slower screen update of contacts & registers. I'm talking direct serial from my laptop.

3. Have to scroll back & forth in the tag file (monitor mode) to see tag values that are not being displayed in the logic vs either see a lot of values in a SLC data table or custom monitor. Is there something in CLX I'm missing ?

4. Having to type in / define a tag for every bit & register & I/O point (besides the standard description & comment I put in regardless of system) vs just having them all predefined as something like N7:12

In fact, in the next CLX system I do, I'm going to make my tags in Excel in the form of N7xxx, since I'll have a multi-line description too, an import them to CLX. That should save on typing, screen real estate, ... No Flames on this, my mind is made up. Did the same for Siemens S7 and saved loads of time. And yes I program in many computer languages so I know about variable names & typing them , ...

 

[kamenges]

The productivity point depends largely on the system. Having the ability to run multiple programs with (reasonably) identical logic and program tags can decrease development time. Also, if you have multiple occurrences of components or functions you can create structures. This will allow you to create a (relatively) large number of data items by defining one tag.

If your particular system doesn't allow you to make use of these types of programming methods then programming a Logix platform device will probably take longer.

Keith

 

[PhilipW]

I find that it takes me 2 - 3 times longer to program / debug a CLX system:

If you treat the CLX as if it was just a glorified SLC then I can see how you might reach this conclusion. Unfortunately for you it would appear that you are therefore missing out on the real potential for 2-3 times BETTER productivity that the rest of us appear to be enjoying.

For a start...if you are not using UDT's....then you have missed most of the game.

At V15, the UDT comments are automatically concatenated.

And once you have created your UDT structures, now try creating arrays of UDT tags.

 

[Sheldn]

I agree with PhillipW on the comments made regarding use of UDTs. There is a learning curve with the Logix platform regarding scanning, use of routines, tasks, and data structures etc... but once you see what the UDT (data structure) can do for you it is powerful. Creating your own UDTs that area ssociated with a device such as a VFD, motor, Valve, analog input, digital input or other (use your imagination) or based on your application needs allows you to develop data structures and logic that is very self documenting. It provides for the "properties" (UDT for example) and "methods" (Standard Subroutine Logic for example) part of object oriented programming in the PLC.

There are differences at the hardware level but you can get used to it.