[HN Gopher] No-code in manufacturing: automation without program...
___________________________________________________________________
No-code in manufacturing: automation without programming
Author : stelza26
Score : 57 points
Date : 2021-10-07 16:25 UTC (6 hours ago)
(HTM) web link (www.smartindustry.com)
(TXT) w3m dump (www.smartindustry.com)
| lifeisstillgood wrote:
| 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.
| drewcoo wrote:
| Sorta like Dinosaur Comics with user-generated content? I like
| it!
|
| https://www.qwantz.com
| WFHRenaissance wrote:
| 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.
| LeifCarrotson wrote:
| 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.
| zwieback wrote:
| 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.
| craftinator wrote:
| > 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.
| dsaavy wrote:
| 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.
| A4ET8a8uTh0 wrote:
| 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.
| jkhdigital wrote:
| Yeah. "No code" is basically just a DSL with a visual (i.e. not
| just text) encoding.
| tediousdemise wrote:
| 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.
| ngrilly wrote:
| What you didn't like about LabVIEW?
| tediousdemise wrote:
| 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.
| throwme159 wrote:
| The site is unusable/unreadable on mobile. So many ads.
| munk-a wrote:
| 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)
| all2 wrote:
| > 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/
| jkhdigital wrote:
| 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.
| wvenable wrote:
| #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."
| sokoloff wrote:
| 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.
| perl4ever wrote:
| 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).
| sokoloff wrote:
| 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.
| perl4ever wrote:
| 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.
| sokoloff wrote:
| 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.
| bob1029 wrote:
| > 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).
| mcguire wrote:
| 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?
| perl4ever wrote:
| 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?
| mcguire wrote:
| 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.
| munro wrote:
| > 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.
| jjk166 wrote:
| As someone who does manufacturing automation for a living, I
| don't think this person has any experience in a manufacturing
| environment.
|
| 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.
| bluGill wrote:
| > 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
| jjk166 wrote:
| 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.
| jkhdigital wrote:
| 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.
| edwcross wrote:
| 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.
| speedybird wrote:
| When you say G-Code is Assembly-like, you just mean
| superficially right? I would expect G-Code to be interpreted,
| not assembled.
| HeyLaughingBoy wrote:
| 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.
| craftinator wrote:
| 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.
| HeyLaughingBoy wrote:
| OK, that I can see.
| sumtechguy wrote:
| 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.
| hinkley wrote:
| 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.
| mc32 wrote:
| 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.
| helltone wrote:
| 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.
| drewcoo wrote:
| No, it's the trend because it claims to make everything simple
| while pushing all of the burden back onto the customer. Did I
| say the quiet part?
| TeMPOraL wrote:
| > _Did I say the quiet part?_
|
| No, you didn't.
|
| The quiet part is "as a Service".
| Fordec wrote:
| 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.
| nbzso wrote:
| 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...
| CodeWriter23 wrote:
| >Is PHP worth learning in 2021?
|
| I'm calling that out as a straw man. Who uses PHP to run gear /
| robots?
| nbzso wrote:
| 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.
| adflux wrote:
| Php supports browsers?
| BoxOfRain wrote:
| Can you imagine? The evil twin of JavaScript on the server.
| munk-a wrote:
| As a PHP programmer I'm offended that you would in imply
| any similarities between a language that actually has
| proper objects and JS.
| jagged-chisel wrote:
| 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.
| kwhitefoot wrote:
| 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.
| munro wrote:
| 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.
| kibbleble wrote:
| 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.
| zwieback wrote:
| 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.
| sokoloff wrote:
| 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++.)
| [deleted]
___________________________________________________________________
(page generated 2021-10-07 23:01 UTC)