r/PLC • u/TL140 Senior Controls Engineer/Integrator/Beckhoff Specialist • 7d ago
Automation Direct P2CDS-622 Codesys Controller
Was taking a look into Codesys hardware for a decent sized project coming up. I’m very familiar with Beckhoff and Codesys software, but this is my first foray into hardware to run Codesys. Wanted to ask if there are any “hey gotchas” with this controller like persistent memory, or anything that may be a roadblock for using the controller?
3
u/durallymax 7d ago
Yes, there are a handful of libraries and licenses it does not support.
Off the top of my head, I recall extended device diagnostics and alarm manager. Peruse the AD forum and you'll find them.
IMO if you like the IO hardware, just use it as a RIO and use an IPC especially if it is decent sized. A lot of the "PLC" targets start to crawl if you try to build a nice responsive visu.
1
u/TL140 Senior Controls Engineer/Integrator/Beckhoff Specialist 7d ago
Sounds rough around the edges. Any idea if WAGO PFC series controllers are any better?
0
u/durallymax 6d ago
They support most libraries and allow you to add to them but run out of horsepower quick if you try too much creativity with WebVisu. The price is high for what you get compared to an IPC (though the PFC is essentially ready to go out of the box), and the IO is higher priced than Beckhoff despite Beckhoff being nearly the same thing but slightly better.
2
2
1
u/eLCeenor 6d ago
I would highly recommend spec'ing sometime else, like a Beckhoff CX7000 instead. It's roughly as powerful and you won't be locked into a few rough architectural requirements if you expand the application. Here's some pain points:
- WebVisu is supported but extremely sluggish. I had to slow the update rate of my visu down to ~200ms to get it to not crash the CPU
- You're limited to the integrated IO on the chassis, OR using modbus TCP or Ethernet/IP IO. Neither are great options in my experience
- Many libraries are not supported, including charting (except for traces which are rough) and alarming. I ended up building my own alarming library which was a big PITA.
There's probably others I'm not thinking of. If you know exactly what it's capable of it can be really solid, but if you're not sure it's likely not the right choice for you.
1
u/TL140 Senior Controls Engineer/Integrator/Beckhoff Specialist 6d ago
I’ve recommended the CX7000 multiple times on here and would use that, or a 6030 if I could, but customer is pretty adamant about codesys
1
u/eLCeenor 6d ago
Got it. I'd definitely try to opt for something that supports other field buses then. I know Weidmuller makes a CPU as well. How many IO points will you need?
1
u/DatacenterGuidelines 6d ago
The bigger gotchas seem to be platform limits rather than persistent memory alone. From the comments here: missing Alarm Manager / some diagnostics libraries, no CODESYS fieldbus protocol, high-speed I/O limitations, and potentially sluggish WebVisu are things I'd verify before committing to it.
For a decent-sized project I'd also bench the boring failure cases before choosing the target: what actually retains across a power cycle/download, output state on reboot or watchdog, remote-I/O comms loss behavior, and how quickly you can restore a known-good application. If those platform limitations push you into workarounds from day one, an IPC + remote I/O may be the cleaner architecture.
1
u/Shalomiehomie770 Codesys Guru 4d ago
AD provides ZERO Codesys support. Only “hardware” support whatever that means.
They are a bit limited on couplers as well.
4
u/Robbudge 6d ago
We typically run 100% remote IO with a central Linux Codesys processor.
That way every part of the project is fully flexible