Comment by jjk166 | Hacker News Reader

Comment by jjk166 | Hacker News Reader

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.

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.

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

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.

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.

The problem is many of them think that they can handle larger problems

Let them think that. As the GP poster said, it is unlikely they will ever be asked to work on a bigger program.

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.

Reply on news.ycombinator.com