Beckhoff (codesys) to Mitsibushi Program Conversion

_Dock_

Member
Join Date
Sep 2015
Location
KY
Posts
508
Does anyone have any experience with converting a Beckhoff (codesys) program to a mitisbushi program? Excluding IO of course.

Are both on the same page with IEC that this would work, or would it be a huge headache? The existing beckhoff program is exclusively structured text.

We dont currently own ant Mitusi programming software so I cant really test and would like some insight before I tell anyone its possible or not.

Thoughts?
 
It would be all brand new hardware so I would assume Gxworks3. Basically customer has asked us to manufacture one of our systems but with Mitsubishi plc and servos.
 
I think it would possible to add the twincat3 (I hope) blocks to a library which could then be used in GX IEC. I have done that between Codesys vanilla and Ecostruxure machine expert

I will do some testing tomorrow between twincat3 and Ecostruxure.
That would allow you to use the function blocks in a project as black boxes and edit them in the library if need be. If they are structured text then they of course be copied but I am not sure that ladder rungs can be copied from library to development environment.
 
GXIEC is dead in the water, this was superseded by GXWorks so not worth bothering with, conversion from GXIEC to GXWorks can be a little problematic.
I have little experience with Codesys & if it's IEC compliant there will be many similarities however, I think it's coding line by line unless it's ST.
Just a couple of other pointers:
Mitsubishi although you can use tag based variables, these are allocated at compile time into ranges of actual addresses.
for example: you create a float tag called My_Float, and do not give it an actual address then when it is compiled it gives it an actual address for example D900 (with it being a float it actually takes up two words so D900 & D901). the problem is as the actual address is determined at compile time you cannot access it from an HMI.
So for local or global variables that you do not need to access then there is no need to give it an actual physical address, however, any that an HMI needs to read/write do need to have actual addresses, Mitsubishi currently does not communicate using tags only actual addresses.
So for example (depending on PLC).
Internal memory bits are "M", M0 to Mxxxx (note the GXWorks IDE allocates say M900 to Mxxxx for temps or compile time allocation) so if giving actual addresses then use the range below say 8000 (The range for the compile time is configurable in the IDE settings).
The same goes for the "D" memories, these go from D0 to DXXX, however, again the upper i.e. D900 are allocated for compile time., also the "D" words can be set to retentive by configuration as standard it is like D512 to Dxxx. again set in the PLC parameters. There are a host of other variables like "L", "R" "B" etc.
Note that word type memories are 16 bit so using doubles (long int), floats (reals) take up more than one register so for example there are 32 & 64 bit type floats these take up two or four words respectively so if coding and allocating actual addresses then bear this in mind if D24 is a single precision float then it uses D24 & D25 if double precision then it uses D24,D25,D26,D27.
The reason for this is backward compatibility with GXDeveloper. I have no doubt that future platforms will use symbol based tags (variables).
One other thing to be aware of, uploading from PLC to disk will not re-construct the symbolic code i.e. graphical representation unless this has been downloaded as part of the project, so loosing your source code means it will come back as ladder in the old format. downloading the symbolic file takes time so what I do is either not bother or only do this after finished for the day & there is plenty of memory to store it. On-line edits can only be 500 or so bytes of changes, normally not a problem but if you create a large function block you will have to put the PLC to stop to download it.
 
Last edited:
Does anyone have any experience with converting a Beckhoff (codesys) program to a mitisbushi program? Excluding IO of course.

Are both on the same page with IEC that this would work, or would it be a huge headache? The existing beckhoff program is exclusively structured text.

We dont currently own ant Mitusi programming software so I cant really test and would like some insight before I tell anyone its possible or not.

Thoughts?

I have moved GE PME 9 , Toshiba, AB SLC500, ABB CODESYS to various Mitsubishi fx platforms using GX IEC, GXWORKS 2 I would advise not to waste time trying to convert. If you know the the process write from scratch in your preferred coding.
 
Thanks for the input all. Seems it could be a headache but possible with the bulk of the st code.
 
It does work and quite easy. If you're going to learn TwinCat3 or Mitsubishi's version of CodeSys you will find library management a necessary and valuable tool and after you learn that, it's a piece of cake to share code between the two; CodeSys versions being compatible and all.


I created a library in TwinCat3 with and FB in ladder, added and installed it into a library. Fired up Ecostruxure Machine Expert and was able to use, copy and paste and also edit the library. I got a dialog box asking me to upgrade and I just ignored it for not specific reason; I'm sure it would work after upgrade too.


Edit:


I must say this was a fantastic experience and exactly where we should be; focus on system design and programming and on dealing with platform specific issues, migration and compatibility all that headache.
 
Last edited:
This could be option...

On the Twincat side there's option to export program parts as xml file. Just right click over your POU and choose "export plc open xml". Do the same for all the POUs, DUTs and GVLs you have in your project.

I hope there's option to Import these xml's on the Mitsubishi side. Don't know anything about it...
 
This could be option...

On the Twincat side there's option to export program parts as xml file. Just right click over your POU and choose "export plc open xml". Do the same for all the POUs, DUTs and GVLs you have in your project.

I hope there's option to Import these xml's on the Mitsubishi side. Don't know anything about it...


Thanks, that is great help; to me anyway.

It worked with the two platforms I mentioned above; so far I was able to export then import one block at a time but not the whole project. But it still looks promising because the import dialog shows the whole structure and every object in it. I must be missing something minor.
 
I had need to install GX Works 3. It is not at all possible to import XML files, it works with CSV. I tried an online XML to CSV converter and that did not work at all wither.
 

Similar Topics

hello all. i need help to connect my Beckhoff PLC with the codesys. i have tried the codesys RTE tool but i coudnt connect to the plc. can any...
Replies
5
Views
3,866
Currently we have many AB L30s in the field with no network monitoring capability. In a new project we will be installing BC9000s in many of the...
Replies
8
Views
5,330
I had a person ask me what is the difference between TWINCAT, WAGO software, and CoDeSys? So if anyone can help me understand that would be...
Replies
6
Views
30,013
I'm trying to integrate a Beckhoff IPC with a Controllogix PLC. There is some documentation, on the Beckhoff website, on how to do a PLC-PLC comms...
Replies
0
Views
64
Hi everyone, This is my first time posting, so please forgive any omissions or mistakes. I am attempting to control the velocity of a stepper...
Replies
18
Views
1,045
Back
Top Bottom