peterabbitcook

Would it be confusing if Simantic added support the Siemens Simatic S7-1500 PLC?

Probably because I tend to work more on the backend side of things (and a vague memory of a gumball machine example in my old “Design Patterns” textbook), I’m fascinated by the statemachines that are implied behind the scenes of these widgets.

That’s a tough question. If your PLC is on an airgapped LAN, admin/admin is not great security hygiene but you’ve reduced most of the risk by airgapping.

On my project the service I wrote was doing bidirectional communication with the PLC over OPCUA. The server running this pod was connected to the internet, so it was critical to have proper TLS for the OPCUA client/server. Rotating LetsEncrypt certs on the system every 45 days is a lot of toil, but using a self-signed cert that expires in 2040 from some dev laptop doesn’t pass muster in most organizations either.

That’s just the OPCUA path.. In these projects You also typically see WinCC HMIs that can talk to the PLC from anywhere on the network without TLS. And also SIMATIC Web Server pages - minimally secured by default, and the amount of info you can grok about the system in Chrome Dev Tools is troubling.

A couple years ago I worked on a service that had to communicate with a Siemens S7-1500 PLC. Based on my experience with that project, none of what I’ve read recently about unsecured industrial PLCs is surprising.

I opened Siemens TIA Portal and PLCSIM for the first time and thought “wow, I didn’t think the Windows 95 GUI library was still supported.” None of the PLC contractors we had hired knew how to enable TLS on the thing (user/pass eg admin/admin was their usual). Anecdote: I once spent hours reading the docs and clicking around trying to get it to accept an SSL certificate signed by a real CA and it wouldn’t go, but it accepted one I self-signed in openssl.

In all fairness, the people who are experts in the field of Siemens PLC programming are usually mechanical-ish engineers and security is not in their skill set or on their mind.

What are your feelings about using initContainers and wait-for-it to skirt the thundering-herd problem?

It made me think of the “step on all the colored tiles without crossing your path” puzzles in Links Awakening!

I wonder how the optimal path changes if turns are penalized as well as steps - in real life turning a lawnmower takes a lot more effort than moving the same spot twice in a straight line.

So under most brewing conditions a nonzero amount of this microbe survive, but that count is 3 orders of magnitude lower what might be termed a “therapeutic dose?”

What even is a good experimental design for probiotic tea? Brew -> agitate in hydrochloric acid & digestive enzymes for X minutes -> mix with billions of existing gut microbes (that may kill this microbe or out-compete it for resources) and incubate at body temperature -> count the number of new colonies of this particular microbe?

Though I guess using @decorator semantics would make it look a lot like python-numba syntax

I think I’m a little skeptical.

#pragma is a real keyword in C but # is just a comment in python - why not use a pythonic @decorator?

Vendoring a library like this into an app seems like a lot more toil than just writing the native multiprocessing python code, or using something built for number crunching like arrayfire or numpy

Where to stop is a pretty fuzzy question I suppose.

In my world, I think the worst possible outcome would be a java.util.json library that does 50-95% of what I currently do with GSON or Jackson. In that scenario I still need an external dependency, and I can either ignore java.util.json or turn a codebase into an error-prone mix of both.

Maybe a good set of design considerations for java.util.json would be “what does this API need to run a CRUD app written in modern java?” Parse requests from the web, send responses to the web, and serialize/deserialize data from X database (e.g. if noSQL or jsonb). In my head “in modern java” would mean that JSON is converted to records at application boundaries

Fick’s Law. The rate of absorption is proportional to the concentration gradient.

Reading this gives me considerable pause - I can’t think of many classes within the codebase I work on that don’t have @Slf4j at the top…

Since there wasn’t a link to the source code in that post, can you help me understand this - for the SLF4J baseline is your logger impl a console appender, a file appender, or a network service like an OTel collector? Does any of that matter for GC context?

In the Java-verse it’s also do-able with Guice. I’ve tried it with Dagger but bailed (square peg / round hole).

I think I prefer Springboot AOP, especially with SpEL.

The term “cross cutting concerns” is thrown around a lot when discussing AOP. Took me a while to appreciate just how powerful it is in this context - sprinkle an AOP annotation here or there to avoid massive refactors in a large codebase, or avoid rewriting classes in a way that makes your classes themselves “cross cut concerns.”

I’ve dealt with a question that rhymes with this.

Sonarqube or CodeQL reports might tell me what percentage of a repo is duplicated code, and a large percentage of that is in src/test/java

I find that a lot of the time this is not just some flippant observation but a clue that I should be using a mechanism like @ParameterizedTest instead of @Test, so I rewrite those tests in a way that makes them easier to set-up, define parameters/constraints, inputs, and outputs. Sometimes it does get a little convoluted as you either use a lot of naked Arguments.of() or define test-class-scoped nested records to encapsulate test parameters, inputs, expected outputs, etc.

So it’s not UL listed?

Do you need the 15V input to torch the capacitors and run the relays? Could I use a 5V USB ESP32 dev board instead, and just put a boost circuit or MOSFET on the relay load side for the explosion circuit when it needs to go off, or are there other components that need the higher voltage?