Advanced level programming examples

[L D[AR2P#0.0]]

Yes I understand, do you mind sharing a few shots of your code just so I can compare with my own? I would like to compare just to make sure I am programming efficiently and ‘properly’ so to speak.

You go first

 

[daba]

[QUOTE='L D[AR2,P#0.0] The pumps must be selected to run to even out the run time of the pumps.[/QUOTE]

Hmmmm, not sure the maintenance guys are gonna be happy that all of the pumps require new shaft seals at the same time, according to manufacturer schedules, on which they base their guarantees and liabilities !!

Introduce an initial offset so that critical maintenance doesn't occur simultaneously on all the pumps because the software, the "brain" says so.

Balancing the run-hours on anything that needs reported maintenance is a bad idea imho.

Produce your own algorithm, and ease the load on your maintenance team.

 

[kalabdel]

Hmmmm, not sure the maintenance guys are gonna be happy that all of the pumps require new shaft seals at the same time, according to manufacturer schedules, on which they base their guarantees and liabilities !!

Introduce an initial offset so that critical maintenance doesn't occur simultaneously on all the pumps because the software, the "brain" says so.

Balancing the run-hours on anything that needs reported maintenance is a bad idea imho.

Produce your own algorithm, and ease the load on your maintenance team.

I'm not following. The logic is designed to even out working hours which also implies tracking working hours; he could do with that anything he wants. Why initial offset when I can offset them anytime I want like 10 percent before schedule time or anything I can think of.
May be they have seasonal shut down and would rather do them all at the same time.
The idea is to balance the working hour, have accurate data and advanced warning, and let maintenance do what they want with the information.

 

[parky]

I believe the OP should consider two ways of developing his skills, think about sequences first, perhaps using bits to do a sequence like a pick & place nice & simple only real thing to think about are the conditions to go from one state to the next bearing in mind some states will exist twice many people I taught always came unstuck on the return where the same conditions exist.
Also try doing it using a variable i.e. step number.
Other more advanced ideas would be a batching process involving analogues (you don't need real analogues just internal variables so you can manipulate)

 

[Bcurry135]

[/QUOTE]

I believe the OP should consider two ways of developing his skills, think about sequences first, perhaps using bits to do a sequence like a pick & place nice & simple only real thing to think about are the conditions to go from one state to the next bearing in mind some states will exist twice many people I taught always came unstuck on the return where the same conditions exist.
Also try doing it using a variable i.e. step number.
Other more advanced ideas would be a batching process involving analogues (you don't need real analogues just internal variables so you can manipulate)

Thanks for that I have done a couple of projects using sequences and step numbers and I find that quite simple too, aswell as practicing a batch mixer. What would you recommend would be good practice next?

 

[Bcurry135]

You go first

I will get it sent across to you later today

 

[parky]

Perhaps tracking products down a production line using FIFO's etc. i.e. reject stations, I would also look into communications with other equipment & servo's, however, this becomes problematic unless you have the hardware.
I have always found it better to map real I/O into and from internal bits but not call the blocks so you use the mapped bits in the program, create logic in the PLC in other blocks to manipulate what would be the real I/O, even if you are using a PLC simulator I find them quite cumbersome to set simulations so I prefer doing it in the PLC and then delete the blocks when tested, some simulators require more effort to set the simulation up than doing it in PLC code.
Another great thing you can do is create your own standard function blocks (AOI's) and keep them in a library, these can be used in future projects.
For example, valve or motor control functions containing alarms, and ways of driving the valve/motor.
An example for in/outs are:
Valve position limits
Outputs
Single/dual acting (just use true or false bits to select the type)
Outputs.
alarm bits
alarm times.
You could create a standard function that incorporates single/dual acting, with limits or without or even just one limit, variables for time functions etc.
Once built & tested these functions make programming a new system easier.

 

[JeremyM]

Yes I understand, do you mind sharing a few shots of your code just so I can compare with my own? I would like to compare just to make sure I am programming efficiently and ‘properly’ so to speak.

Don't worry about efficiency when you're learning or initially developing a solution. You'll save time by doing that after you've solved the problem.

 

[drbitboy]

I would also recommend committing design patterns to memory, see here.


Especially the first few of those patterns are used over and over in one form or another, i.e. the trigger is not always a contact, it could be a compare instruction.


E.g. a timer that, once it starts timing (triggered), uses its own .Enable bit as a seal-in to keep itself enabled and timing until it is done, with perhaps the NC/XIC as the equivalent of the [Stop] contact on the Start/Stop Pattern, to reset the timer.

 

[Bcurry135]

Perhaps tracking products down a production line using FIFO's etc. i.e. reject stations, I would also look into communications with other equipment & servo's, however, this becomes problematic unless you have the hardware.
I have always found it better to map real I/O into and from internal bits but not call the blocks so you use the mapped bits in the program, create logic in the PLC in other blocks to manipulate what would be the real I/O, even if you are using a PLC simulator I find them quite cumbersome to set simulations so I prefer doing it in the PLC and then delete the blocks when tested, some simulators require more effort to set the simulation up than doing it in PLC code.
Another great thing you can do is create your own standard function blocks (AOI's) and keep them in a library, these can be used in future projects.
For example, valve or motor control functions containing alarms, and ways of driving the valve/motor.
An example for in/outs are:
Valve position limits
Outputs
Single/dual acting (just use true or false bits to select the type)
Outputs.
alarm bits
alarm times.
You could create a standard function that incorporates single/dual acting, with limits or without or even just one limit, variables for time functions etc.
Once built & tested these functions make programming a new system easier.

Thanks for the detailed response I’m not sure I fully understand what you mean by mapping the real Io into and from internal bits but not calling the blocks?

 

[parky]

It's a throwback from before there was PLC simulators, sometimes only the PLC rack & processor was available and you could not write to inputs, there were applications that could simulate via communication with the processor like PICS and an ex siemens engineer produced an interface card that sat on an S5 PLC rack to simulate the I/O an application on a PC could then be used to do the simulation i.e. set inputs on conditions to provide feedback as if the real I/O was in place on the machine. it had plenty of simple settings like using an output onto a time delay to switch an input on (simulating say a valve or cylinder closing/opening as if in the real world), however, many PLC's if you try to put in a program and address real I/O it will go into error and inputs are generally not write enabled only outputs. Software simulators can get round this but many are difficult to set up these operations i.e. using an output to turn on an input or increment a variable.
As many PLC's now use structured programming where you can call program blocks in a task it is easy to enable or disable them. so whether you use a simulator or a real PLC by mapping the inputs to internal bits i.e. I:1/0 to an internal memory like B:3/0 and mapping internal bits to the real output images you can use these bits in the main logic then call the mapping blocks that just map these bits into or out to the real I/O, this means you do not need the real I/O just the processor or rack (or a simulator), during testing you disable the call to the I/O mapping block(S) and write extra blocks to use these mapped bits to do things like timing and increment/decrement variables to simulate an analogue value, most simulators are restricted to digital I/O so analogue simulation is difficult.
so you create a map block of code:
I:1/0 B:3/0
---| |----------( )
do this for all the inputs

B:3/100 O:2/0
---| |---------( )
Do this for all outputs

Then use the B bits in the program you are creating.
Create another block called simulation
Here you write code to simulate the real i/O for example
B:3/100 T4:x, 0.1, 10
--| |-----------| |

T4:x.DN B:3/0
---| |------------( )

This does two things allows you to test without using real I/O in a simple manner, hones your programming skills by creating the simulation in the PLC code and gets round certain problems where some PLC's need the real I/O or poor simulator configuration.

 

[Bcurry135]

Yes I understand now what you mean, thanks very much for all your input it has been much appreciated!

I would love to get my hands on a project involving servos but I haven’t come across anything yet, is there any software available to possibly do a simulation of servo motor control from a plc?

 

[Bcurry135]

I would also recommend committing design patterns to memory, see here.


Especially the first few of those patterns are used over and over in one form or another, i.e. the trigger is not always a contact, it could be a compare instruction.


E.g. a timer that, once it starts timing (triggered), uses its own .Enable bit as a seal-in to keep itself enabled and timing until it is done, with perhaps the NC/XIC as the equivalent of the [Stop] contact on the Start/Stop Pattern, to reset the timer.

Thanks for that link, from that website I see that I am already familiar with the patterns described. I’m very grateful for all of your responses!

 

[nyanpasu]

I'd start with proper error handling. For instance, it's one thing to code a simple state machine, but it's another thing to figure out every single way anything important can go wrong during a sequence or a step and implement the correct action, be it a simple alarm to an HMI or a more complicated auto-diagnosis or catch and retry system.

Some exercises also seem simple prima facie but it's the corollaries that make them more complicated. Priority systems can either be pretty simple or pretty complicated. It depends on the number of conditions/variables to track, the weight assigned to any one variable (whether they vary or not depending on environment), when priority must shift, and any number of random, exceedingly rare edge cases production absolutely wants the system to automatically handle. Without spaghetti code, of course.

Batch control is another example. If you're just calling ingredients by specified volume to one mixing tank from two or three tanks containing dedicated ingredients then yes, that is pretty simple. Add more tanks, more parameters, more ingredients, more automation (calculations by parameters, auto-corrective actions, buffered transfers, etc) then it gets more funky. If you're going to practice batch control then why not use the time to familiarize yourself with best practices via ISA 88 too?

Finally there's also the whole area of analog process control that is a world unto itself and where the hardest thing is perhaps not simply a question of functions and function blocks but rather implementation.

Perhaps it could be fun to combine that with the above. How about some kind of mixing tank? From an "empty" state, have two or more product lines called in a mixing tank with parametrable ratios for each product. The mixing tank has an agitator, perhaps a jacket. Product must be mixed and heated for some short time (few minutes perhaps) then sent onwards to processing, all in real time (that is while the tank outlet is open). To make it more fun, maybe there are a few processors on the line, and any number can be on or off, so the outlet flow can vary. Can you detect (substantial) leaks in the tank, or blocked processing lines? How would you handle these issues?

 

[mikeexplorer]

I am one who is learning programming by controlling a model railroad layout. I documented my progress here:

https://www.nepaview.com/model-train-plc-project.html