Hey all. I've got a background in industrial protocol work (EtherNet/IP, Modbus, edge historians) and I keep running into the same gap. There's no native IEC 104 client driver for Ignition. Right now the answer is to bolt on Kepware, and nobody loves paying for the middleman just to talk to a substation.
I'm building a native IEC 60870-5-104 module with full APCI/ASDU handling, interrogation, and time sync, running straight into the Gateway. No external server to license.
Before I go heads down, I want to make sure I'm building what people actually need. So two questions for you all.
First, if you've needed IEC 104 in Ignition, what forced your hand, and what did you end up doing instead?
Second, I'm opening a small paid beta at $495 per gateway (it'll be $695 at release). Beta folks get direct input on features and priority support. If that's interesting, reply here or send me a message.
Thanks, curious to hear how common this pain actually is.
@christofer.dutz has also got most of this built in his tools. There has been a lot of requests in the past.
The biggest part of this is that if this is an AI project, it’s going to lose. When it comes to drivers, people want thoroughly developed drivers from companies that fully understand the medium and the context. Nobody wants to pay for someone else’s prompt slop.
We're about to start the field testing of that one in the next weeks working nicely on my bench... Let's see if it survives the field (I'm not really worried )
Funny, we may go from years of IEC 104 "drought" to having multiple options soon.
Curious who has built their implementations from a purchased spec vs who has built off publicly available information and implementations, and whether that will make a difference.
I guess as with everything with AI, a senior engineer with deep protocol and engineering skills using Ai can achieve miracles. A junior just vibe-coding is a route aiming to catastrophe (we're especially seeing this in the plc4x prs)
Right now there seems to be two trains of development, one is AI driven the other is developer driven. The developers might be using AI, but there is actual knowledge backing the choices and strategies they use. The AI driven train normally isn’t able to be maintained using anything but AI.
If a feature or product looks, functions, and performs as required, but is developed by and can only be maintained using AI - that's a problem for the user why?
A year from now, at ICC, let's look back at this. I bet by then debating whether AI should be part of writing and maintaining software will look as inane as debating whether gravity should be part of structural engineering.
If you're right, I'll buy you a beer. If I'm right, sounds like I might be getting drunk.
My experience thus far is that our clients still want the human to be a source of technical expertise, rather relying on the human to be an AI expert and AI to be the technical expert.
Not saying you can't work with AI, I think that's already a given. But more that credibility is still dependent on the human holding some sort of experience and expertise. Which I think is where we see the most successful AI assisted efforts.
to be clear, I'm not proposing that you outsource all the expertise to the AI.
What I am saying, though, is that AI writing all the code, and AI being required to maintain the code, will become the norm. That doesn't mean the expertise, the requirements, the validation criteria, etc., was also outsourced to the AI.
Humans writing code, and relatively soon reading/reviewing code, is not the future of software engineering. Not saying that will happen industry-wide, and certainly not industry-wide within a year, but it's the inevitable future.
The job of a software engineer is no longer to build the car - it's to build the factory or assembly line that builds the car. It certainly helps if you know how cars work, though.
“This harvester is neat, but I’m still going to pick corn by hand on my farm.” Some guy in 1931 who quickly became irrelevant.
The difference is that you currently can’t own a cutting-edge AI platform in the same way you can own a cutting-edge harvester; you can only rent/timeshare it. IMO this is what we should all be concerned about.
working nicely on my bench... Let's see if it survives the field (I'm not really worried 
)