We have had sample post-processors here on the forum for a while for exporting VC robot programs into native robot languages. Here is an add-on for doing the reverse. So now you can upload native robot program into VC simulation model. We start off with Kuka translator but more brands will hopefully be added in the future.
Install the addon by extracting the zip file to My Commands folder. Then restart the application and the “Upload” button shows up on the Program ribbon tab.
Package contains ReadMe.txt which has quick instructions on how to use different translators.
version_history_xxxx_xx_xx.txt shows the updates to the add-on.
Currently included uploaders:
Kuka (.src/.dat)
ABB (.mod)
Fanuc (.ls)
Yaskawa (.JBI)
---
Kuka translator lets you upload a single .src file. You can also include .dat file and $config.dat files in the same folder and add-on will recognize those. $config.dat is used to read base and tool data along with possible home positions.
The scope of the translator is limited. It can handle PTP/LIN/SPTP/SLIN motions, subroutine calls, binary input and output, IF and WHILE statements and simple data declarations and assignments. Translator uses regular expressions in parsing so there will be a small learning curve if you want to modify the parser.
The scope of the uploader is very similar to Kuka uploader. You can load one .mod at a time but you can load other modules one by one and merge them into the existing program. When loading multiple modules load your main module last so that the subroutines exist for call references.
For DO/DI signal mapping you can use robotWrapper.SignalOutMapping and robotWrapper.SignalInMapping dictionaries. So add real_signal:sim_signal pairs (e.g. “doArcOn”:101) to those dictionaries to customize mapping to suit your cell. Without dictionary uploader tries to find signal index from the name (e.g. do12 => 12).
Uploader loads base and tool data from module and overrides current data. If this is unwanted just delete readBaseToolData() call on upload() function. The most common thing that can go wrong in the translation is the base/tool frame location. Uploader tries to find suitable node to attach the frame to but this requires that the kinematic structure on the simulation model matches the real device exactly. Mechanism names must match (e.g. positioner component name could be “STN1”). Also be aware of tracks as the robot world frame might not be at the same location as on the real cell when using tracks. In problem cases set frames manually and block readBaseToolData().
External axis value mapping can be changed on robotWrapper.ExAxisMapping. For example if the real cell has track as axis 7 (~E1) and positioner as axes 10 (~E4) and 11 (~E5) and on the sim model track is E1 and positioner is E2 and E3 then the ExAxMapping should be { 0:0, 3:1, 4:2, 1:3, 2:4, 5:5 } using zero-based indexing.
MoveC is loaded but only as two lin motions. Few comments surround that to notify that original motion was actually circular.
Fanuc uploader loads a single .LS file but you can also put POSREG.VA into the same folder and uploader will recognize it and position register inside it. You can load other .LS into the same simulation by choosing not to reset existing program.
There are limitations to the uploader. UFrame and UTool data is not loaded so you have the set those manually. Uploader will not translate all jumps but only the ones that form a loop and then it will form a while from it. Some program flow instructions like SELECT is not supported. In motions OFFSET and TOOL_OFFSET are not supported. This uploader doesn’t support Karel but only the .LS files.
Yaskawa can read PULSE and RECTAN jobs but there may be some issues with translating jobs from some systems. In case of problems please reply this thread about the issues and we try to update the translator. Please read ReadMe.txt in the package for details.
I’ve found some minor issues, with Fanuc PP.
In my .ls the 0.xxx (float) values were printed out as .xxx or -.xxx
The PP could’t handle the Config and Location Names either.
P[1:“HOME”]{
GP1:
UF : 0, UT : 1, CONFIG : ‘N U T, 0, 0, 0’,
X = 621.034 mm, Y = .549 mm, Z = 172.662 mm,
W = -174.542 deg, P = -.934 deg, R = 107.944 deg
};
There were also problem with the IF statement.
It look like this:
1: LBL[1] ;
2: !home ;
3: PAYLOAD[1] ;
4:J P[1:HOME] 100% FINE ;
5: ;
6: DO[102:LEF.HOME]=ON ;
7: DO[101:LEF.FENT]=ON ;
8: ;
9: DO[103:LEF.UZEMKESZ]=ON ;
10: !------------------------ ;
11: ;
12: IF DI[101:CIKLUS START/lef indulht]=ON AND DI[106:LEFUJO AUTOMATABAN]=ON,JMP LBL[2] ;
13: ;
14: JMP LBL[1] ;
15: !gep fole all ;
16: ;
17: LBL[2] ;
18: ;
19:J P[2] 100% CNT100 ;
20:…
We don’t have Mitsubishi or Denso uploaders planned at this moment. Denso downloader could be something we could add in the future to our translators.
In general downloaders are easier to make and that’s why we have more of those. Uploading process can be a lot more complex because you may need to read in data from multiple sources like global variables stored somewhere else than the actual job file. Also native languages have a lot of commands that are not supported in VC such as JUMP-LABEL (or GOTO-LABEL). So translating them into VC program is really difficult. Downloading is easier as VC statements can usually be easily mapped to native robot commands.
Hello
Great piece of Add-on! Can i ask you if the following code structure made in a KUKA is compatible for upload? Its a Base_Frame where im modifying the data based on an Input variable (eg. stacking height adjusted)
&ACCESS RV
&PARAM EDITMASK = *
&PARAM TEMPLATE = C:\KRC\Roboter\Template\ExpertVorgabe
DEF Pickup_subject( )
ENDECL GLOBAL FRAME Base_data[13]
;*********************************************************
;Fixed offset program base by values or variables
;*********************************************************
Base_data[13]=$NULLFRAME
Base_data[13].x=Base_data[13].x+0 ;Shift base in x-direction
Base_data[13].y=Base_data[13].y+0 ;Shift base in y-direction
Base_data[13].z=Base_data[13].z+giLayerToPlace*rCurrentCellHeight+0 ;Shift base in z-direction
Base_data[13].a=Base_data[13].a+0 ;Shift base in z-rotation
Base_data[13].b=Base_data[13].b+0 ;Shift base in y-rotation
Base_data[13].c=Base_data[13].c+0 ;Shift base in x-rotation
;*********************************************************
;Set program base definition to table 1 and table 2
;*********************************************************
Base_data[16]=Base_data[2]
Base_data[16]=Base_data[16]:Base_data[13]
No I don’t think this will be translated. This sort of math operations rarely translate well into VC program. While we do have SetBase statement the problem is that you cannot use variables in that statement to shift the base. So translating this sort of logic is near impossible to do as the vocabulary of VC language is so much smaller than KRL.
No new pre-processors are being planned at the moment. Pre-processors in general are really difficult to make because the VC language is so much simpler than native robot languages and therefore there are big limitations on what you can translate to VC. Lately the trend has been going more towards the use case where you run the native code on virtual controller and connect virtual controller to VC simulation. That way we don’t have to worry about some functionality missing on VC controller/executor. And for that connectivity we might have some news soon for Doosan specifically.
We don’t have any plans to develop new translators for this forum add-on. Nowadays we have specific product for offline programming in Robotics OLP (Robotics OLP - Visual Components). That product includes translators for many brands including UR. I would say that these OLP translators in general are better because they have been developed and tested in production environment whereas these forum add-ons are more of a sample with limited testing usually against virtual controllers only. Of course the OLP translators are not available for basic Essentials user but if you are in need of a good offline programming software I would suggest to look into our OLP products.
