Successful Program Design Tips

[Jason366433]

I’m currently starting a brand new design with a compactLogix controller and a panel view 700. I’ve completed similar projects from start to finish in the past but have never really set myself up with a standard or steps to take while designing a system.

Just curious to know if anyone has some good tips for setting a foundation or sequence to take on designing similar projects.

I feel each project I do is kind of random and I just start with bits a pieces of the project and build off of those. But, I feel it would be nice to have some kind of sequence to follow through with to keep myself on track.

Kind of a large question I know but, just figured I would see how other programmers attack their projects.

 

[LegacyLee]

Do it in a spreadsheet first before applying random logic steps and just guessing if it'll work. Have a very well defined P&ID and name your elements after those elements. Don't even start programming w/o a finished P&ID. Don't dare name an element w/o a P&ID reference. Those are the things that keep me sane. No way should a variable ever have a generic reference such as 'pump', 'valve'...just P&ID names like XV_9876 or YS_1234...never something like Pump_abcd. IMHO.

 

[parky]

I agree with the last post, first thing to do is from the drawings give all your I/O a symbol (If possible a description if it can have this field) that makes sense perhaps some form of text that is on the PI&D or electrical drawings)
Try to create a system with perhaps your own functions like motor control that have been tested & you know it works do this for things like this & valves etc.
If the process relies on things like steps (sequences) again have some sort of common re-usable control FB i.e. call it something like "Process Engine" i.e. does things that would be common to any process for example, A start, hold, stop, Alarm hold I do suggest where possible rather than use individual bits for controlling a sequence use a Sequence variable, for example: "Process Sequence" this contains a number say 0-1000, use increments of say 10 to allow for extra steps should you need to insert some.
Example:
0 = IDLE
!0 = Starting up
20 = Tare Vessel
30 = xxx & so on
Perhaps have a Main sequence var & a process sequence variable.
The good points about this is that it is possible to jump back & forth should it be required rather than having to set or reset control bits.
If an HMI is present, most can display messages based on values in a variable i..e.
IDLE
HOLDING
HELD
RESUMING
TARING VESSEL
ADDING PRODUCT X
MIXING etc.
This seems to be the best approach that i have found over many years of programming, however, many companies may have their own standards you will have to follow, indeed it is often a good idea to use some of their ideas in your own standards, I'm not saying poach but use the concepts if it suits you.
To re-iterate,
Before you do any coding create your I/O symbols, have spreadsheets (or printouts of the variables) where at some point you pen them in so you can keep track, create even simple flow charts etc.
This way your documentation can be incorporated in the manuals you provide.
It is all about housekeeping & ensuring any modifications are documented it makes it easier for you & your customer.

 

[JeffKiper]

I try to start out my young guys with the basics and drill in the fact that all systems have 3 core items. Input , Logic, Output.

I get them to write down what the steps are. Easy high level first, then refine the steps, while refining the steps they naturally add inputs and outputs as details come along.

Then they rewrite it again and again. Repetitions each time I prefer them to have a new paper so we can look at the iterations they have went through.

After a few times of this they start listing inputs and output and then logic without the all the other steps.

The input and outputs are requirements for the machine to work you have to have them. The logic is what you change you can control that so make it a flexible roadmap. Sometimes we hit road construction and have to change the road map. You ultimately have to hit the same destination. Your map and mine may be different, as long as we get to the destination....... you get the idea.

Im akso talking about 17 year old kids.

 

[JeffKiper]

Parky and LegacyLee are both on the same track as me. I AASSuME LegacyLee is in the process world where P&ID rule. I'm in the machine world where a P&ID never exist. That's one of the things I love about our worlds we are all doing controls and so different at the same time.

My customer base is mainly small manufacturing machines. A lot of sequences we break them down into small steps. We actually use a BIT of a DINT as a step indicatior. Step 0, step 1, step 2, 3, etc. One the first rung of the lader you have 0-31 bits listed in that rung. You cannlook quickly and see what step the system is in and jump straight to that step the next transition if waiting for X event or Y time etc.etc...

What we found was a lot of maintenance guys (or maybe just me) like small easy steps that keep the machines organized.

I was on a job where the original programmer used steps like Parky recommended. There where 305 steps to the machine. They where not in numerical order where over the years they added extra steps and just put them at the bottom of the logic. It was less than fun troubleshooting because when you looked for var STEP_NUMB you got 305 MOV instructions. I was on step 105 and needed 106. They just skipped 106 and went to 107 for example.

It became a total rewrite. I think it was 6 sequences total after we broke them down into smaller functions.
Example SEQ 1 runs till complete and triggers 2 to run, complete then 3 etc.
You can have them run independently until each seq is complete then batch then complete and advanced. You would be amazed and what it can do to a cycle time when you run each system independently or in unison.

Ive found several times where running in unison makes the machine noise rhythmic and operators can twll what is going on by the sound. I promise you they get in tune with the machines. When they operate as individual steps and are event based your rhythm changes. Example the sensor sees this piece of light color wood and has a little longer reaction time vs the darker color. The ovehead crane is blocking the light so the visin system doesnt see the part.....

Just a littlw back story what we break them down into small steps and quicker diagnostic troubleshooting.

Put all the steps on the HMI. I usually have up to 64 funcions step complete and steps waiting are how you get up to 64 our of those 32 BITS. I dont think Ive ever use that many but thwy are there if I need to.

Step 8 complete and steps 9 not = " Waiting for X or Y"
I prefer these STRINGS yo be in the PLC so if your changing ant logic you can change the description displayed on the HMI right then. Why wait until later and try to remember exactly what was done. Its another software package and another "Hang on so I can update the HMI for a minute or 2".

We have all seen where someone added an Alarm to the PLC and it never got added to the HMI.

STRINGS take up memory, but lack of diagnostics and incresed downtime take up money and profits.

 

[parky]

No idea what sort of industry you mainly work in but in my case (before I retired) was any that was going, it was heavily into batch processes but sometimes this would fit nicely into other machine controls.
One thing I tend to use especially in process batching that require recipes is a structure like this:
The process is made up of tasks i.e. a batching process that adds/blends/heats & cools product.
The recipe has two main structures, a common for things to do with perhaps common settings, and processes where the recipe has say 16 stages consisting of the following, oil addition, water addition, slurry addition, heating/mixing, manual addition.
Each recipe stage is identical, i.e. it contains all the things it needs like weights/heating times/temperatures etc.
Then you have what we called units these consist of the different processes
We tended to use a control engine that took care of the starting/stopping/abort or hold statuses, then another engine that did the batching process.
When a recipe is loaded & the system started, it took the first stage from the recipe, checked what type of stage (process) was then called the code that controlled that, at the completion the next recipe stage was loaded, this again checked the type of process & loaded it.
So we had two processes, the main engine this was basically simple
the seq. word was as follows
0 = IDLE
10 = Startup
20 = Running
30 = Holding
40 = Held
50 = Held on exception
60 = resuming
So the operator presses the start button it puts 10 into the seq var.
this calls the startup routine when complete it steps on to 20 when at 20 it starts the process seq. this consists of the following steps
0 = IDLE
10 = Startup
When on this step it loads the first stage of the recipe checks the type of addition & forces the process seq. var to the range for the type of addition.
for example:
10-99 is water addition (note we tend to jump in steps of 10 to allow for extra ones in the future)
100 -199 Slurry
200-299 Oil
300 -399 manual addition
400 -499 heating/mixing
& so on.
it means we only had one bit of code for example manual addition as there could be perhaps 5 different manual additions we only needed one bit of code then contained the weights limits etc.
So for example, The recipe stage is checked for type of addition, if oil it forced the process sequence to 200, this enables the oil sequence & steps through, when complete it stepped on & loaded the next stage, if this happened to be manual addition then it forced the seq var to 300 & so on
As we could have 5 or 6 manual additions in a process it only used one bit of code where the current recipe stage was put into it's own stage variables.
One other thing we had in the recipe was that all recipes were based on 100kg size, when the recipe was loaded, the operator put in the batch size, the system took the weights for a 100kg batch a little maths & worked out the actual amounts to add.

 

[JeffKiper]

No idea what sort of industry you mainly work in but in my case (before I retired) was any that was going, it was heavily into batch processes but sometimes this would fit nicely into other machine controls.

Again, this is what I like about what we do. I've only ever serviced 1 or 2 batch operations. So, this style is outside of my comfort zone.

 

[parky]

Yes that one I did in 2004, the last one was in 2016 but it was a lot smaller, the one in 2004 was a very large system 22 tanks, each recipe contained 2560 words all stored on an SQL DB, however, these were not all values as many were the ingredients description. as you could have 6 types of product per addition & upto 16 additions/processes it took quite a bit of memory. as the vessels were different sizes hence the need for a recipe based on 100kg, the largest was 1500kg so if the vessel batch was selected as 1000kg & the addition based on 100kg was 10kg then simple maths gave a required weight of 100kg of that product. it meant that on any vessel a batch size could be from 100kg minimum to 1500kg but obviously if a 500kg tank was selected the max batch size was limited to 500kg.