Control Logix learning curve

[Paullys50]

I think the problem many people have is that 5000 does not organize the tags for you, it's up to the programmer to take on that task which is of course a learning curve in itself. If you aren't consistent with tag names your program can get pretty ugly.

I've found that UDTs are great, but limited(no online changes), so I also try to create tag arrays which act similar to the data files in 500. I then alias those base tags with consistent name conventions. So N7:0/0 looks like N7[0].0 in 5000. Unfortunately I do wish there were better ways to identify "unused" bits/words within an array.

I find that a couple of hot keys have made life very easy when working with 5000. This first is Ctrl+Tab. This allows you to tab through the ladder window, tag window, cross-reference windows very quickly and efficently. The second is Cntrl+G, use this when in the tag window, it will open a "Go to" window, just start typing the tag name you are looking for and it will jump to it. Those two have made 5000 a better experience for myself.

 

[a12bee]

Thanks daba, I appreciate the offer and do apologize to the OP for the thread jack.
Paully's5.0 listed the things I tend to stub my toe on. I'll reach the tipping point soon though.
Cheers.

 

[daba]

Ron touched on the search gotcha, that hit a nerve.

My biggest complaints about the 5000 software:

1. With 500 when you do a cross-reference you get a pop-up window where you can scroll up & down to browse by address. With 5000 it's not a pop-up window, you have to leave your ladder view to see the cross reference. Gone is the entire cross-reference - you get only the tag you clicked on. This because the tags are not address-based, of course.

2a. With 500 you could open a B3 file (any file) and click on Useage and see what addresses were used. This made it easy to "see" the used address structure as you programmed. It made program organization so easy & intuitive. The switch to tags without addresses throws this out the window.

2b. With a data file open I'd edit symbol names & descriptions as needed, then drag & drop the address into the rung I was creating. With 5000 you have to leave the ladder view to go to the tag editor. The tag editor has all the tags - the list can become extremely long.

I'm not a fan of 5000, in case you couldn't tell. I've done less than 10 systems from scratch, but more than five. I've followed behind other programmers on six more. I feel like the software handicaps me, it does not empower me. Just my opinion - everyone has one. Just like that other thing, LOL

Oh - you can use aliases to get the addresses back.

Replies to the points raised....

1. If you are doing a cross-reference, why are you interested in addresses other than the one you cross-referenced, they will be irrelevant. You do not "leave" your ladder view, it is still there - use the "Window" menu option to retrieve it - or Ctrl-TAB

2a. With a tag-based database you will create and organise your data the way you want it organised and is relevant to the application, not mould your application code around a pre-defined schema that the manufacturer imposes on you. You might, as an example, originally organise a B file to be used just for one-shots, but someone else might use an unused bit in that file for something else. Contrast that with a BOOL ARRAY tag called One_Shots, and it is immediately obvious to everyone what the bits in that tag are used for. In the tag data-base view there is an option to view "unused" tags, which you can delete (even online) if you need to or want to.

2b. In the ladder editor, just start typing a tagname for the instruction operand. If you have already defined/created the tag, it will automatically appear in the edit-line (look-ahead). By the time you are writing code, you should have your tags and tag-structures already created, by then you ought to know the tag-name of the data you are addressing. If not, and look-ahead hasn't found the tag you want, you have either mis-typed it, or it doesn't exist and you will have to create it. For this you can use a pop-up dialog (r-click, select "new", or use Ctrl-W to bring up the dialog. You do not have to leave the ladder editor.

Be wary of using aliases just because you can. I have seen spaghetti code that uses aliases like you wouldn't believe, and beleive me it is hard to follow. I personally restrict using them to give meaningful tag-names for I/O points, since these are the only "real" address-based tags that exist. I don't see a need to alias internal tags to other internal tags.

 

[Peter Nachtwey]

Difficult to implement

I've found that UDTs are great, but limited(no online changes),

You can't believe how difficult this would be to implement. It wouldn't be too bad if the UDT is used in one program or subroutine but if the UDT is used all over then effectively the whole program is changed. So yes this is a limitation but a reasonable one. I don't know an any other PLC that can do this. The only way I can think of to make online UDT changes is is to recompile the whole program and download it in a separate buffer and then change which program is running at the end or beginning of the scan. This means that there must be a memory big enough to hold two programs.

 

[Paul B]

I'll ponder on your points a while before replying. Thanks for noticing my comments, they were sincere.

This thread has been great for thought!

 

[Paul B]

Peter and I were online and posting at near the same time.

To his post: With Siemens you have UDT's and when you change them it affects the logic globally so same thing I think. With Siemens you can then right-click the blocks folder and Compile All and it will 'fix' everything offline. But then you need to reconcile online, and when it compiles what it is doing is re-generating the data blocks so they match the UDT so it means you will lose your online data if you download.

I think the UDT's in Siemens are awesome on the one hand, but for what I just said I am not ready to jump. I thought long and hard on it - days, but decided to retain the use of STRUCT inside DB's to accomplish much the same thing without fear of data loss in a running process.

 

[Peter Nachtwey]

Peter and I were online and posting at near the same time.

To his post: With Siemens you have UDT's and when you change them it affects the logic globally so same thing I think.

Yes.

[quote[
With Siemens you can then right-click the blocks folder and Compile All and it will 'fix' everything offline.
[/quote]
Yes, I don't think it is practical to do it otherwise. Both Rockwell and Siemens will be equal here.

But then you need to reconcile online, and when it compiles what it is doing is re-generating the data blocks so they match the UDT so it means you will lose your online data if you download.

Yes, that is very possible. All the memory locations within the PLC have changed.

I think the UDT's in Siemens are awesome on the one hand, but for what I just said I am not ready to jump.

I don't see the difference between the Rockwell and Siemens UDTs. They are both methods of defining data structures and if these data structures are used everywhere within the program the whole program will need to be downloaded. Siemens will only need to download those FCs, FBs and OBs that use the UDTs. If one if careful it may be possible to write some FC that access the data structure that access the data in the FC and only need to down load those FC. This is called data encapsulation. In Java and C++ these are called accessors. One calls a subroutine just to access data.
The unfortunate part is that the S7 is totally clueless about methods or data accessors so a separate FC must be written.