Codesys... and brands

Hi all,

Codesys and Beckhoff, Codesys and Mitsubishi, Codesys and Lenze...

I recently did a project with a C3200 controller from lenze and i700 drives. So I understand that Lenze uses Codesys, but what about Beckhoff and Mitsubishi... Beckhoff has Twincat and Mitsubishi has Worx, what ahve those todo with Codesys ?

Thanks in advance for clearify some things for me ,

Kind regards,
Combo

There's about 200 manufacturers that use Codesys. Some of the bigger players (Beckhoff, Schneider) use their own 'wrapper' around the Codesys IDE. There are advantages and disadvantages to this. Having to pay for it being one.
My preferred controller uses 'pure' Codesys; the IDE is a free download from the 3s Website. Clearly, the price is right.
My controller has the Runtime licence already installed so there's nothing to worry about.
Mitsubishi don't use Codesys. A few manufacturers speak about PLCOpen. My guess is Codesys are fully compliant.
And all 5 IEC61131-3 languages to choose from. There won't be many manufacturers that give (£0.00) you all 5.

And there's no manufacturer tie-in. You can see why it would be so unpopular with the established brands.
Pp

What's your favourite brand @paraffin power?

Hi
Beijer 'X2 control' - buy an hmi, get a plc free
Very capable hmi, too. Their apps guys are helpful and enthusiastic.

Thanks.
I quite like the idea of Codesys, but because they aren't usually seen much out in the wild, it's hard to have a grasp about any issues it may have.

I'll check that one out.

I use Wago, also a wrapper around CoDeSys 3. The language flexibility of IEC 61131/3 works for me, controllers are powerful, flexible and expandable I/O and our local Wago branch office gives good support.

I have only two Turck BL20-PG-EN - used as programmable RFID gateway.
Supports IEC 61131-3 (IL, LD, FDB, SFC, ST)

Beckhoff left Codesys. TwinCat 2 is Codesys 2, but TwinCat 3 is Microsoft Visual Studio.

ELAU EPAS-4 was Codesys 2 and the successor is Schneider PacDrive3 which is Codesys 3 and renamed SoMachineMotion. This is just slightly different from regular old SoMachine which is also Codesys 3 and they have mentioned they plan to combine the two into the same IDE for the next major revision.

B&R has members on the Codesys board and there are similarities between Codesys 3 and Automation Studio 3.x and 4.x, but Automation Studio is not, and has never been Codesys.


PLCopen is a different thing; it's a standardization on how to program servo motion control. Most Codesys platforms include it since the library already exists, but many non-Codesys platforms also have PLCopen available. Unfortunately, proprietary and unavoidable differences in how servo control operates platform to platform means that there can be notable variations, even in the standard functions. It's also way too granular and manual for modern programming. I'm seeing PLCopen fall out of favor quickly with PLC makers and more and more are providing alternatives that handle more of the drudgery automatically (single function block that powers the axis, jogs, homes, resets faults, etc). In PacDrive, you can't even access most of the robotics functions if you use PLCopen, so it was dead on arrival on a platform designed around easy robotics control.

What is maybe more interesting is not how many platforms do or don't use Codesys, but how many platforms us VxWorks as the RTOS. It's one of those unspoken things that a Zero-Day that compromises VxWorks would likely affect more than half of the active PLCs worldwide.

CapinWinky said:

Beckhoff left Codesys. TwinCat 2 is Codesys 2, but TwinCat 3 is Microsoft Visual Studio.

Click to expand...

Correct me if I'm wrong, but for me Twincat seems some unholy combination of Visual studio and Codesys 2, where the IEC 61131-3 languages are still programmed with codesys embedded to visual studio.

CapinWinky said:

It's one of those unspoken things that a Zero-Day that compromises VxWorks would likely affect more than half of the active PLCs worldwide.

Click to expand...

A VxWorks zero day would probably affect half the embedded devices of any type worldwide, not just PLCs.

On the plus side, it's way better than everyone sludging their way through trying to secure their own proprietary thing. Most vendors don't have the resources for it.

On the downside, if there is a goof, wow. It's like the intel CPU stuff happening right now, it basically affects everything.

mk42 said:

A VxWorks zero day would probably affect half the embedded devices of any type worldwide, not just PLCs.

Click to expand...

You are being too conservative... I think it's probably more than that. I mean, even fire detection systems use VxWorks.

I would also risk that a vast majority of shipping uses it too.

cardosocea said:

You are being too conservative... I think it's probably more than that. I mean, even fire detection systems use VxWorks.

I would also risk that a vast majority of shipping uses it too.

Click to expand...

https://en.wikipedia.org/wiki/VxWorks#Notable_uses

I was being pretty broad when i said embedded, but yeah. Its everything from GE CT scans, to Cisco Switches, to SpaceX Dragon.

It almost feels easier to count devices that DON'T use it.

Hietsu said:

... the IEC 61131-3 languages are still programmed with codesys embedded to visual studio.

Click to expand...

I agree. I have used both TwinCAT 2 and 3. It appears that TC3 uses Microsoft Visual Studio as a shell to incorporate what were separate programs in TC2 (System Manager and PLC-Control). They also use it to replace the PLC code editor. Underneath, it likely uses the same CodeSys engine and compiler. Indeed, System Manager appears almost the same in VS, just moved to VS windows and forms. Likely Beckhoff dove deeper in providing C++ coding for the PLC.

Moving to VS gave several advantages. In TC2, you must move back and forth between the 2 programs (build PLC code, link to it in SM then log-in, back to PLC to download code, ...). Most of that happens behind the scenes in TC3. You can also include Windows HMI code (VB, C#) within the same VS "solution", though not necessary and may add confusion.

paraffin power said:

Mitsubishi don't use Codesys. A few manufacturers speak about PLCOpen.
Pp

Click to expand...

I think GX IEC Developer is Codesys V2. Extension of file is .pro and it has that look and syntax..

PLCopen is a different thing; it's a standardization on how to program servo motion control. Most Codesys platforms include it since the library already exists, but many non-Codesys platforms also have PLCopen available. Unfortunately, proprietary and unavoidable differences in how servo control operates platform to platform means that there can be notable variations, even in the standard functions. It's also way too granular and manual for modern programming. I'm seeing PLCopen fall out of favor quickly with PLC makers and more and more are providing alternatives that handle more of the drudgery automatically (single function block that powers the axis, jogs, homes, resets faults, etc). In PacDrive, you can't even access most of the robotics functions if you use PLCopen, so it was dead on arrival on a platform designed around easy robotics control.

What is maybe more interesting is not how many platforms do or don't use Codesys, but how many platforms us VxWorks as the RTOS. It's one of those unspoken things that a Zero-Day that compromises VxWorks would likely affect more than half of the active PLCs worldwide.[/QUOTE]

Actually, PLCOpen is a lot more than motion control. The point of the organization is to work towards standardization across controller platforms. It's a great organization and deserves your support. Probably the two most compliant IDE's are CoDeSys and MultiProg, but others are getting on the bandwagon. Of course the big dogs (Siemens and Rockwell) pay lip service to PLCOpen but have so much legacy in doing things differently I doubt they'll ever change...