Studio 5000 set the order of routines in organizer

Is there a way to change the order of the routines in the organizer? It is defaulting to alphabetical order, but I would like to change the order to better suite my feeble brain (I know it has nothing to do with the execution of code). If I can't figure anything else out, I will prepend a number to the names to force the order.

Just put preceding letters to force your desired organization.

A_Routine1
B_Routine2

I always name them:

R001_real_name
R002_routine_to_be_second
R003_third_one
R004.......

and at the end

R999_Faults

We typically use "_01_Name", "_02_Name2" nomenclature. You need the "_" as the name can't start with a number for some reason.

Thanks all.

g.mccormick said:

Thanks all.

Click to expand...

The other thing I didn't mention is naming called sub-subroutines

R601_name1
R602_ .....

So they aren't mixed in the main section.

One thing to keep in mind, they scan in the order which you call the routines, not by the order that they are organized in the project tree. If you already had your program calling the routines based on the order in the tree, then you rename them, putting them in a different order, the execution order doesn't change. Hopefully that made sense....

vlad romanov said:

we typically use "_01_name", "_02_name2" nomenclature. You need the "_" as the name can't start with a number for some reason.

Click to expand...

+1

I name all my continuously executed routines R01...R99, so that I can name them in the order I intend to call them.

For subroutines that are not continuously executed, I number them SBR01..SBR99. Luckily S comes after R in the alphabet, so they all sit just below my continuously executed routines, and the specific order is largely unimportant as they're not being continuously executed.

ASF said:

I name all my continuously executed routines R01...R99, so that I can name them in the order I intend to call them.

Click to expand...

But what is next after R99? Been there before

I_Automation said:

But what is next after R99? Been there before

Click to expand...

Since the only limit to the number of routines is determined by available memory (or 65,536, if I remember correctly), then you could easily adopt a numbering system with as many leading zeroes that fit the bill... e.g.

R001_{name}
R002_{name}
..
R099_{name}
R100_{name}

The alphanumeric sorting on the organiser tree works correctly then.

I_Automation said:

But what is next after R99? Been there before

Click to expand...

daba said:

Since the only limit to the number of routines is determined by available memory (or 65,536, if I remember correctly), then you could easily adopt a numbering system with as many leading zeroes that fit the bill... e.g.

R001_{name}
R002_{name}
..
R099_{name}
R100_{name}

Click to expand...

The way my programs are structured, I very rarely have a need to go past R99. Most of the time I prefer to separate different sections of plant into different programs, with each section/program having a common routine structure - e.g. R01-R09 is housekeeping and signal processing for sensors and analogs, R10-11-12 is sub-section 1 motors-pneumatics-other, R20-21-22 is sub-section 2 motors-pneumatics-other, R80-R89 is alarms/warnings/annunciation, and so on. 100 routines for one section of plant has always been more than enough.

But on the odd occasion this structure doesn't suit, yes, more leading zeroes is the answer.

ASF said:

The way my programs are structured, I very rarely have a need to go past R99. Most of the time I prefer to separate different sections of plant into different programs, with each section/program having a common routine structure - e.g. R01-R09 is housekeeping and signal processing for sensors and analogs, R10-11-12 is sub-section 1 motors-pneumatics-other, R20-21-22 is sub-section 2 motors-pneumatics-other, R80-R89 is alarms/warnings/annunciation, and so on. 100 routines for one section of plant has always been more than enough.

But on the odd occasion this structure doesn't suit, yes, more leading zeroes is the answer.

Click to expand...

It sounds like you have the bases covered there ASF !

This post is for the "not so experienced" programmers

Whatever your needs are, structuring your code in a logical and defined way is not for you (although it helps enormously), it is for the poor guy who has to fix a fault at 3:00 am on a cold winter's morning, with nothing more than a cable drum to put his laptop on, a beer crate to sit on, and trying to type while wearing gloves ! Been there, done that, etc.

Yesterday he worked on the chiller plant, the code written 5 years ago to the company standard, and managed to find & fix the problem in 15 minutes. In three years time there will be an issue on the newly installed Widget Palletiser that he has to address. But because of company "standards", he should already know how the code is structured, and if he knows the structure, he immediately gets a good handle on how it works.

It should not matter that the new application was written in version 93, and the chiller plant written in version 14, the code, as written should be familiar enough to ease his many years away transition.

I'm a firm believer in the old saying "If it ain't broke, don't fix it !". Change should only be attempted out of necessity.

Sometimes I think that the PLC developers are making "improvements" just so they keep a job!

daba said:

Whatever your needs are, structuring your code in a logical and defined way is not for you (although it helps enormously), it is for the poor guy who has to fix a fault at 3:00 am on a cold winter's morning, with nothing more than a cable drum to put his laptop on, a beer crate to sit on, and trying to type while wearing gloves ! Been there, done that, etc.

Yesterday he worked on the chiller plant, the code written 5 years ago to the company standard, and managed to find & fix the problem in 15 minutes. In three years time there will be an issue on the newly installed Widget Palletiser that he has to address. But because of company "standards", he should already know how the code is structured, and if he knows the structure, he immediately gets a good handle on how it works.

Click to expand...

Right on. And as well as the advantages for maintenance, it has a lot of advantages for me as an OEM/designer/contractor as well. I've trained up two other programmers in the company I work for, to use the same structure that I use, and as a result any one of us can go and commission a program that any other one of us has written. Five years after Tom puts a system in, I can come along and add an extra widget or two, and if Tom comes looking next week, he'll know exactly where to find the code I added. And it'll look largely the same way it would have looked had he done it himself. Makes my job easy and my colleagues jobs easy.

dmroeder said:

One thing to keep in mind, they scan in the order which you call the routines, not by the order that they are organized in the project tree. If you already had your program calling the routines based on the order in the tree, then you rename them, putting them in a different order, the execution order doesn't change. Hopefully that made sense....

Click to expand...

Yep. This is purely for sanity sakes.