Can an automation engineer make an automation control scheme, and how to write and implement a logic program?
Really good,our team could provide the process flow(crushing/griding), equipment list, equipment layout and process control requirements.Can you provide the plant automation scheme(including selection of automatic instruments and meters,needs of the materials,hardware&software-you may find other engineer to complete the task) and quotation for this automation project.That's generally the idea .....
However, the origin of automation as a rule comes from either client or consultant, or even a process engineer for a specific process.
There is also working for a panel builder / system builder as we used to call them. So instead of having a MCC {motor control centre} with just push button controls, we build MMC's with a PLC to give us automatic control over motor drives.
As for software and logic program, is it not a good idea to write down how this particular machine is going to work by way of Functional Description. You have mentioned what appears to be a rock crushing plant. Maybe the belt conveyors would start up in sequence with the crusher starting first.
The days of writing a logic program from a blank sheet of paper are long over, but the 'genius' part of a Control Engineer is to code a logic program into something workable. I've really only written a start sequence algorithm once. Another project with belt conveyors would have almost the same sequence with slight differences.
The greatest satisfaction of course is commisioning a machine and seeing it perform exactly as you have described in the Functional Description.
Thanks for reply me.I am agreed with your points,and first we will try to develop a small system (Vibration Monitoring System - VMS) to our client to show the power of automation for mineral process.It is a Feature enhancement project,could you join the project to finish the task?What I normally do, is first make a good functional specification (what must the machine do and how) together with a process technologist that knows the product well and knows what has to be done with it and when.
This must be in normal plain language, without automation-technical stuff that the process technologist doesn't understand.
Only if you both agree on this specification, you take the next step and make with the functional specification (this is automation technical and the process technologist doesn't understand this).
Here are the state machines/SFCs and control strategies.
A good solution for this is the ISA-S88 standard for process control.
https://en.wikipedia.org/wiki/ISA-88
Thanks for your reply.Dear Kevin,
This is a technical specification. That is the main mistake many people make.
The customer is often not technical, for him you must write a functional specification in plain language that (almost) everybody without technical knowledge can understand.
When both parties agree on the functional specification (after changing after discussions) you translate the functional specification into the technical specification (what you sent in your previous message).
This is how things go when the customer is not technically skilled.
But maybe he is, and can read your specification. If he/she agrees on that you can start implementing the project if all is clear to both parties and agreed upon.
by Seth Price
by Bob Odhiambo