Improve programming and control

Does anyone know a way to improve my programming and problem solving skills? Most courses just cover functions and UI from the programming softwares, but knowing platforms didn't mean you are a better porgrammer, I have some experience programming, about 3 years and now I feel I'm stuck even I already worked with several machines in my career.

Have you found any interesting problems to solve along the way?

You might visit an equipment manufacturer's site and see what stuff they build. Try to design an application that runs a piece of equipment and simulate it. Repeat that with other equipment. Can these programs co-exist as a process? Think about code modularity, dependencies, and ownership - if you add or remove existing equipment, does the other equipment's programming fail? How can you solve this? Can you make a state machine for combinations equipment? Even further - can you generalize a state machine across different processes? Can batch and continuous processes exist and carry out their work under the same framework?

Anyone can XIC a pushbutton or OTE a motor starter. What stuff necessarily happens between an input and an action? Permissive, interlock, state checks? Can logic be supplied that manages these in a general, scalable way?

What can be done in programming to align the functionality of several different VFD models across manufacturers? Parts shortages happen. Minus comms/protocol differences, does your programming permit design replacements with a minimal amount of IO rework?

Now circle back to the equipment you programmed and see what can be improved with everything up to this point.

Frequently the problem is not perfectly knowing the operation of the machine to be automated and this means knowing each of the position detectors, sensors, actuators, motors, drivers, etc. that it has and even detect if any device is missing.

If it is a new installation, the programmer should be a member of the design team along with mechanical designers, electricians, etc. In my experience the PLC programmers were also designers of the electrical part

If it is to modify something, then the first thing is to study the machine in detail and to decide how to modify it.

Getting in front of the screen to program should be a later step

Stretch projects.

you can read til' you're blue in the face, but won't really make progress unless you push yourself.

If you do it for work, take on projects that seem just a little bit beyond what you're comfortable with, learn the new topics and implement.

Every time you do this you end up bringing new knowledge and skills to the next one, if you never get out of a comfort zone, you never get better.



If you have no projects lined up, then take a look at your current knowledgebase and skillset and fill the gaps one at a time, find cheap ways to test your programming and machine builds.

Nobody really learns much without doing the work IMHO.

When I was first introduced to programming the teacher made it a point to explain that no one has ever learned to program by reading books or solutions. You have to do it yourself.

Now, I do understand where you're at since I too have zero imagination for these things, but do have some examples you can take to get started.

Here's some ideas and tips for you to program:

- Set of traffic lights. However, program them so that the time a certain direction is green can be configured and modified. Don't forget to check for feedback on the lights to ensure that they're working and if not raise the relevant faults.

- Car wash system. Don't waste a lot of time with motion control as it's not easily simulated, but program a car wash with the ability to choose certain options as well.

- Industrial Jam making system. This is a big one and you need to take it in a structured approach. So start off creating logic to control and alarm process devices like valves motors, VFDs, proportional valves, etc... you can also use a platform like PlantPAX if it's useful for your career.
In this system you have say... 3 jams that can be made and you have to dose the ingredients into the mixer, so think water, sugar, fruit (this will be a solid so you'll need a hopper and screw conveyor), additives, along with an agitator and heating controls. (You can look up a jam recipe online and replicate it). As I mentioned above, do this by blocks. Start with process devices, then create a sequence/routine/function to dose each ingredient (bonus points if the function is the same for all dosing) and finally create your recipe sequence. In addition, create simulation logic to run alongside your program (this is easier with PlantPAX) so that you can see your logic running without you having to be simulating inputs.

The other aspect of this is to know safeguards to be put in place and alarms that are useful, common, but that would be a longwinded post that I don't have time for now, but you should still think and ask what if this or that goes wrong and how to get around it. I'm sure many of us here would be happy to give you ideas ONCE you ran these scenarios yourself and came up with something.

I agree with Cardosoea:
Especially the process i.e. batching.
This is a good one as it is easy to simulate for example after you have created standard functions like valve control & status, motors etc. take an example of one batching tank with loadcells for weight, perhaps add some things like flow meters for things like water oil or what ever (probably not need them as can be done as weight but a good exercise).
Think about some sort of recipe handling try to make for example a standardised recipe i.e. a header with standard things then each recipe stage identical regardless what is being added, so for example:
Stirrer speeds, weight (regardless of if it is done by flow or weight) heating temperature cook time etc.
Easy to simulate ignore real I/O but allow for mapping real I/O into internal bits in a seperate program file so that it can be disabled (not called) when in simulation) i.e. use the mapped bits, write some code to simulate the valves opening & closing same with motors, add some simualtion code to simulate the weight going up & down & temperatures rising/falling very simple for example use a timer so when say the water feed valve opens start incrementing the weight (or flow meter count) to the vessel weight.
I did a 21 tank batching /heating & cooling system where we completely simulated it, when we commissioned it appart from simple in-flight factors & a few slight mods we did not need to make any major changes it worked a dream.

parky said:

perhaps add some things like flow meters for things like water oil or what ever (probably not need them as can be done as weight but a good exercise).

Click to expand...

I was actually assuming both since they operate slightly different, one will be loss in weight and the other a totaliser.

Not really, but I did say both, just to get used to using various types of addition, it is not actually loss in weight as if using the vessel loadcells then it is just adding, loss in weight is if the product you are feeding into the batching tank is on weighcells on many systems I have done flowmeters are also incorporated so that more than one liquid product can be added at the same time, however, if not then we often use the flowmeter as a comparison on the added ingredient i.e. a double check. We often had simultaneous additions on liquids but it would depend on the process.
There was one I did in the late 90's that had loadcells on the vessels, flowmeters on the liquids & on a sugar addition loss in weight so in effect it had 3 types of addition that could be at the same time, it also had direct steam injection (vapour injectors), although the steam was generated with a known range of what I call wetness, the amount of water added to the batch was less than the required, at the end of the batch before final cook stage the ingredient addition weights were added, a check on the actual final weight & to allow for the "wetter Steam" the batch weight was then topped up with a calculated final water addition.

Actually thinking a bit about it, I do loss in weight for flow control dosing, but not to dose. I did loss in level before though. LOL



The double check of flowmeter was one of the points I mentioned before about understanding what could go wrong.