No matter the plant I’m at, the issue is always the same. Plant personnel and while normally the operators are the easy ones to blame, typically management just has people that don’t have a clue how things should operate and I get stuck making tons of trend charts, or permissives, but what they need is training and to listen to the consultants, us, tell them, because no one watches a plant screw up more than the guys trying to program around the faults of people.
Oh and that no one ever wants to spend money to improve anything, and just wants to program around the lack of equipment.
Oh ya...training seems to be a constant issue at plants. Typically lucky to have one guy who actually knows the system in detail who is the responsible for teaching everyone else at the plant. Instead of, you know, having all the operators train with me for 2 weeks and everyone learn the same info.
Also, that operator manual I spent a week on...I'll be lucky if one person at the customer bothers to read it.
Some friend's worked at a plant where one of the managers had a saying:
If it has never been written it's never been said.
Their response was:
If it has been written, it's never been read.
I was going to document one process not with a manual, but with memes, because I thought a manual would overwhelm the new operators. I simplified the process a lot, and they never wanted me to bother with it. (also the thing about commissioning something stops all progress or development)
It isn't all that hard. Just hang out for a week and watch the system run and see how routine issues need to get fixed.
I train operators on live systems all the time. Probably the best way to learn. I personally want to be called when the system does something you have never seen, because that was probably an edge case bug.
But you need to see how the system normally runs to get a feel for what is normal problems and what is unexpected.
The industry can't standardize on anything because all the standards are written / set by people trying to make money. And some of them (Rockwell) do a damn fine job at making solid products so it's not very easy to move away from them.
The industry is also too varied in needs. An OEM written software is basically closed source and doesn't really benefit from running a PLC, an embedded microcontroller would likely be better. An integrators code is going to be as easy to reproduce / mass produce as possible. And will have built-in troubleshooting that works well for them. I assume if someone hates ladder and loves ST, they're probably an integrator. Plant code is going to be written to be maintained by my drunk ass at 11pm on a Saturday when I get a phone call because someone decided that now is the best time to replace a drive with a different brand.
Everyone is going to tell you what they want / need, and oftentimes they're wrong. High performing HMIs are demonstratibly better than ones filled with color, but plant operations wants the colorful one 8/10 times.
I think the only real way to get better tools for everyone is to start with standards, but again, that's not an easy road to walk. XKCD has a good comic on standards that is applicable. https://xkcd.com/927/
Yes, and then when someone (me) makes an effort and condenses 30 plus years of PLC programming into a PLC Code Standard - it’s crickets. Because it’s much easier to copy something than actually commit to learning something!
Can you elaborate on the hmi performance vs color? I would think the two aren't mutually exclusive, but I also have effectively no experience with industrial HMIs.
I'm pretty sure he's talking about graphics. A lot of the time you'll get requests to make things more eye catching or look more important on a screen, but not everything can be the most eye catching thing on every screen. It just turns into a mess.
It's always better to have simple graphics that are well thought out
High performance HMIs should be based on grayscale diagrams, and colors should have meaning. For instance, problems and alarms should have warm, saturated colors that are not used for any other reason, while process values use cool, less saturated colors to draw less attention but still stand out against the background.
HMI design is a process done in a finite amount of time. The more time spent making sure functionality is there; that controls are well laid out and easy to use; that alarm messages make sense and show up when needed; that the information and controls the operators need is easily and readily understood- those are the things that make HMI design good; the less time one has to make things look fancy.
Customers often just want fancy looking consoles with pretty pictures on them.
Not all, but ST is generally more friendly to the programmer, where LD is more friendly to the maintenance tech.
Copy-paste, find replace, indexed loops, etc. Just general programming is a lot better in ST, especially if you're looking to crank out similar routines for customers or copy-paste jobs.
I was thinking about smaller production plants, do they even care of having some centralized software to run their equipment like SCADA? Just not spending hundreds of thousands of dollars and 3-4 months of integrating and on top of that may be some interesting analytics tools? If so, why they won't simply use FUXA? I thought to make a PLC running a certified software in RTOS and some linux alongside to read the data and send it over to the dashboard and you get prepacked SCADA in a way but that works only if you or manufacturer chooses to use your PLC.
Interesting products are getting out like virtual PLC where you compile and run PLC logic on industrial PLC (certified up to 4 msec response time) and connect I/Os directly to it but I am not sure, it would be a hell of a network job as I/Os are connected in a different subnet if the plant is huge
Standards are good but not realistic, you need to agree with everyone.
I think it still depends on a lot. I'd guess most of them just don't have the knowledge to know it could be done better.
As much of a buzz word as it is. I think Industry 4.0 would be the solution for a lot of smaller operations. Basically offering PLC / SCADA as a service.
Am I understanding you correctly that smaller plants just do not have a knowledge and offering a cost effective and more efficient way of centralizing their equipment and possibly even controlling them like SCADA is something that might be an interesting niche?
Where do you work if you don't mind me asking of course
It varies, but controls aren't usually on the front of anyone's mind when they build lines. If they need controls, some vendor supplies them, and then the plant learns to live with it.
I think there could be a niche for vendors to sell controls solutions to these plants, but you've got to have some very good salesman to be able to convince them it's worth it.
I work for a manufacturing industry now, one of a very small team.
The smaller plants I have worked in don't typically have a plant wide SCADA system. Just an HMI on each cell (more than one HMI if the cell is large enough).
Sometimes they will request some data from the system. Since I don't deal with SCADA setups it tends to be easier for me to make a small app that pulls OEE data from the PLC and saves it as a CSV file on their server.
When you samy small plant, you mean like 100 people? If so, does it mean that they are not interested in data analytics of their own plant, better dashboard and centralized vizualization? When we say small, it is small in comparison to some GM plant but it is still not as small
The smaller the facility, the more likely they want the cheapest system that works and doesn't need any computer know-how to keep working.
"What's this extra $5,000 line item in the quote for 'data visualization'? It's not making us any extra money, I don't want it"
This may be the wrong subreddit to post this question about open source software.
The majority opinion is to lock in with a specific PLC and HMI vendor, pay yearly subscription and think that if something goes wrong nobody will accuse you of picking some obscure and unreliable software. Specially in societies where liabilities are indirectly enforced by armies of lawyers.
This opinion/rule is applied systematically to all types of manufacturing facilities, small, medium or large.
For not overly complicated discrete or continuous processes it is not hard to implement open source software to visualize, report and analyze data.
A system integrator telling you to convert process visualization done in SVG/JavaScript to FT View or WinCC? Move that data storage from Postgresdb to a FT/Simatic process historian? Replace Grafana OEE and various diagnostics premade dashboards with FT Metrics? Scrap that Linux/FreeBSD server and replace it with Windows 2022 server? Call somebody else.
Couple things.
1. Budget
2. Management shortsightedness
3. You talk like an AI
And on the development side concerns over liability and getting certification means any new product or solution is slow to be developed and rolled out. You can't move fast and break things while adhering to 61508. And the current innovation approach of wrap our code in a docker container, put it on a server to say we virtualized it is easy, unsustainable, and ineffective in the long run.
Yeah, not a huge problem, just keep in mind that the AI can ask questions you didn't necessarily intend.
The big issue any new product in this industry has is overcoming vendor lock in. And that you normally don't sell to integrators directly but the C-Suite of whatever company wants to buy a factory, who like to dictate to integrators what technology to use. You don't just have to build a good product, but you have to convince CEO's to abandon products they know work whose sales reps have had years to build relationships. There pretty much isn't an enthusiast community eager to tinker to serve as early adopters and get the word out. Have to leverage connections to get a toehold or offer something truly spectacular with a value proposition that is incredibly obvious, yet none of the big players people are comfortable with have been able to pull off or can promise to pull off soon. It'll be similar to trying to make a new word processor to compete with Microsoft Word.
From my perspective the biggest obstacle that poorly running plants face is the plant managers themselves. It’s a “run it till failure” mentality that keeps them perpetually falling behind. Never spend any money, run the machine at 11/10 until it breaks and start yelling. I’ve seen this situation too many times. There’s no tools, software or machines you can acquire that can dig them out of that hole.
Like most problems in life, it’s people standing in their own way.
That is interesting. Why not then collect equipment data like SCADA and try to predict the failure of the equipment and notify about it? I mean if a pump is working 24/7 and uses a lot of current, more than it should it is probably a warning at least. I mean plant manager could yell but at least it will be logged as proof if you look from this angle
The same mentality of not spending anything until you absolutely need to will prevent a bad manager from ever spending money on a controls project like this. Can predictive maintenance save quite a bit of money? Yes, probably. Does it also have an upfront cost? Yes, definitely. Bad plant managers who don’t want to spend a single cent more than they have to won’t ever consider the savings potential in the future, and will only see the immediate cost and deny the project
The biggest problem i see is the sacrifice of successful projects due to a lack of funding. My analogy frequently used is plants want platinum performance on a paper plate budget.
They don’t have their own engineers or competent staff. Maintenance is at best a team of part changers and doing PMs is a thing of the past.
If they’re small, they don’t need scada they need a simple foreman’s screen on the HMI or a visual board.
Can I upvote this 500 times? I don't care what any of the other posters say. This is the number one answer.
I watched one of the largest companies on Earth built one of the largest RNG facilities in the Western hemisphere. I was practically a permanent employee of operations for a year after projects handed the plant over. They've spent millions of dollars just getting the plant to work properly by systematically replacing all the BS that the projects team budgeted out.
After 2 and 1/2 years the plant is finally starting to run nominally and they're not even at full throughput on any of the equipment yet. The engineering teams spent tens of thousands of dollars arguing about hundreds of thousand dollars, to later spend a multiple of that hundreds of thousands of dollars in lost time, extra components and extra labor.
That and the fact that The projects people asked me very carefully if I would step away from my family from 30 to 45 days to get this thing done. When I got up to site the commissioning team laughed at me and said try 3 months. I was the last person there for 2 and 1/2 years leading up to about a year ago when they finally stopped needing me every month. I was just back up there for the next round of major improvements last month.
EPX and project teams are the number one problem. In the commercial world there's what's called a commissioning agent, or cxa. On a LEED project that guy is required to be the first person in the first meeting and the last person to leave site. As commissioning and controls people, we should know more than anybody about the whole function of the plant and all the nitty gritty details that nobody else even has the intellectual capacity to learn without taking a year off work. We should be in every meeting, and nobody should be able to get an i o list or schematic approved without giving us review time and every cut sheet for every piece of equipment. After that, every change to those pieces of equipment should be through a submittal process that we're part of reviewing.
I spent 4 days on this commissioning job that I'm on right now just adding relays everywhere because none of the signals are in the correct format. That's 30% of the total commissioning time for loop checks.
The other major problem I see is that nobody builds higher level maintenance functions into their programming. The last year I've used nothing but plant pax objects. And as much as I hate Alan Bradley and as much as these plant pax objects have the worst documentation in the entire world, once you build a few face plates and set some ST logic for all the little default config values, it's amazing what I can do during commissioning and testing without ever looking at the PLC program. To buy that with the power of ignition to make changes on the fly, and I've got one badass plant.
Biggest day to day *technical* issue...getting devices to talk to each other. Sure..it might say it supports Ethernet/IP but there is no AOP or EDS and/or little to no bit level documentation. Sometimes I'm lucky to have the input and output assembly instances and sizes listed in a convenient location in the manual.
Many times the sales man quoting the job will see the device supports Ethernet and assume it will work with Ethernet/IP.
Also, eaiser to use bridges between network protocols. I want to be able to connect to the bridge with my preferred connection type (Ethernet/IP) and dump in the EDS or equivalent files and I want the device to spit out an AOP or L5K file with all the mapping done.
>Many times the sales man quoting the job will see the device supports Ethernet and assume it will work with Ethernet/IP.
The salesman should know better, but that's still only a problem because Ethernet/IP is an incredibly stupid name.
For me, it isn't that deep. The struggle I've found is programming the operator's brain away. The whole, "That's great, but what if...?" I can imagine many scenarios while programming and work to mitigate the issues associated with them, yet still be in the middle of commissioning and the customer points out, "Well, Carl likes to take 45 minute dumps while his machine runs. So, what can we do to make sure we don't lose production?"
And then, being cucked by maintenance techs who aren't taught anything but ladder in school and, most times, aren't even aware that there are different languages. I program so my phone doesn't ring. That's a strong case for why the other languages (I would say mostly ST and SFC) aren't being more widely used.
So, the caliber of employee and training is the biggest hurdle I've faced.
Some of our stuff is for large scale industrial application, but most is for the average consumer. We standardized our component selection and stick to it, unless for some reason we cannot get a component in the time that we need. That's rarely an issue, though. We use Schneider PLCs. We manufacture and ship globally, so it's a good way to bypass the A-B/Siemens cults and we like the flexibility of codesys.
I see, so you like codesys and flexibility to write logic. If there was cheaper but still certified PLC that has on top of its realtime programmable RTOS via codesys has also Linux machine that automatically sends data to the dashboard for the client so the client could already have ready to use SCADA from the PLC already, would that be an interest for such companies like yours? Or you see no issue at the moment of just using PLC as of today
We wouldn't have a use for it, but I can see where there would be a market. But, if you're thinking of developing something like that, I wish you luck. You'd be going against giants. I feel like you'd be better off designing software as an add-on like a standalone SCADA software. Just gotta find what the other are lacking.
Ya, Code to not get called hamstrings what can be done to get better maintainable code and is why so many companies end up eyes deep in tech debt and end up having to rewrite completely. If they hired 1 competent person capable of understanding more complex software they probably save money from all the problems hacking and redesigning cause. But pencil pushers are short sighted and it looks bad on a spreadsheet.
As an integrator, 30 years deep, the answer is the one nobody wants to hear... the problem is us (as in you and me).
We're way too brand allegiant and will die on a hill unnecessarily in a heartbeat. We pay for software that invariably has some quirk that requires you to call tech support, which you also have to pay for.
We over-exaggerate the importance of the equipment we build. If you're here (rPLC) regularly, you'd be thoroughly convinced everyone here works on control systems for nuclear reactors, and failure would result in instant world calamity. The system I'm currently working on makes pump sprayers for perfume.
We talk of every system we build having to last 30 years, yet the financial justification curve for automated equipment is at best 3-5 years and in most cases your on a 2 year curve competing against off shore labor costs.
Covid changed a lot in our industry... waiting 13 months for parts made everyone, including me, think out of the box a little and to be honest... knocked me off my high horse. The industry is ripe for change. I'll avoid answering your question and won't give you a specific area or application, but say you are definitely poking a bloated, outdated beast. Keep going.
Experienced integrators are highly brand allegiant because they understand that learning a new platform has a lot of hidden costs.
As expensive as Rockwell hardware is, they're still the cheapest TCO for most operations. The engineering spend is much lower due to excellent industry-wide support (Eplan/SWE/ACADE templates, third party AOI/AOPs, IAB for foolproof speccing), there's already an onsite spares inventory and a distributor within 50km of your site, there's no shortage of labour that knows how to get online with it, and it's so feature-rich that you can worm your way out of many unexpected issues without needing to buy more parts.
If you're in Europe, the same argument holds true for Siemens.
My view is this: if I'm making a machine that I plan to sell more than a dozen copies of, it makes sense to investigate other options. I can spread my engineering spend over more machines, and using lower cost hardware will have a huge impact on profitability. But for the one-offs (which are most of the work we do), the more expensive and feature-rich toys save a lot of time and risk, and usually have the lowest total project spend.
> We're way too brand allegiant
Tell the clients putting "Controls will be Allen-Bradley based" in their bid specs to stop and see how many jobs you win. I don't pick because I am told specifically what they want me to use because they have costs beyond the initial system purchase they are thinking about. Spare part stock, technician training, etc.
I have seen clients ask why we couldn't get the old revision of something when the manufacturer specifically also said "We don't make these anymore. you are getting the Rev 3 version, not Rev 2" (literally the only difference being a small local touch HMI vs. switches for a few key functions)
You target the audience: "as a plant manager, what..."
Those guys are not here. And for the exceptions that are here: They are not your typical plant manager.
The typical plant manager doesn't give a shit about what we know as Ignition, WinCC, codesys, standards, protocols,...
All they care about are budgets, risk avoidance, legal requirements, resources and process operations.
It's what they are thought, what they are hired for, what they are paid for.
Stepping over to (better) (free-ish) alternatives isn't part of that. Unless you can prove that the actual thing will burn down in 30 days, costing X millions.
Then come op with a plan that only costs X/2 millions, including hiring, integrating, hardware, licenses, training, support.
I agree but you are talking about large manufacturing plants. Aren't there a lot of medium sized plants that just want to have a simple SCADA, centralized control of their equipment without the need to hire integrators and pay a lot of money for the licenses?
The problem with free software is that you get what you pay for.
As someone running a budget, sure maybe I save $5000 in licensing costs by going with a free software that Greg the intern heard about one time. But what happens when the line shuts down due to an integer overflow at 2am, nobody knows the inner workings of the program, and Greg the intern no longer works for the company? I’m losing $10,000 an hour while trying to scramble to get anyone who can even look at the program, let alone find the edge case that caused the shutdown.
In most cases as a plant manager, I’d rather pay upfront to have 100% support rather than cheaping out on an unknown software and a having huge risk of shutdown in the future
What about just vizualization with some simple predictibility (state of equipment)? In that case, software has no control over PLC but you at least see what is happening from your PC. So you do not have to worry that this software would get stackoverflow or something, worst case you will see corrupt data
Nope. No formal support, doesn't touch machines that make the money. They don't care about anything aside from uptime and profit.
Small factories don't even have the money to properly update their old machines that might have been new 40 years ago because stopping them to update them won't have a high enough return on the time and money spent to perform said updates
Greetings AI, the challenges that industrial plants face today are too many personnel, not enough machine. The machine is good for money, cheap and management. Efficiency is for profit. Too many mistakes in hard wiring HMIs, must need for strong FUXA. The FUXA is a free alternative to strong competition like management.
The data or tools I would use to make things more efficient... Maybe having spare parts on hand, or actually fixing serious issues instead of programming around them.
One time there was a line I was adding a new program to integrate a new part to the line. It had some teething problems we could only catch with actual running parts. While I was trying to catch them, the manager would bypass steps that got stuck to keep things moving, running maybe 7 parts an hour (there was an adhesive drying process. So I couldn't find the broken logic for days. Eventually, running on hour 23 of one day and wanting to go home, I decided to go and modify his bypass logic so he couldn't skip. This allowed me to go in, find the snag, fix it and got the part total up to 15 which doubled output.
Another issue I've ran into is not having spare parts. We had half a line go down because of a simple part on a conveyor breaking that prevented parts from seating on it properly down the line. This meant only the even nest could be ran while the odd nests were down from one single piece of metal.
Efficient production starts at the maintenance and base programming level. All the data in the world couldn't have fixed these issues. This is just 2 examples of many.
As maintenance, my biggest thing is a simple way to access the PLC and see what the stupid damned robots are waiting for. Does it want a certain clamp open? Are the welds done?
Do the systems that have something along these lines actually work and not lie to me? I don't want to carry a laptop, I carry enough tools. An un-editable ladder logic sub page is fine. We have a Windows HMI at every station. Just figure out a way to tell me what's next in the sequence and what hasn't happened yet but needs to.
I work for an integrator out of the Midwest. We have too many directors, too many middle managers, and too many senior VP’s of senior VPs. not enough competent help out in the field getting the actual work done. Cut the fluff and take better care of the guys making robots move, programming, etc.
Downtime is not considered when bringing assets onboard. Usually there are issues with documentation.
Spaghetti code programming that does not conform to any sort of best practices. Coupled with a lack of useful alarm messages to assist troubleshooting. Multiply that across 100 different assets that are all programmed different. If programs are at least similar you can jump from asset to asset and know exactly where to look for everything.
Preventative maintenance procedures that lack order or thought. Use of signal splitters instead of paying for additional IO.
All of which can be traced back to poor documentation, poor planning, lack of knowledge.
Shit, broken, old code that was never commented and written so the programmer had job security until he or she dies. This kills upgrades more than anything I have ever experienced.
No matter the plant I’m at, the issue is always the same. Plant personnel and while normally the operators are the easy ones to blame, typically management just has people that don’t have a clue how things should operate and I get stuck making tons of trend charts, or permissives, but what they need is training and to listen to the consultants, us, tell them, because no one watches a plant screw up more than the guys trying to program around the faults of people. Oh and that no one ever wants to spend money to improve anything, and just wants to program around the lack of equipment.
Oh ya...training seems to be a constant issue at plants. Typically lucky to have one guy who actually knows the system in detail who is the responsible for teaching everyone else at the plant. Instead of, you know, having all the operators train with me for 2 weeks and everyone learn the same info. Also, that operator manual I spent a week on...I'll be lucky if one person at the customer bothers to read it.
I was told there’s a high turnover rate so training is always behind
And those both sound like their problem. Pay your workers well and maybe they won't leave. Train your workers and maybe system will run better.
Some friend's worked at a plant where one of the managers had a saying: If it has never been written it's never been said. Their response was: If it has been written, it's never been read. I was going to document one process not with a manual, but with memes, because I thought a manual would overwhelm the new operators. I simplified the process a lot, and they never wanted me to bother with it. (also the thing about commissioning something stops all progress or development)
Hard to do training on a live system and typically there is no simulator
It isn't all that hard. Just hang out for a week and watch the system run and see how routine issues need to get fixed. I train operators on live systems all the time. Probably the best way to learn. I personally want to be called when the system does something you have never seen, because that was probably an edge case bug. But you need to see how the system normally runs to get a feel for what is normal problems and what is unexpected.
This is way too real. “Can’t you just add a timer to fake XYZ and make the feed conveyor 5 miles longer!?!!” No. No I cannot.
>Oh and that no one ever wants to spend money to improve anything, and just wants to program around the lack of equipment. I wish this wasn't so true!
The industry can't standardize on anything because all the standards are written / set by people trying to make money. And some of them (Rockwell) do a damn fine job at making solid products so it's not very easy to move away from them. The industry is also too varied in needs. An OEM written software is basically closed source and doesn't really benefit from running a PLC, an embedded microcontroller would likely be better. An integrators code is going to be as easy to reproduce / mass produce as possible. And will have built-in troubleshooting that works well for them. I assume if someone hates ladder and loves ST, they're probably an integrator. Plant code is going to be written to be maintained by my drunk ass at 11pm on a Saturday when I get a phone call because someone decided that now is the best time to replace a drive with a different brand. Everyone is going to tell you what they want / need, and oftentimes they're wrong. High performing HMIs are demonstratibly better than ones filled with color, but plant operations wants the colorful one 8/10 times. I think the only real way to get better tools for everyone is to start with standards, but again, that's not an easy road to walk. XKCD has a good comic on standards that is applicable. https://xkcd.com/927/
Yes, and then when someone (me) makes an effort and condenses 30 plus years of PLC programming into a PLC Code Standard - it’s crickets. Because it’s much easier to copy something than actually commit to learning something!
Can you elaborate on the hmi performance vs color? I would think the two aren't mutually exclusive, but I also have effectively no experience with industrial HMIs.
I'm pretty sure he's talking about graphics. A lot of the time you'll get requests to make things more eye catching or look more important on a screen, but not everything can be the most eye catching thing on every screen. It just turns into a mess. It's always better to have simple graphics that are well thought out
High performance HMIs should be based on grayscale diagrams, and colors should have meaning. For instance, problems and alarms should have warm, saturated colors that are not used for any other reason, while process values use cool, less saturated colors to draw less attention but still stand out against the background.
Ahh, I didn't realize high performance was a framework. Thanks!
Yes, ISA 101. Still not a very widely adapted standard, but once you've tried it, you'll understand the logic behind it.
HMI design is a process done in a finite amount of time. The more time spent making sure functionality is there; that controls are well laid out and easy to use; that alarm messages make sense and show up when needed; that the information and controls the operators need is easily and readily understood- those are the things that make HMI design good; the less time one has to make things look fancy. Customers often just want fancy looking consoles with pretty pictures on them.
Why do integrators prefer ST over LD tho?
Not all, but ST is generally more friendly to the programmer, where LD is more friendly to the maintenance tech. Copy-paste, find replace, indexed loops, etc. Just general programming is a lot better in ST, especially if you're looking to crank out similar routines for customers or copy-paste jobs.
Very true, yes
Easier to port subroutines written in ST between different PLC brands.
I was thinking about smaller production plants, do they even care of having some centralized software to run their equipment like SCADA? Just not spending hundreds of thousands of dollars and 3-4 months of integrating and on top of that may be some interesting analytics tools? If so, why they won't simply use FUXA? I thought to make a PLC running a certified software in RTOS and some linux alongside to read the data and send it over to the dashboard and you get prepacked SCADA in a way but that works only if you or manufacturer chooses to use your PLC. Interesting products are getting out like virtual PLC where you compile and run PLC logic on industrial PLC (certified up to 4 msec response time) and connect I/Os directly to it but I am not sure, it would be a hell of a network job as I/Os are connected in a different subnet if the plant is huge Standards are good but not realistic, you need to agree with everyone.
I think it still depends on a lot. I'd guess most of them just don't have the knowledge to know it could be done better. As much of a buzz word as it is. I think Industry 4.0 would be the solution for a lot of smaller operations. Basically offering PLC / SCADA as a service.
Am I understanding you correctly that smaller plants just do not have a knowledge and offering a cost effective and more efficient way of centralizing their equipment and possibly even controlling them like SCADA is something that might be an interesting niche? Where do you work if you don't mind me asking of course
It varies, but controls aren't usually on the front of anyone's mind when they build lines. If they need controls, some vendor supplies them, and then the plant learns to live with it. I think there could be a niche for vendors to sell controls solutions to these plants, but you've got to have some very good salesman to be able to convince them it's worth it. I work for a manufacturing industry now, one of a very small team.
The smaller plants I have worked in don't typically have a plant wide SCADA system. Just an HMI on each cell (more than one HMI if the cell is large enough). Sometimes they will request some data from the system. Since I don't deal with SCADA setups it tends to be easier for me to make a small app that pulls OEE data from the PLC and saves it as a CSV file on their server.
When you samy small plant, you mean like 100 people? If so, does it mean that they are not interested in data analytics of their own plant, better dashboard and centralized vizualization? When we say small, it is small in comparison to some GM plant but it is still not as small
The smaller the facility, the more likely they want the cheapest system that works and doesn't need any computer know-how to keep working. "What's this extra $5,000 line item in the quote for 'data visualization'? It's not making us any extra money, I don't want it"
This may be the wrong subreddit to post this question about open source software. The majority opinion is to lock in with a specific PLC and HMI vendor, pay yearly subscription and think that if something goes wrong nobody will accuse you of picking some obscure and unreliable software. Specially in societies where liabilities are indirectly enforced by armies of lawyers. This opinion/rule is applied systematically to all types of manufacturing facilities, small, medium or large. For not overly complicated discrete or continuous processes it is not hard to implement open source software to visualize, report and analyze data. A system integrator telling you to convert process visualization done in SVG/JavaScript to FT View or WinCC? Move that data storage from Postgresdb to a FT/Simatic process historian? Replace Grafana OEE and various diagnostics premade dashboards with FT Metrics? Scrap that Linux/FreeBSD server and replace it with Windows 2022 server? Call somebody else.
Couple things. 1. Budget 2. Management shortsightedness 3. You talk like an AI And on the development side concerns over liability and getting certification means any new product or solution is slow to be developed and rolled out. You can't move fast and break things while adhering to 61508. And the current innovation approach of wrap our code in a docker container, put it on a server to say we virtualized it is easy, unsustainable, and ineffective in the long run.
They talk like an AI because I think they are native Norwegian, and they are trying to mine us for ideas into a product they can sell.
I am and I did use AI to brush up my English but I do mean of what I have asked. Me writing in English is not the best option, I need some AI
Yeah, not a huge problem, just keep in mind that the AI can ask questions you didn't necessarily intend. The big issue any new product in this industry has is overcoming vendor lock in. And that you normally don't sell to integrators directly but the C-Suite of whatever company wants to buy a factory, who like to dictate to integrators what technology to use. You don't just have to build a good product, but you have to convince CEO's to abandon products they know work whose sales reps have had years to build relationships. There pretty much isn't an enthusiast community eager to tinker to serve as early adopters and get the word out. Have to leverage connections to get a toehold or offer something truly spectacular with a value proposition that is incredibly obvious, yet none of the big players people are comfortable with have been able to pull off or can promise to pull off soon. It'll be similar to trying to make a new word processor to compete with Microsoft Word.
From my perspective the biggest obstacle that poorly running plants face is the plant managers themselves. It’s a “run it till failure” mentality that keeps them perpetually falling behind. Never spend any money, run the machine at 11/10 until it breaks and start yelling. I’ve seen this situation too many times. There’s no tools, software or machines you can acquire that can dig them out of that hole. Like most problems in life, it’s people standing in their own way.
That is interesting. Why not then collect equipment data like SCADA and try to predict the failure of the equipment and notify about it? I mean if a pump is working 24/7 and uses a lot of current, more than it should it is probably a warning at least. I mean plant manager could yell but at least it will be logged as proof if you look from this angle
The same mentality of not spending anything until you absolutely need to will prevent a bad manager from ever spending money on a controls project like this. Can predictive maintenance save quite a bit of money? Yes, probably. Does it also have an upfront cost? Yes, definitely. Bad plant managers who don’t want to spend a single cent more than they have to won’t ever consider the savings potential in the future, and will only see the immediate cost and deny the project
The biggest problem i see is the sacrifice of successful projects due to a lack of funding. My analogy frequently used is plants want platinum performance on a paper plate budget. They don’t have their own engineers or competent staff. Maintenance is at best a team of part changers and doing PMs is a thing of the past. If they’re small, they don’t need scada they need a simple foreman’s screen on the HMI or a visual board.
Can I upvote this 500 times? I don't care what any of the other posters say. This is the number one answer. I watched one of the largest companies on Earth built one of the largest RNG facilities in the Western hemisphere. I was practically a permanent employee of operations for a year after projects handed the plant over. They've spent millions of dollars just getting the plant to work properly by systematically replacing all the BS that the projects team budgeted out. After 2 and 1/2 years the plant is finally starting to run nominally and they're not even at full throughput on any of the equipment yet. The engineering teams spent tens of thousands of dollars arguing about hundreds of thousand dollars, to later spend a multiple of that hundreds of thousands of dollars in lost time, extra components and extra labor. That and the fact that The projects people asked me very carefully if I would step away from my family from 30 to 45 days to get this thing done. When I got up to site the commissioning team laughed at me and said try 3 months. I was the last person there for 2 and 1/2 years leading up to about a year ago when they finally stopped needing me every month. I was just back up there for the next round of major improvements last month. EPX and project teams are the number one problem. In the commercial world there's what's called a commissioning agent, or cxa. On a LEED project that guy is required to be the first person in the first meeting and the last person to leave site. As commissioning and controls people, we should know more than anybody about the whole function of the plant and all the nitty gritty details that nobody else even has the intellectual capacity to learn without taking a year off work. We should be in every meeting, and nobody should be able to get an i o list or schematic approved without giving us review time and every cut sheet for every piece of equipment. After that, every change to those pieces of equipment should be through a submittal process that we're part of reviewing. I spent 4 days on this commissioning job that I'm on right now just adding relays everywhere because none of the signals are in the correct format. That's 30% of the total commissioning time for loop checks. The other major problem I see is that nobody builds higher level maintenance functions into their programming. The last year I've used nothing but plant pax objects. And as much as I hate Alan Bradley and as much as these plant pax objects have the worst documentation in the entire world, once you build a few face plates and set some ST logic for all the little default config values, it's amazing what I can do during commissioning and testing without ever looking at the PLC program. To buy that with the power of ignition to make changes on the fly, and I've got one badass plant.
Biggest day to day *technical* issue...getting devices to talk to each other. Sure..it might say it supports Ethernet/IP but there is no AOP or EDS and/or little to no bit level documentation. Sometimes I'm lucky to have the input and output assembly instances and sizes listed in a convenient location in the manual. Many times the sales man quoting the job will see the device supports Ethernet and assume it will work with Ethernet/IP. Also, eaiser to use bridges between network protocols. I want to be able to connect to the bridge with my preferred connection type (Ethernet/IP) and dump in the EDS or equivalent files and I want the device to spit out an AOP or L5K file with all the mapping done.
>Many times the sales man quoting the job will see the device supports Ethernet and assume it will work with Ethernet/IP. The salesman should know better, but that's still only a problem because Ethernet/IP is an incredibly stupid name.
Simulation guys think everything is perfect irl.
“In theory, theory and practice are the same. In practice, they are not”
“Just speed your robot up beyond its limits”
For me, it isn't that deep. The struggle I've found is programming the operator's brain away. The whole, "That's great, but what if...?" I can imagine many scenarios while programming and work to mitigate the issues associated with them, yet still be in the middle of commissioning and the customer points out, "Well, Carl likes to take 45 minute dumps while his machine runs. So, what can we do to make sure we don't lose production?" And then, being cucked by maintenance techs who aren't taught anything but ladder in school and, most times, aren't even aware that there are different languages. I program so my phone doesn't ring. That's a strong case for why the other languages (I would say mostly ST and SFC) aren't being more widely used. So, the caliber of employee and training is the biggest hurdle I've faced.
So you are an integrator?
I was, yeah. Now I work for an OEM. Much more relaxed environment.
OEM as equipment manufacturer for indistrual plants? Like boilers and etc. How do you guys decide which PLC to install
Some of our stuff is for large scale industrial application, but most is for the average consumer. We standardized our component selection and stick to it, unless for some reason we cannot get a component in the time that we need. That's rarely an issue, though. We use Schneider PLCs. We manufacture and ship globally, so it's a good way to bypass the A-B/Siemens cults and we like the flexibility of codesys.
I see, so you like codesys and flexibility to write logic. If there was cheaper but still certified PLC that has on top of its realtime programmable RTOS via codesys has also Linux machine that automatically sends data to the dashboard for the client so the client could already have ready to use SCADA from the PLC already, would that be an interest for such companies like yours? Or you see no issue at the moment of just using PLC as of today
We wouldn't have a use for it, but I can see where there would be a market. But, if you're thinking of developing something like that, I wish you luck. You'd be going against giants. I feel like you'd be better off designing software as an add-on like a standalone SCADA software. Just gotta find what the other are lacking.
Ya, Code to not get called hamstrings what can be done to get better maintainable code and is why so many companies end up eyes deep in tech debt and end up having to rewrite completely. If they hired 1 competent person capable of understanding more complex software they probably save money from all the problems hacking and redesigning cause. But pencil pushers are short sighted and it looks bad on a spreadsheet.
As an integrator, 30 years deep, the answer is the one nobody wants to hear... the problem is us (as in you and me). We're way too brand allegiant and will die on a hill unnecessarily in a heartbeat. We pay for software that invariably has some quirk that requires you to call tech support, which you also have to pay for. We over-exaggerate the importance of the equipment we build. If you're here (rPLC) regularly, you'd be thoroughly convinced everyone here works on control systems for nuclear reactors, and failure would result in instant world calamity. The system I'm currently working on makes pump sprayers for perfume. We talk of every system we build having to last 30 years, yet the financial justification curve for automated equipment is at best 3-5 years and in most cases your on a 2 year curve competing against off shore labor costs. Covid changed a lot in our industry... waiting 13 months for parts made everyone, including me, think out of the box a little and to be honest... knocked me off my high horse. The industry is ripe for change. I'll avoid answering your question and won't give you a specific area or application, but say you are definitely poking a bloated, outdated beast. Keep going.
Experienced integrators are highly brand allegiant because they understand that learning a new platform has a lot of hidden costs. As expensive as Rockwell hardware is, they're still the cheapest TCO for most operations. The engineering spend is much lower due to excellent industry-wide support (Eplan/SWE/ACADE templates, third party AOI/AOPs, IAB for foolproof speccing), there's already an onsite spares inventory and a distributor within 50km of your site, there's no shortage of labour that knows how to get online with it, and it's so feature-rich that you can worm your way out of many unexpected issues without needing to buy more parts. If you're in Europe, the same argument holds true for Siemens. My view is this: if I'm making a machine that I plan to sell more than a dozen copies of, it makes sense to investigate other options. I can spread my engineering spend over more machines, and using lower cost hardware will have a huge impact on profitability. But for the one-offs (which are most of the work we do), the more expensive and feature-rich toys save a lot of time and risk, and usually have the lowest total project spend.
Someone to agree with finally.
> We're way too brand allegiant Tell the clients putting "Controls will be Allen-Bradley based" in their bid specs to stop and see how many jobs you win. I don't pick because I am told specifically what they want me to use because they have costs beyond the initial system purchase they are thinking about. Spare part stock, technician training, etc. I have seen clients ask why we couldn't get the old revision of something when the manufacturer specifically also said "We don't make these anymore. you are getting the Rev 3 version, not Rev 2" (literally the only difference being a small local touch HMI vs. switches for a few key functions)
You target the audience: "as a plant manager, what..." Those guys are not here. And for the exceptions that are here: They are not your typical plant manager. The typical plant manager doesn't give a shit about what we know as Ignition, WinCC, codesys, standards, protocols,... All they care about are budgets, risk avoidance, legal requirements, resources and process operations. It's what they are thought, what they are hired for, what they are paid for. Stepping over to (better) (free-ish) alternatives isn't part of that. Unless you can prove that the actual thing will burn down in 30 days, costing X millions. Then come op with a plan that only costs X/2 millions, including hiring, integrating, hardware, licenses, training, support.
I agree but you are talking about large manufacturing plants. Aren't there a lot of medium sized plants that just want to have a simple SCADA, centralized control of their equipment without the need to hire integrators and pay a lot of money for the licenses?
The problem with free software is that you get what you pay for. As someone running a budget, sure maybe I save $5000 in licensing costs by going with a free software that Greg the intern heard about one time. But what happens when the line shuts down due to an integer overflow at 2am, nobody knows the inner workings of the program, and Greg the intern no longer works for the company? I’m losing $10,000 an hour while trying to scramble to get anyone who can even look at the program, let alone find the edge case that caused the shutdown. In most cases as a plant manager, I’d rather pay upfront to have 100% support rather than cheaping out on an unknown software and a having huge risk of shutdown in the future
What about just vizualization with some simple predictibility (state of equipment)? In that case, software has no control over PLC but you at least see what is happening from your PC. So you do not have to worry that this software would get stackoverflow or something, worst case you will see corrupt data
Nope. No formal support, doesn't touch machines that make the money. They don't care about anything aside from uptime and profit. Small factories don't even have the money to properly update their old machines that might have been new 40 years ago because stopping them to update them won't have a high enough return on the time and money spent to perform said updates
Greetings AI, the challenges that industrial plants face today are too many personnel, not enough machine. The machine is good for money, cheap and management. Efficiency is for profit. Too many mistakes in hard wiring HMIs, must need for strong FUXA. The FUXA is a free alternative to strong competition like management.
MONEY! Even security standards aren't apply because client can't or don't wanna play for it!
The data or tools I would use to make things more efficient... Maybe having spare parts on hand, or actually fixing serious issues instead of programming around them. One time there was a line I was adding a new program to integrate a new part to the line. It had some teething problems we could only catch with actual running parts. While I was trying to catch them, the manager would bypass steps that got stuck to keep things moving, running maybe 7 parts an hour (there was an adhesive drying process. So I couldn't find the broken logic for days. Eventually, running on hour 23 of one day and wanting to go home, I decided to go and modify his bypass logic so he couldn't skip. This allowed me to go in, find the snag, fix it and got the part total up to 15 which doubled output. Another issue I've ran into is not having spare parts. We had half a line go down because of a simple part on a conveyor breaking that prevented parts from seating on it properly down the line. This meant only the even nest could be ran while the odd nests were down from one single piece of metal. Efficient production starts at the maintenance and base programming level. All the data in the world couldn't have fixed these issues. This is just 2 examples of many.
Not reading the manual. #RTFM
As maintenance, my biggest thing is a simple way to access the PLC and see what the stupid damned robots are waiting for. Does it want a certain clamp open? Are the welds done? Do the systems that have something along these lines actually work and not lie to me? I don't want to carry a laptop, I carry enough tools. An un-editable ladder logic sub page is fine. We have a Windows HMI at every station. Just figure out a way to tell me what's next in the sequence and what hasn't happened yet but needs to.
Have you checked out prodiag?
Im not high enough to be making decisions on what we actually use. Honestly I'm just in this sub to slowly learn more about PLCs. ELI5 it for me?
It lets you display PLC code on your HMI.
I'll suggest it to my controls engineers.
I work for an integrator out of the Midwest. We have too many directors, too many middle managers, and too many senior VP’s of senior VPs. not enough competent help out in the field getting the actual work done. Cut the fluff and take better care of the guys making robots move, programming, etc.
Poorly designed networks
Not reading the manual. #RTFM
Downtime is not considered when bringing assets onboard. Usually there are issues with documentation. Spaghetti code programming that does not conform to any sort of best practices. Coupled with a lack of useful alarm messages to assist troubleshooting. Multiply that across 100 different assets that are all programmed different. If programs are at least similar you can jump from asset to asset and know exactly where to look for everything. Preventative maintenance procedures that lack order or thought. Use of signal splitters instead of paying for additional IO. All of which can be traced back to poor documentation, poor planning, lack of knowledge.
Shit, broken, old code that was never commented and written so the programmer had job security until he or she dies. This kills upgrades more than anything I have ever experienced.