When NOT to use a GEVINO

I sell Arduino-compatible PLCs. So take this page for what it is: a list of the cases where I'm telling you to buy from someone else.

I'm writing it because the fastest way to ruin my reputation is for a GEVINO to end up somewhere it shouldn't.

1. Functional safety

If the function falls under your risk assessment — emergency stop, light curtains, muting, two-hand control, guard monitoring — the GEVINO has no place in it.

The GEVINO is CE marked as industrial equipment. It has no functional safety certification: no ISO 13849 or IEC 62061 assessment, no redundant channels, no notified body. Your safety chain needs a dedicated safety relay or a safety PLC.

It can sit in the same cabinet and run all the process logic. Safety is a separate circuit, and it stays separate.

2. Guaranteed determinism

A traditional PLC guarantees you a scan cycle within a stated time. The GEVINO doesn't: it's a C program on a SAMD21, bare metal, no RTOS. The cycle takes as long as the code you write into it.

If you need a maximum time guaranteed by contract, I'm not your supplier.

What you get in exchange is direct control. Critical inputs don't go through the scan: they're hardware interrupts, latency in the microsecond range, independent of whatever the main loop is doing. A short pulse that a scanning PLC would miss, you catch here.

The flip side: timing is your responsibility. A blocking delay() in the loop breaks everything, and no runtime will save you. This product is for people who program, not for people who assemble blocks.

For coordinated axis interpolation, high-dynamic positioning or current loops, buy a motion controller.

3. Specifications that require IEC 61131-3

If the end customer wants to be able to call any maintenance technician and have them open the program in ladder, C++ is a problem even when it works better. That isn't backwardness: it's managing the risk of maintenance ten years out.

Same goes if nobody in the company reads C++. You become dependent on whoever wrote the code — and that someone might be me. That's not a position I want to put you in.

4. Contractually guaranteed supply continuity

I still support products I sold thirty years ago. I say that with pride, but it's what I've done so far, not a guarantee of what happens twenty years from now.

I'm a small operation. If your specification demands guaranteed continuity of supply, the big brands have a structure I don't have.

5. Redundancy and high availability

Hot standby, redundant CPUs, plants where downtime is measured in tens of thousands per hour. Not my field.

6. High I/O count and fieldbus

Hundreds of points, native Profinet or EtherCAT, distributed topologies. The GEVINO is for single machines and compact cabinets.

7. Regulated environments

Pharmaceutical with GAMP validation, food with certified traceability, ATEX. That needs documentation and supplier qualification I can't provide.

And while we're on AI

Plenty of people have tried getting a chatbot to write ladder logic, got poor results, and concluded that AI is useless here. Understandable conclusion, wrong diagnosis.

Language models are weak at ladder and structured text: little public code to train on, a different dialect for every brand, and no way to verify the output without the proprietary environment. Give them the same problem in C and they're far more solid, because C is everywhere.

That doesn't mean AI writes your program. It means it takes the boilerplate off your desk — initialization, protocol parsing, state machines, Modbus — and leaves you the work that matters: understanding the process, deciding the logic, validating it in the field. That part stays yours, and it's the reason you get paid.

Someone who has been programming PLCs for ten years has exactly the skills needed to use this tool well. Too much experience was never the problem.