No-code in manufacturing: automation without programming(smartindustry.com)
smartindustry.com
No-code in manufacturing: automation without programming
https://www.smartindustry.com/blog/smart-industry-connect/no-code-in-manufacturing-automation-without-programming/
63 comments
I worked in this sort of space for awhile. You got it in your last paragraph. Downtime costs money. Not only does downtime cost money, service calls do too. You get a guy who knows exactly how to fix it out on site and he shows up and has the wrong part and he costs 200 bucks an hour. You can burn 4 hours just waiting for a part. We were having a lot of good luck adding some sensors, remote diagnostic, and pre-diagnostic. That way you could schedule a downtime for a part swap out and have the right part on hand. Programming and remote control was near the bottom of that money stack. Like you said most of the stuff is PLC and relay logic. Sometimes you get lucky and there is a decent computer in the middle and you can scan that, but be careful as the 485 line may already be saturated with commands.
In many ways it’s akin to the reason why SLAs don’t mean shit when they’re business to business. Anybody who breaks even in using a tool doesn’t stay in business for long. They use a tool because the tool -all of the tools - plus the labor costs them a dollar for every 10 they can gross. Your $1000 a month service can hold up or straight up lose $50,000 in revenue, so don’t be surprised if I’m not that happy about you offering to cut us a check for $250 when your stuff shit the bed two days before a hard deadline.
We want the money back guarantee because we think the specter of you making no money will motivate you not to fuck us over. Your guarantees mean next to nothing, and the manpower involved in getting and cashing that check might eat most of it up anyway.
We want the money back guarantee because we think the specter of you making no money will motivate you not to fuck us over. Your guarantees mean next to nothing, and the manpower involved in getting and cashing that check might eat most of it up anyway.
Depending on the industry downtime doesn’t only mean widgets aren’t getting built but also the wip widgets we were making have to be thrown out.
> generally coding skill is not particularly lacking
In my experience it is. Sure there are people who can go in and hack some simple code, but they typically know nothing about the clean code style that you need to make millions of lines manageable. They do okay with 500 lines programs where it isn't hard to know the whole, but don't put them on anything more complex
In my experience it is. Sure there are people who can go in and hack some simple code, but they typically know nothing about the clean code style that you need to make millions of lines manageable. They do okay with 500 lines programs where it isn't hard to know the whole, but don't put them on anything more complex
I think this is where standardized DSLs are needed in order to make software an effective and useful tool for nonspecialists. Doing everything in a full-featured programming language is like bringing a fully-loaded aircraft carrier to what is, in most cases, a pocketknife fight. If you only provide a pocketknife, you don't have to worry about accidentally burning down the entire city.
Besides, standardized DSLs are often better suited for static analysis due to the restricted forms of control flow and less esoteric constructions (fewer or no pointers, dynamic allocation, etc).
If only vendors didn't force users into closed, proprietary IDEs which lack many basic syntactic checks, developing for industrial control system would be much more pleasant.
If only vendors didn't force users into closed, proprietary IDEs which lack many basic syntactic checks, developing for industrial control system would be much more pleasant.
But there is absolutely nothing in the manufacturing world that would ever require millions of lines of code. There's a big difference between software development, which they are not doing, and coding, which these no-code solutions seek to help them with.
For reference, I'm currently dealing with a customer whose most complex machine (which automates a job that used to take two people per shift) runs on 128 lines of code.
For reference, I'm currently dealing with a customer whose most complex machine (which automates a job that used to take two people per shift) runs on 128 lines of code.
When you say G-Code is Assembly-like, you just mean superficially right? I would expect G-Code to be interpreted, not assembled.
Saying that it's like assembly is an odd way of phrasing it since a single G code statement can have a huge amount of functionality under the hood. But yes, it's interpreted. In fact, some older machines have very small buffers so you have to "drip feed" them a few lines of G-code at a time.
I work with gcode on a day to day basis. I understand what the parent poster means about it being "assembly like", in that many of the common patterns of handwriting assembly language are employed when hand writing gcode. It has GOTO statements, lots of analogs for push and pop like behavior, and in some cases you are manipulating raw bits to deal with user input. It is interpreted into machine code as well, as is assembly.
OK, that I can see.
Yeah, I say G-code is Assembly-like the same way I'd say a dolphin is fish-like: they resemble eachother in many ways and if you'd never seen one, you kinda get the idea, but they are not related and if you cut them open they are very different.
As a controls engineer who has integrated dozens of automated manufacturing cells, I have to say: none of the salespeople I interact with have buzzword densities this high! As nbzso mentioned, the higher you climb the less oxygen there is...
There's definitely a need for some kind of simplified programming that's understandable at different levels. Simplest is for an operator, then by a maintenance technician, by a line engineer, by a controls engineer at an integrator (like me), and by applications engineers at manufacturers and distributors. The operator needs a minimal number of adjustments - this part number might have a harder material and need to run at a reduced speed, or be highly porous and need more adhesive dispensed. That kind of hour-by-hour adjustment is typically custom-built into an HMI by the controls engineer. The tools themselves need to be debugged by maintenance techs, the robot code on a teach pendant or the ladder logic in a PLC are those languages. Hopefully, the maintenance tech doesn't have to touch the structure of the program, just some of the conditions or values for certain steps. Programs increasingly expose data at certain parts of the cycle to external databases. That's the "4IR" or "Fourth Industrial Revolution" or "Industry 4.0" component, or just a spreadsheet export, depending on your altitude. T Whether that data is analyzed in Excel, an MES dashboard, or a Python script depends on the consumer.
There are DSLs at all levels, none of those people are writing assembly language. But "No code" proponents typically remove too much flexibility to the level of the implementor of the product, far removed from the end user.
There's definitely a need for some kind of simplified programming that's understandable at different levels. Simplest is for an operator, then by a maintenance technician, by a line engineer, by a controls engineer at an integrator (like me), and by applications engineers at manufacturers and distributors. The operator needs a minimal number of adjustments - this part number might have a harder material and need to run at a reduced speed, or be highly porous and need more adhesive dispensed. That kind of hour-by-hour adjustment is typically custom-built into an HMI by the controls engineer. The tools themselves need to be debugged by maintenance techs, the robot code on a teach pendant or the ladder logic in a PLC are those languages. Hopefully, the maintenance tech doesn't have to touch the structure of the program, just some of the conditions or values for certain steps. Programs increasingly expose data at certain parts of the cycle to external databases. That's the "4IR" or "Fourth Industrial Revolution" or "Industry 4.0" component, or just a spreadsheet export, depending on your altitude. T Whether that data is analyzed in Excel, an MES dashboard, or a Python script depends on the consumer.
There are DSLs at all levels, none of those people are writing assembly language. But "No code" proponents typically remove too much flexibility to the level of the implementor of the product, far removed from the end user.
Came here to say the same thing. I've been in automation for a loong time and this article seems like an AI-generated jumble of buzzwords.
Maybe in adjacent fields no code and IoT is a thing but in mainstream manufacturing automation I'm not really encountering it. It feels like we just moved a bit past PLCs and proprietary field busses. The main added value is not normally in rapidly changing SW that's generated by non-programmers.
Maybe in adjacent fields no code and IoT is a thing but in mainstream manufacturing automation I'm not really encountering it. It feels like we just moved a bit past PLCs and proprietary field busses. The main added value is not normally in rapidly changing SW that's generated by non-programmers.
> But "No code" proponents typically remove too much flexibility to the level of the implementor of the product, far removed from the end user.
Not only do they remove flexibility, but they often introduce "magic" that is too difficult to debug when dealing with live industrial systems. It's fairly simple to go through a bunch of iterations with a debugger in a standard programming environment. As soon as your dealing with a sprawling realtime physical system, you can't do that.
Not only do they remove flexibility, but they often introduce "magic" that is too difficult to debug when dealing with live industrial systems. It's fairly simple to go through a bunch of iterations with a debugger in a standard programming environment. As soon as your dealing with a sprawling realtime physical system, you can't do that.
> So, what is no-code? No-code development is perfect for engineers who have zero programming knowledge. It’s based on a visual drag-and-drop user interface, with no hand coding required to reach the end goal. It empowers workers to design solutions they need to overcome the challenges they face every day—without writing a single line of code. In 2019, 84% of enterprises across the US, UK, Canada and Australia had already implemented a low-code development tool or platform to take care of some of their coding needs.
This piece is a fluff piece at best. Looks like a "guest blog" entry to advertise for the writer's company [0]
The problem with no/low code is it mirrors a DSL for whatever problem being solved. Anything more general becomes a programming language.
Maybe my understanding of language is limited? I'd love to be wrong about this.
[0] https://www.emnify.com/
This piece is a fluff piece at best. Looks like a "guest blog" entry to advertise for the writer's company [0]
The problem with no/low code is it mirrors a DSL for whatever problem being solved. Anything more general becomes a programming language.
Maybe my understanding of language is limited? I'd love to be wrong about this.
[0] https://www.emnify.com/
My limited experience with "no/low code" has been that it sacrifices the reuse of logic.
I don't understand how that can possibly substitute for programming, because the reuse and composition of logic is the whole point...isn't it?
It's also the source of complexity, so just making a visual, drag and drop interface isn't going to make development more accessible, I would think. Less, in that it's more cumbersome and expands visually.
My assumption has been that this is an emperor with no clothes that is invariably sold to decision makers who won't use it.
But maybe there's more to it?
I don't understand how that can possibly substitute for programming, because the reuse and composition of logic is the whole point...isn't it?
It's also the source of complexity, so just making a visual, drag and drop interface isn't going to make development more accessible, I would think. Less, in that it's more cumbersome and expands visually.
My assumption has been that this is an emperor with no clothes that is invariably sold to decision makers who won't use it.
But maybe there's more to it?
> The problem with no/low code is it mirrors a DSL for whatever problem being solved. Anything more general becomes a programming language.
Yes! I've explored visually representing functions, and state machines, but it all feels very limiting compared to written language. I think more research could be done in the visual coding area for expressing thought, because I really want coding to look like something out of neon genesis evangelion--but IDK, written language isn't bound spatially. And in written language, it's so easy to express contradictions, which is an important part of developing a system. I think MC Escher is probably the most advanced research we have in the area of visually representing recursion and contradictions lol.
Yes! I've explored visually representing functions, and state machines, but it all feels very limiting compared to written language. I think more research could be done in the visual coding area for expressing thought, because I really want coding to look like something out of neon genesis evangelion--but IDK, written language isn't bound spatially. And in written language, it's so easy to express contradictions, which is an important part of developing a system. I think MC Escher is probably the most advanced research we have in the area of visually representing recursion and contradictions lol.
> The problem with no/low code is it mirrors a DSL for whatever problem being solved.
This is the entire advantage too. If you read this like a hard constraint, your new job is to simply make sure you develop a high-quality model of the problem domain. The rest could be put on the business owners, especially if you can teach them a little bit of SQL (the world's most popular DSL).
This is the entire advantage too. If you read this like a hard constraint, your new job is to simply make sure you develop a high-quality model of the problem domain. The rest could be put on the business owners, especially if you can teach them a little bit of SQL (the world's most popular DSL).
SQL: one of the original no-coding means of coding. I wonder how many people in the world are paid specifically to write SQL, fix other people's SQL and deal with all the other issues?
So there's really two problems that are being conflated in the phrase "no code":
1. We need a richer library of standardized DSLs for various real-world environments, where the power of a full PL is perhaps too dangerous without excessive training.
2. The method of specifying algorithms in plain text (i.e. "code") is not intuitive or unapproachable for large numbers of people who could otherwise benefit greatly from the ability to "program" the tools they use.
1. We need a richer library of standardized DSLs for various real-world environments, where the power of a full PL is perhaps too dangerous without excessive training.
2. The method of specifying algorithms in plain text (i.e. "code") is not intuitive or unapproachable for large numbers of people who could otherwise benefit greatly from the ability to "program" the tools they use.
#2 is the same as arguing that anyone can be a great novel writer because what prevents people from doing that is writing words. So instead of writing, great novels can be created by dragging and dropping story elements, plot points, and characters!
#1 is a different but similar problem. "If only language itself was simpler, people would have an easier time writing novels."
#1 is a different but similar problem. "If only language itself was simpler, people would have an easier time writing novels."
My line of thinking on this is “what makes Excel have the combination of simplicity to start and ability/power to scale to fairly complicated workbooks and how to bring that to other fields, including manufacturing?”
We could do a lot worse than excel in a lot of areas I think.
We could do a lot worse than excel in a lot of areas I think.
Excel VBA and Power Query are regular programming languages.
Nothing in particular has been solved by Excel, it's just that the languages that are built in are disdained by software engineers so people assume there's something special about them. It's cultural. You can write a Lisp in VBA if you want.
Microsoft's attempt at low/no code appears to be Power Automate, and it's awful (imo).
Nothing in particular has been solved by Excel, it's just that the languages that are built in are disdained by software engineers so people assume there's something special about them. It's cultural. You can write a Lisp in VBA if you want.
Microsoft's attempt at low/no code appears to be Power Automate, and it's awful (imo).
I’d wager that 99% of all excel workbooks in the world contain no VBA.
Excel’s market power is in what you can do in the formulas, interactive exploration, and incremental progress not in the (fairly awful dev-experience) VBA.
Excel’s market power is in what you can do in the formulas, interactive exploration, and incremental progress not in the (fairly awful dev-experience) VBA.
That's true, but the point is, they haven't created anything that bridges the two worlds. They are just there, in coexistence.
Well, then again, I also think you are also falling into the trap of underestimating the amount of VBA code, and businesses built on it, because of your cultural disdain for it.
Well, then again, I also think you are also falling into the trap of underestimating the amount of VBA code, and businesses built on it, because of your cultural disdain for it.
I don’t have any disdain for Excel or VBA. It’s clearly hugely useful, successful, and valuable.
I’ve written some VBA; the DX is terrible, but I have massive respect for what they’ve accomplished and I readily reach for it when it’s the right tool. I wrote some powershell for a manufacturing site a few weeks ago. Didn’t enjoy doing it, but it was the right horse for that course.
I’ve written some VBA; the DX is terrible, but I have massive respect for what they’ve accomplished and I readily reach for it when it’s the right tool. I wrote some powershell for a manufacturing site a few weeks ago. Didn’t enjoy doing it, but it was the right horse for that course.
It's either a very simple DSL, or it is coding.
Complete with debugging and maintenance and all of the other things that make "coding" hard.
Complete with debugging and maintenance and all of the other things that make "coding" hard.
I wish people would stop claiming that drag and drop program creation is not programming. It is simply a different style of programming using a different language.
From Wikipedia: "Computer programming is the process of designing and building an executable computer program to accomplish a specific computing result or to perform a specific task."
See https://en.wikipedia.org/wiki/Computer_programming.
The same claims used to be made regarding Programmable Logic Controllers (PLCs), despite the word programming being part of the name.
From Wikipedia: "Computer programming is the process of designing and building an executable computer program to accomplish a specific computing result or to perform a specific task."
See https://en.wikipedia.org/wiki/Computer_programming.
The same claims used to be made regarding Programmable Logic Controllers (PLCs), despite the word programming being part of the name.
Outside of tech, I think coding means green text on a black background--but I think of it more generally, describing a process that you want something/someone else to run... a cooking recipe for someone to follow, it's CODE! So yeah, to that end, visual programming is still coding. AI that generates code, well, you still have to tell the AI what to do, still coding--on that tangent, if AI code generation ever is perfected, I'd rather work in that language, and not even look at the output like assembly.
I really want visual programming to succeed, but there's something fundamentally harder with it. I'm starting to think written language can't be beat for expressing thought. Visual programming is probably a great introduction to computer programming for people to quickly automate simple tasks, but I rest assured that as soon as they want to describe any complex process, they're going to fall into written language like the rest of us--or do lots of copying and pasting and create a mess. To write is to think, I think.
I really want visual programming to succeed, but there's something fundamentally harder with it. I'm starting to think written language can't be beat for expressing thought. Visual programming is probably a great introduction to computer programming for people to quickly automate simple tasks, but I rest assured that as soon as they want to describe any complex process, they're going to fall into written language like the rest of us--or do lots of copying and pasting and create a mess. To write is to think, I think.
There's a time and place for visuals. Geometry is a form of visual math, but how do you "visualize" models that go beyond the 3rd dimension...?
For most people, trigonometry is enough to build stuff with. And for many ideas, a diagram communicates better than talking or writing it into an excel sheet.
For most people, trigonometry is enough to build stuff with. And for many ideas, a diagram communicates better than talking or writing it into an excel sheet.
I don't really care if it's called programming or not but whenever I've inherited LabView or similar type of project I spent more time trying to figure out what the "programmer" tried to do than it would take to rewrite from scratch in a traditional language/environment.
If you gave them a program written in C++, it would probably be faster for them to recreate it in Labview than to figure your version out. (Heck, if you gave it to a python programmer, they might choose to replace-implement it in python rather than figure out your C++.)
I often claim software is a new form of literacy. And I see no-code as the equivalent of cutting up all the frames from marvel comics and tippexing out the speech bubbles, then handing them to some illiterate and saying "hey, you can write your own story now !"
It's not how we (as a society) need to handle this.
Edit: i.e. that is not empowering the illiterate.
It's not how we (as a society) need to handle this.
Edit: i.e. that is not empowering the illiterate.
I think the issue with your analogy is that no-code programming is more like cutting up all of the idioms and narrative elements (in abstract) from Marvel comics and offering them to an illiterate and saying "Tell me a story using these parts". Ultimately, storytelling is composed of tropes. Every once in a while a breakthrough is made in aesthetic/narrative style, but that's just a new feature for a no-code platform. Not everyone needs to be writing bleeding edge or avant-garde software – a lot of people just need simple and reliable internal tools.
Sorta like Dinosaur Comics with user-generated content? I like it!
https://www.qwantz.com
https://www.qwantz.com
I see a different future.
As a side-effect of pushing "automation" agenda corporations will not have needed workforce to accomplish the task.
The marketing delusions and wishful thinking are popular methods of self-destruction. Sadly in the corporate world, the more you climb the less oxygen you get. And with lack of oxygen human brain is prone to malfunction.
You can have some form of automation, but the need of competent programmers will not vanish into the thin air.
>Is PHP worth learning in 2021?
The first google result:
PHP is an open-source programming language that is completely free, and because it supports all the main browsers, it is highly scalable. ... PHP is not dying and is definitely worth learning in 2021 and beyond. There are still thousands of jobs available for new PHP programmers
https://www.google.com/search?q=Is+PHP+worth+learning+in+202...
As a side-effect of pushing "automation" agenda corporations will not have needed workforce to accomplish the task.
The marketing delusions and wishful thinking are popular methods of self-destruction. Sadly in the corporate world, the more you climb the less oxygen you get. And with lack of oxygen human brain is prone to malfunction.
You can have some form of automation, but the need of competent programmers will not vanish into the thin air.
>Is PHP worth learning in 2021?
The first google result:
PHP is an open-source programming language that is completely free, and because it supports all the main browsers, it is highly scalable. ... PHP is not dying and is definitely worth learning in 2021 and beyond. There are still thousands of jobs available for new PHP programmers
https://www.google.com/search?q=Is+PHP+worth+learning+in+202...
>Is PHP worth learning in 2021?
I’m calling that out as a straw man. Who uses PHP to run gear / robots?
I’m calling that out as a straw man. Who uses PHP to run gear / robots?
This is an example of old technology (programming language) pronounced dead numerous times.
I can give another example: COBOL. https://www.makeuseof.com/what-is-cobol/
The idea behind this is that marketing and agenda driven "visions" often paint wrong picture towards an ideal future. And reality always finds a way to strike back.
I can give another example: COBOL. https://www.makeuseof.com/what-is-cobol/
The idea behind this is that marketing and agenda driven "visions" often paint wrong picture towards an ideal future. And reality always finds a way to strike back.
I code in PHP very frequently (thanks to Laravel), I’m not declaring it dead by any stretch of the imagination. I just don’t think it’s in daily use on the assembly line. It’s all PLC. And where you do see a Raspberry Pi on the floor, it’s Python, C/C++ or C# before it’s PHP.
As a consultant in the business automation and data space, the promised "paradigm-shift" is sort-of accurate but a little too optimistic in what the author believes the implications are.
No-code/low-code has been a game changer in many ways for businesses. It lets people dip their toes into improving their efficiency and productivity with low-hanging automations and simple apps. These things can have huge payoffs. And if you stick within that realm, it actually is a paradigm-shift to be able to build solutions as a non-tech person.
But there's always a point where you:
1. need more complex no-code/low-code solutions to get big pay-offs 2. have a mess of so many no-code/low-code solutions that they end up causing tons of maintenance/issues and you have trouble getting all your separate solutions to play nicely together
You end up spending a lot of money to get someone who is very advanced with those no-code/low-code tools (which usually ends up with code solutions inside of those tools), or end up building completely custom solutions anyway.
Also, there are a lot of nuances in what could be considered no/low-code. This article isn't too clear on which types of applications are considered no/low-code, and throws out everything from cellular-IoT infrastructure to MES. Is something like Tableau low-code? Or are we talking more about the Zapier kind of tools? Both of those examples have giant roadblocks once you get to a certain point, where you need some type of dev/architect knowledge to really get the most use out of the tools.
No-code/low-code has been a game changer in many ways for businesses. It lets people dip their toes into improving their efficiency and productivity with low-hanging automations and simple apps. These things can have huge payoffs. And if you stick within that realm, it actually is a paradigm-shift to be able to build solutions as a non-tech person.
But there's always a point where you:
1. need more complex no-code/low-code solutions to get big pay-offs 2. have a mess of so many no-code/low-code solutions that they end up causing tons of maintenance/issues and you have trouble getting all your separate solutions to play nicely together
You end up spending a lot of money to get someone who is very advanced with those no-code/low-code tools (which usually ends up with code solutions inside of those tools), or end up building completely custom solutions anyway.
Also, there are a lot of nuances in what could be considered no/low-code. This article isn't too clear on which types of applications are considered no/low-code, and throws out everything from cellular-IoT infrastructure to MES. Is something like Tableau low-code? Or are we talking more about the Zapier kind of tools? Both of those examples have giant roadblocks once you get to a certain point, where you need some type of dev/architect knowledge to really get the most use out of the tools.
Is no-code the new trend because full automation with AI failed? I wonder if we're trying to realise what jobs actually require skilled labour.
Dare I say its because AI succeeded. AI is no longer a barrier to entry, there's plenty of off the shelf libraries and python examples out there to get you going.
The result is, that a lot of under the hood intelligence is automated. And the inputs, outputs and process selection instead of process design are all that's left to hype up as a differentiator in an ever increasingly commoditized market.
The result is, that a lot of under the hood intelligence is automated. And the inputs, outputs and process selection instead of process design are all that's left to hype up as a differentiator in an ever increasingly commoditized market.
[deleted]
It seems like every few years, we get to experience a wave of 'no code' solutions with varying degrees of success. LiveCode isn't too bad, but there is still some code there. Which bring me to my next point, the way it is described, this solution still appears to be coding... under guise of moving things around in GUI. Don't complex programs have the same kind of flow at the very outset of the design process?
I dunno. Maybe its time to get coffee. It is being a long day.
I dunno. Maybe its time to get coffee. It is being a long day.
Yeah. "No code" is basically just a DSL with a visual (i.e. not just text) encoding.
The fundamental problem with no-code/low-code products is that they are a solution to the wrong problem. To an outsider, code is basically indecipherable. Just like weird math symbols, bizarre physics equations, scientific jargon, etc.
Because they don't know how to read code (or substitute in any of the other examples I gave), the outsider assumes that that's the hard part: "If the code/jargon/equation was simply in plain English, anybody could program/do science/understand math".
But they're wrong. Anybody who spends enough time to pick up the actual underlying skill (whether it be programming, mathematics, or science) will trivially pick up the language of the trade, which, on the whole, exists because it expresses complicated ideas in a convenient way.
The hard part of programming is solving the actual problems, not expressing those solutions in code. Likewise, the hard part of electrical engineering isn't reading circuit diagrams, or the hard part of being an author is knowing English. Thus, if you want to make programming your system easier, you don't throw out the idea of code. You solve as many of the hard problems as you can, and then supply those solutions as a library.
Because they don't know how to read code (or substitute in any of the other examples I gave), the outsider assumes that that's the hard part: "If the code/jargon/equation was simply in plain English, anybody could program/do science/understand math".
But they're wrong. Anybody who spends enough time to pick up the actual underlying skill (whether it be programming, mathematics, or science) will trivially pick up the language of the trade, which, on the whole, exists because it expresses complicated ideas in a convenient way.
The hard part of programming is solving the actual problems, not expressing those solutions in code. Likewise, the hard part of electrical engineering isn't reading circuit diagrams, or the hard part of being an author is knowing English. Thus, if you want to make programming your system easier, you don't throw out the idea of code. You solve as many of the hard problems as you can, and then supply those solutions as a library.
I work for a "no-code" app (Kalipso Studio) with focus in logistics and shop floor applications. But the programmer needs to have some basic programming skills and at a little bit of SQL. This guy is a bit exaggerated. We have many costumers using this manly to interface PLC that now come with Webservices or have other software to convert the protocol, etc... We have companies using this to control robots, but the movements was natively programing. Now they just use our software to manage the robot, get data/statistics, and load different parameters. I don't think the "no-code" is for people with less skills. Our clients buy this because they what to be more productive, or they can't or don't want to buy the solution from a external company. Governments and military also don't like external companies, so they buy to use internally like big companies. And apps in the industries are always changing, so they need to be fast to adapt. They don't need a very fancy interface, most of them will never be published, they are not building a Tiktok app.
The site is unusable/unreadable on mobile. So many ads.
Get an adblocker - with ublock on desktop I can see literally zero ads on this site (except the sharebar at the end which, honestly, is rather unobtrusively placed)
With a title like that, I thought about mechanical engineering. Humanity built machines to "automatically" perform tasks for the last 100+ years. Factories seem to always aspire toward automation at any technological level, even if fully mechanical.
Whenever I see no-code in relation to manufacturing automation, only one piece of software comes to mind and it's LabVIEW.
I have nothing nice to say about LabVIEW. It's the very reason I changed my career from electrical to software engineering.
I have nothing nice to say about LabVIEW. It's the very reason I changed my career from electrical to software engineering.
What you didn't like about LabVIEW?
With LabVIEW, I found the inability to use the git version control system extremely limiting, along with vendor lock-in/licensing and difficulty debugging VIs.
Programming graphically has its merits, but I think for large organizations it ultimately becomes a huge headache when employed in production environments and that they would be better served by a text based programming language such as python. In my opinion, it works far better in lab environments and for rapid prototyping.
Programming graphically has its merits, but I think for large organizations it ultimately becomes a huge headache when employed in production environments and that they would be better served by a text based programming language such as python. In my opinion, it works far better in lab environments and for rapid prototyping.
I can see no code, ie visual coding succeeding but it has to address a huge deficit and that's debugging.
Coding is really not a limiting factor in manufacturing automation. For decades everything has been built around being controlled by first relay logic and then PLCs, which implement multiple languages like ladder-logic which are basically already drag and drop. Most sensors are simple - generally they provide a boolean on/off signal, and occasionally there's an analogue output which is pretty easy to interpret. Physically placing and wiring the sensors correctly is the hard bit, not interpreting the data. There are more advanced systems, like computer vision, but they all already have user interfaces which allow you to interact with them without coding. In fact it's actually a real pain in the ass that in most cases there is no coding option, and thus everything has its own proprietary and arcane method of operation and its unreasonably difficult to get things to talk to each other.
Further, generally coding skill is not particularly lacking. Assembly-like languages such as G-Code are widely used by machines and many tradesmen know enough to hand edit at least simple programs, and the engineers on staff are generally comfortable with more advanced programming. While they're a far cry from software developers, but it's sufficient for the relatively simple cases that a no-code solution might be suitable for.
The main issue for automation in manufacturing is not versatility but reliability. A few hours of downtime can cost tens of thousands of dollars, and a machine crash might easily cost 8 figures, to say nothing of the potential for injury or even death. Whatever difficulty there is in coding for manufacturing environments is in structuring these programs such that they are consistently accurate and fail safe. Personally, I don't find anything that makes it easier for someone to tell a machine to do something stupid particularly appealing.