[RSLogix] How to tackle automating tagname creation and predefined code libraries

As a newcomer to RSLogix, I keep reading about (and am quite interested in) how companies automate tagname creation and have libraries of predefined code that makes code generation much more automated than manual, from-scratch programming. I have read posts where coders claims that up to 80% of their code is predefined, and only 20% maximum is manually coded. All I can say is, wow! Right now I'm very deep in my water treatment plant project that many of you might remember if you recognize my username. Every line of code has been manually programmed by me, but what I understand is that many companies automate a lot of this process since RSLogix files can be interpreted as plaintext and a lot of the drudgery I've manually taken care of can be automated and reduce workload and obviously this is quite interesting.

I realize that a lot of the specifics are going to be covered by NDAs and that specific info can't be shared, but I was wondering if any suggestions can be shared on how a company might approach this method, and just how much can truly be automated. From my perspective, trying to code with enough generic options, yet be solid code, would be very difficult just from the perspective of how many possibilities are out there for how to tackle a problem and the specific requirements of each individual project. Yet, I can see how once you overcome the "generic code can meet specific requirements" hurdle, how development can be sped up quite a lot.

So I guess my question is, how do I approach the challenge of creating pre-defined code libraries that are general enough to fit multiple applications, but are flexible enough to meet specific requirements without requiring total rewrite during every project? Secondarily, how does one approach that design concept, and determine how to automate the process? Is it custom Python code at every company? Are there commercial solutions available?

I'm not sure how they automate tag creation, but I know one thing you can do is create an Add-On Profile.

For instance, I have one for type "Cylinder" and it has everything on that type of Cylinder, for instance:

Cylinder Extended
Cylinder Retracted
Motion Fail (timer that keeps track of how long before the extended or retracted switch is made indicating the motion succeeded)
Cylinder Extract/Extend (for valve coil)

And the logic to move it, tell its state and keep coils from energizing at the same time.

Another example would be for pump logic. You could have an AOP for pump/pump logic. Basically you can find these online and modify them.

I would also look into EDS files as I know that they generate tags from plain text and you may be able to figure more out from there. Hopefully someone else chimes in that can help you more.

Let's talk about just ControlLogix/CompactLogix and it's Studio 5000 development.

Before you really get into it, it's important to understand that you can't automate much unless you have standard methods that you use on every application. If you don't standardize your methods there is nothing to automate. Having standard Add On Instructions, standard UDTs, standard ways of coding sequencing or IO mapping. You can easily standardize how devices work, such as a valve. Valves may have feedback, it might be beneficial to have on/off delays on them, certainly HOA functions, and alarms (valve output is on, but feedback is incorrect). By creating an AOI, or at mimnimum creating a UDT you know your valve tags might always look something like:

Valve01.auto
Valve01.hand
Valve01.off
Valve01.iFeedback_Open
Valve01.iFeedback_Closed
Valve01.onDelayTimeSP
Valve01.offDelayTimeSP
Valve01.oOutput
Valve01.alarmOpenFeedback
Valve01.alarmClosedFeedback

The advantage of AOIs/UDTs, well your tag creation logic only has to create the Valve01 tag, everything else is inherited so-long as you have the UDT for a valve defined.

Things like tag creation, IO mapping logic and instantiating AOIs are a decent start. These tasks are typically pretty tedious, and are essentially the same across projects big or small. Automating this can be a real time-saver.

Tag names are pretty easy since you can import/export them to/from a .csv file from Studio 5000. So the challenge is in creating the .csv file that you can import. If you create a handful of tags in Studio 5000, then export the .csv file you'll be able to see the format required. Just open it in Excel. You'll see there are a few lines for a header, then you'll start to see the tags defined w/comments and any additional information. An intermediate step here is to simply modify the .csv file directly in Excel and just follow the pattern until you get comfortable manually before you try to write VBA to do it for you.

Excel and VBA are tremendous tools for us. I've done some of this with Python as well, but I find Excel a bit nicer as it helps in managing the overall software development.

Say you have a bunch of IO that you need to create tags for. Create your IO list in Excel w/descriptions and use VBA to loop through the list generating each line of the .csv file. Once that is complete you should be able to import that into Studio 5000. This is extremely handy especially if you come across a project where descriptions and electrical prints don't match. I have used this method a number of times to get proper descriptions on the PLC tags w/o tediously entering them in manually.

You can do similar with logic by exporting a section of code into a .L5X file, essentially xml. Review the exported code and see what the structure of the xml file is. You would again work backwards from there to create the xml file using Excel/VBA.

Easier said than done, especially if you don't have any reference at all.

This also requires that you use Excel as a development tool, to aid in your software development. I generally have an excel file for each project which organizes information required for a project. Such as tracking valves, motors, analog inputs, PID loops, analog outputs, digital outputs..etc. It also tracks sequence steps, any tags required for setpoint/parameters. Gets into alarms as well. Each device has a tag, each device is linked to physical IO, once I centralize all of this information it's easy to use VBA to do some dirty work. Of course centralizing information helps you manage the project as well.

I have a few files I'll try and post. Just so you have a reference. I need dig them up do a quick review to make sure nothing I'm sharing is company specific. These files are ones which I created to help myself and never took off in the companies I was at, primarily because other engineers just didn't understand the value. Anyway give me a day or so.

The first file will be something I did more of an exercise, it creates a large logic string that can be pasted into RSLogix500 to generate alarm logic. The second file will be my 'IO Configurator', basically I can configure my hardware in Excel, then generate my IO list template. Once I fill in my IO template with the proper information I can then generate the .CSV file and import the required tags.

I am very interested in this approach as well. Thanks Paully.

See post below.

So here is my first really attempt at automating anything, never took off because we couldn't decide on how to standardize alarming. I did this probably 8 years ago now. In this excel file it will build alarm logic for the RSLogix500 platform.

If you just enter the 'example' addresses into each field and click the 'build' button it will generate a very large string. Click on the logic string (note if it disappears that is ok), then 'select->all', 'copy'. You can then paste this string into the ladder editor for an RSLogix500 program and watch the rungs build themselves.

The VBA is all on the 'build' button. Comments aren't very good and it got a bit complicated primarily decoding the addresses. If you don't know how to use VBA w/Excel, google it I'm not going to explain it.

This is offered as a reference only, it's been to long I have no idea how it works. If you have problems with it, well...figure it out.

Ok here is the IO configuration I mentioned.

On the "IOConfig" Sheet, this is where you configure hardware. Each line is a rack in a control panel, with configured device information. Items with blue headers are just reference information really, I do have a derived chassis/IO system so you'll see that in my IO address once it is generated. You can pretty much ignore it for the sake of the example.

I have the ability to use ASI, FlexIO or PointIO. I can configure each slot with the specific type of IO in the slot. I also can do some things like flowmeters and in this case there is a Powerflex 753 listed as well.

The "IOList" sheet is where my IO list template is created.

The "CSV" sheet is the output of information that is writting to the .CSV file. NOTE, you MUST create a "C:\Projects" folder, this is where the .CSV file will be saved. I don't have any directory checking in place.

TO USE:

1 - On the IOConfig Sheet, right click anywhere "IO Generation Functions" --> "Generate IO Template"

When complete you will be taken to the IOList sheet. You will see a pre-formatted output which provides a line for each IO device for a Tag and description. You will see panel and chassis information as well as the expected IO address. This is 'blank'. It is up to you to fill in a 'Tag' name (M101, V105...etc) as well as a descriptor. Note if the device has multiple addresses, such as with the PowerFlex drive, you will see multiple addresses w/the correct definition.

2 - On the IOList sheet, right click anywhere "IO Generation Functions" --> "Generate IO CSV". A .csv file will appear in your "C:\Projects" directory. It is also output onto the CSV sheet for reference. Note, devices such as a the PowerFlex drive on Ethernet have multiple functions. You will see that I append additional information to the description for these devices. You can then import this .CSV file into Studio 5000, assuming of course your hardware tree configuration and naming conventions align with the .CSV file.

Hey thanks everyone for chiming in. Sorry I'm so late getting back to this; I've been a very long last couple of weeks at the water plant, and am finally getting back to emails and forum posts.

To touch on a few things mentioned:

1. AOIs - I have created a few AOIs for things like Lead/Lag pump controls. Now that I'm more well versed in Logix, I'm seeing how a lot of what I am doing manually could be wrapped up into AOIs, like all the pump logic of calling to run, fail alarms...it would be quite nice to wrap that all up into AOIs for future use, one the code is tested and vetted. So much of my code is duplication for multiple loops, I can see the value in investing in that AOI library. I guess part of my hesitation at first was thinking "what if I create an AOI but it doesn't fit all circumstances, and if I have to make a change will it adversely affect other places I'm using it"...it can be overwhelming to try to keep track of all those details for a project with multiple loops and PLCs.

2. UDTs - UDTs have been a fantastic life saver for this project. I first started creating tags manually, and it was tedious as heck...once I learned about UDTs I never looked back. Only bummer is, if you want to do produce/consume tags you seem to need to have two UDTs; one for produce tags, one for consume tags.

3. Paully - let me fully review your posts before I respond. There's a lot of great info there and will take a bit for me to digest.

Where I used to work they developed a VBA application that would automate the nuts and bolts of a project, by inserting blocks of library text (the code) into an L5K file, substituting tag names from a project database created in Access, and later SQL.

Every Valve, Pump, Level Probe, Proximity Switch, Operator Button, etc., etc. had a standard piece of code in a library that was "included" for each plant item, substituting the plant item's name for each instance. This worked equally well for when each plant item was handled by a subroutine, and was easily upgraded to make full use of Add-On Instructions (V16 and later).

Project development time was reduced by about 80%

Having said that, you need to understand that such a venture took many man-hours in development, testing and implementation, and can only be justified if you are planning on rolling out lots of projects, all to the same spec.

daba said:

Having said that, you need to understand that such a venture took many man-hours in development, testing and implementation, and can only be justified if you are planning on rolling out lots of projects, all to the same spec.

Click to expand...

Even then, it probably ends up like this:
http://www.plctalk.net//www.pinterest.com/pin/create/extension/

Paully's5.0 said:

Even then, it probably ends up like this:

Click to expand...

Yes, that's about it... but at least the "Ongoing Development" in this instance was someone else's workload. The people who developed the code generation applications were mostly SCADA development people, mostly fresh from Uni, mostly clued-up to the eyeballs in "proper" computing.

How ironic that it was them that said the PLC development side of a project was the critical path, and needed to be "streamlined".

Us "PLC" guys got our projects out much faster, they got the extra workload to develop the solution, and the task of maintaining/updating it forever.....

Paully's5.0 said:

Even then, it probably ends up like this:

Click to expand...

Now I want to know what the mouse-over text for that one was!

defcon.klaxon said:

..........
2. UDTs - UDTs have been a fantastic life saver for this project. I first started creating tags manually, and it was tedious as heck...once I learned about UDTs I never looked back. Only bummer is, if you want to do produce/consume tags you seem to need to have two UDTs; one for produce tags, one for consume tags.

Click to expand...

Not sure I understand the problem here....

A "UDT" is a User-Defined Data-Type - Once the UDT structure is defined you then create tags of that type. The tags you create can then be configured as produced or consumed, no problem. Of course, the UDT needs to declared in both projects - producer and consumer.

In fact, it is good practice to create your UDT in one project (eg. the Consumer), then copy/paste the UDT into the other project (eg. the Producer) so you guarantee the identical structure. Creating your Produced and Consumed tags from the same UDT you will have no problems.

daba said:

Us "PLC" guys got our projects out much faster, they got the extra workload to develop the solution, and the task of maintaining/updating it forever.....

Click to expand...

I've had to maintain the system we have used, it was a chore. I think there is a line in the sand that has to be drawn as to how far to take it. Some of my colleagues wanted to do similar to your company and have 80% of code generated. I was against it primarily because it ould prevent anyone from learning the actual logic in the PLC. What happens during commissioning if you have to make changes!

I think it's great for the tedious, repetitive tasks. The time saved, and CONSISTENCY achieved are worth the development labor.

Jeev said:

Now I want to know what the mouse-over text for that one was!

Click to expand...

"'Automating' comes from the roots 'auto-' meaning 'self-' and 'mating', meaning 'screwing'."

This is another one that I think is quite applicable to this discussion...



"Don't forget the time you spend finding the chart to look up what you save. And the time reading this reminder about the time spent. And the time trying to figure out if either of those actually make sense. Remember, every second counts toward your life total, including those right now."