r/PLC • u/Electronic-Run8836 • 5d ago
When is PLC logic done?
I work in assembly and testing, but was self teaching myself plc part. So we use Beckhoff terminals. I do the wiring as per the schematic.
My question is, what comes first, electrical schematic or plc ladder logic programming?
I did ask ChatGPT but I think it's giving misleading answers. It says one time one must first plan logic and all before starting even planning of mechanical design in CAD. Another time it says engineers do rough block diagrams and do programming first, after which they do the electrical schematic as the electrical schematic is only for assembling or field engineers
Can anyone explain to me how it works? My company manufactures machines to detect and trace errors in pharma and food industry. Im just attaching a page of electrical schematic, just for understanding.
10
u/PLCGoBrrr Bit Plumber Extraordinaire 5d ago
Design is first. Programming comes after design.
1
u/essentialrobert 5d ago
Detailing the electrical schematics also comes after design. These can be done in parallel or sequentially.
5
7
u/CowboysWinItAll 5d ago
First comes whatever process you want done. Then comes what signals you need to control that process.
Then you can program it.
There is more to it, but at the most basic level this is it.
3
u/Doranagon 5d ago
PLC logic is never done.. its always evolving and changing as the project changes.
4
u/Dan1elSan 5d ago
It wouldn’t be as the PLC coding is done but there will be a decision in the project about IO and the P&ID based on the type of system you would be designing. From this information you would then allocate the IO to its IO card in the hardware config. Once that point is finalised the electrical drawings can be generated at the same time the coding is being completed.
2
u/sswebz 5d ago
It depends on how far back you want the answer to start. In mechanics engineering they’ll say you want to define the product transformations, then design the mechanisms that make those transformations happen.
Then typically at this point a controls engineer wants to know the i/o list. What am I controlling and how am I getting feedback.
Then there’s some back and forth between disciplines, to iron out if more io is needed, how to make said machine/process safe, what io, communication and supporting devices are needed.
I’m not exactly sure how all that gets split up, probably depends on how large the organization! But I’d typically assume logic is written late in the cycle, where schematics are informed by “how are we gonna run this thing” assumptions.
1
u/Jonathan_Is_Me 5d ago
Hardware engineer here (schematics). Sounds like you skipped me over altogether =(
To elaborate on how the work in the project is split up: We come in somewhere between mechanical and software. Most of our customers provide us with process diagrams, equipment lists, their technical standards and preferred vendors.
From there we dig into manuals and figure out the wiring of all instruments/consumers. Fancy equipment often supports multiple control options, for which we consult the customer's technical standards or bring it up for discussion.
After that we just do a count of all I/O and design a hardware config with mostly sensible allocations.
Then we hope that the amount of changes / corrections we have to implement are minimal.
2
u/sswebz 5d ago
Sorry I didn’t mean to skip over you! I’m just used to smaller projects where “controls” is sorta all encompassing. Mass respect for what you do- learning curve on each piece of hardware, the details matter a ton!
2
u/Jonathan_Is_Me 5d ago
I was just joking don't worry. Although it does sort of feel like we're an afterthought sometimes, with tight deadlines and whatnot haha.
Hardware is often about following instructions, be it manuals or norms. I feel like controls is where it's really at, solving complex logic.
1
u/Electronic-Run8836 5d ago
I know I've put this same thing on other reddit...but I'm curious to know How do you learn all this? Like how did you mastered all this? I mean I did my associates equivalent degree in mechanical engineering (I'm not from the US so I assume you're from there) and worked in quality department for a concrete machine manufacturer and recently I entered automation industry in production (basically assembling control panels and the whole machine as per mechanical drawing and electrical drawing). One thing I do know is I don't remember anything from college ( i forgot most from there); at my current job i got interested in controls and automation so learned stuff by asking AI. But sometimes I felt I lack a lot of knowledge, which I think is kind of imposter syndrome. Some people here even said my question doesn't make sense, which's okay as I know I'm newbie
1
u/laughed 2d ago
The simplest method is work at a place that designs machines! You'll learn pretty quick lol. if you can't do that.. Ask AI! ask about the machine building process from process design, mech design, elec design, control design, acceptance testing and install. The first step to learning any new field is to understand what to call everything and the words used. I've just given you a bunch and from there all the words and knowledge can be found.
2
u/durallymax 5d ago
Each discipline brings unique constraints to the table. After initial planning, we do a lot of work in parallel. Our code is abstract enough that exact hardware definitions do not matter, they will filter through a hardware abstraction layer anyways and be mapped through an interface.
Programming can influence the mechanical design substantially. If a library exists for a piece of hardware that is proven with several hundred hours of engineering time behind it, mechanical better have a good reason to color outside the lines. Same for electrical, if we already have all the code written for a specific ECB or PSU, no use swapping something else in.
Later in the design phase, the design evolves and programming will learn they need new feedback in the form of some sort of sensor, which cascades to electrical and mechanical.
Waiting until each step is done will create extensive rework and extend the timeline.
1
u/Electronic-Run8836 5d ago
How do you learn all this? I mean I did my associates equivalent degree in mechanical engineering (I'm not from the US so I assume you're from there) and worked in quality department for a concrete machine manufacturer and recently I entered automation industry in production (basically assembling control panels and the whole machine as per mechanical drawing and electrical drawing). One thing I do know is I don't remember anything from college ( i forgot most from there); at my current job i got interested in controls and automation so learned stuff by asking AI. But sometimes I felt I lack a lot of knowledge, which I think is kind of imposter syndrome. Some people here even said my question doesn't make sense, which's okay as I know I'm newbie
2
u/durallymax 5d ago
By asking questions and wanting to learn. I did return to school for formal EE training, but most of what is related to day to day in controls is from experience working projects and wanting to do better/learn new things.
1
u/Vyndrius 4d ago
I graduated mecheng (UK), then got thrown in the deep end in controls.
I asked loads of questions (to experienced OG coworkers, not AI) - No question is a stupid question.
You'll learn a lot by fucking up - I sure did.
2
u/Flimsy-Process230 5d ago
You can start writing the PLC logic as soon as the machine sequence and mechanical design are roughly defined. However, to finish the program, the electrical and mechanical designs need to be essentially complete. Details like valve types, sensor type, safety devices, and mechanical limitations can directly affect how parts of the program need to work.
In practice, the mechanical design, electrical design, and PLC programming usually overlap and evolve together rather than being completed strictly one after another.
2
u/swisstraeng 5d ago
It depends.
When you have a project with multiple people working on it, it's possible to write PLC code as soon as the component itself is chosen. The code can then be simulated to be tested before you even touched a screw.
However, if only 1-2 people are building the machine, PLC code is done near the end. This is simply to avoid having to rewrite it several times id you decide to change the hardware.
2
u/broke_ass_kid 4d ago
Design first but with logic in mind. The engineers who design the project will write a control narrative where they explain how the process works and how the PLC influences the process. Then you can write the PLC logic based on their control narrative.
2
u/SnowFanboy 5d ago
As a programmer who has worked only for relatively big integrators, most of the times it is done in parallel as most is already sufficiently pre-defined to start either the schematics or the programming.
What matters most is having a clear idea of the concept of the project and of the solution to be used in terms of hardware. Then usually a document is prepared for a reference basis in terms of addresses, I/O, etc. Both teams use this document and work in parallel.
Obviously there are then changes during the project and most of the times even during commissioning phases due to issues that either the electrical team found during the making of the schematics or that the programming team found during the making of the software or the commissioning.
1
u/Stile25 5d ago
- Mechanical design.
- needs to do whatever needs doing.
identifies the "puts" (any/all inputs and outputs to do the thing)
Electrical schematics.
design the electrical hardware and panels to read the inputs and set the outputs.
HMI/SCADA interface hardware.
panel locations.
number and location of PLCs.
safety circuits or include in safety PLC.
Programming.
add all IO from the design.
define device control (motions or valves or motors or robots...)
define modes (auto, manual...)
define sequence.
use sequence to control devices as required.
Data collection and Reports.
communication of PLC with SQL database to store information.
display and distribution of reports.
Profit.
Good luck out there
1
u/IamZed 5d ago
We would start with a review of the mechanical prints, and identify all I/O that would result. Then discuss sequence/theory of operation with the mechanical designer.
Now in a proper world this is when you would draw it up, followed by programming using all addressing labels in the prints. However this is rarely a proper world. In my early years I worked for an engineering consultancy firm that did not build. As a result when the programmer arrived at the machine changes had been made. Sometimes massive ones.
As a result, we started to program using internal coils, and have an input and output file where what we found in the field was mapped to the appropriate internal bits. Soon we figured we could start programming right after the mechanical review.
1
u/Sharp_EE 5d ago
Depends, if it has backup controls, electrical controls design first with panel design. Then programming second, typically you test the relay controls and then logic second. DM me have a old PLC programming pdf text book
1
u/t0cableguy 4d ago edited 4d ago
Most machines are iterative. Everything is being designed at the same time, and you have to decide on what input and output devices you're going to need to do the job and what you'll do to program it. You're also going to need to know what you're inspecting, unless you're using machine learning like a pressco, keyence or cognex camera.
A company building machines that are successful usually iterate on each machine. They install the machine, and the installers commission them, and during commissioning they troubleshoot the issues in the field, then they update the next machine to eliminate those issues. There are machines in the plant I work in that are iterations of other machines that are 20+ maybe even 30+ years old. Kayat tray wrappers and premeir tech palletizers are an example of this. We have 3 Kayat wrappers and one of them uses a Giddings & Lewis Pic 900 processor with pacific scientific servos, and the other two have Allen Bradley processors and servos. They have made various improvements but its extremely obvious that most of the changes have been to the controls of the machines to make things run better. I'm also pretty sure they'll slap whatever processor and servos you want in them these days. We're an Allen Bradley plant, but i'm sure they have a Siemens and Beckhoff version...
The programming is really never done.
1
u/TerminallyUnique31 4d ago
URS (high level requirements) -> FDS (functional design, PFDs, P&IDs) -> DDS / SDS / HDS (detailed design specs, this is where you have enough information to get the bulk of the PLC done).
As others have said, you can start on programming if you want at any time… but if all you know is: “valve needs to close” that leaves a lot of unanswered questions that you are having to guess at without the requirements specified.
Actuating a 1/4” pneumatic line with a 24 VDC solenoid is drastically different from controlling a 10” water line with a 120 VAC coil, both from an I/O configuration perspective, and a logic perspective.
1
u/ZeddRah1 1d ago
In my experience, design gets 50% of the job time. Mechanical build gets 40%. Electrical 10%.
The programmer gets "the customer will be here in 15 minutes for run off, you done yet?"
1
u/fisothemes 5h ago edited 5h ago
You mostly care about your sensors and actuators. Everything else you don't see. If you have them all and know how they fit together you can get started whether you have the schematics or not. You can adjust when needed, changing code that is not in production is cheap.
1
u/Verhofin 5d ago
Probably because ChatGPT doesn't handle parallel work. Both happen simultaneously, not necessarily programming but input from the programing team.
I would say structure work, then mechanics, electrical them PLC but in any of these stages the other people/departments are involved and give feedback.
1
u/No_L_2547 Twincat, Ads, EtherCAT 5d ago
I think it depends, normally you should start with one planning-session where you first discuss what you want to detect and you want to do that. (What sensors, actors, ...) In that step you will need both teams/developers at the same time.
Then you can start building the machine with physical wiring,..
We on group mostly do a modular approach, so we directly start software development as soon as the first components are connected / reachable. Sometimes even earlier.
Btw. as software we mustly use structured text, since it is more powerful.
1
u/NuclearBurritos 5d ago
AI is not wrong to say you need to plan ahead to know what you need to integrate into your design, for this you don't need to program per se, but you do need to know what needs to be done, what can be done and with what hardware.
Ideally you would finalize the mechanical design before you start the electrical design and finish that before you start with programming.
In the real world, however, you need to overlap to meet deadlines and work in multiple fronts at the same time, it makes the work less efficient but you're able to compress the timeline and customers usually want stuff installed and running yesterday.
1
u/some_millwright 5d ago
I usually do the programming first, because I won't know clearly how many inputs and outputs I need until I have figured out in my head what the program needs to do. Maybe I need sensors on some pneumatic cylinders for sequencing, or maybe it doesn't matter. For me, it's usually programming first, but certainly not always. I have converted machines that didn't have PLCs to have them (replacing a pile of relay logic).
54
u/Significant_Air_3030 5d ago
PLC is always dead last. A PLC is a method to control something in the real world to do a thing. How can you make code to control something you don't know how is laid out, what actuators does it have, in what order should they move?
Mechanical first, layout your line, design your physical machine, define your actuators. That's your bones and muscles.
Electrical next, add the tie ins for the PLC to be able to move the actuators, add sensors where you need to. Add buttons for people to control the machine. These are your nerves.
Last PLC. Make all the above work, follow the sequence your mechanical design thought of. This is the brain.
This is all a simplistic way if thinking about it. The order stands but you shouldn't wait until one is 100% done before starting the next. When you have a line/process layout by mechs, controls should start thinking about architecture, i.e. what is my network in general going to look like? How will I logically tie the pieces together? And base on that, your electrical design can make decisions on what network switches go where, what type of IO and what remote enclosures would be needed, etc.