Hello everybody! All the programming languages for robot arms are pretty similar so I think maybe there is a some kind of parser that can parse for example Kuka's code into Kawasaki's AS language? For example RoboDK makes code for almost every robot. Do you know the ways I can implement it?
Parsing code
-
Ilim Aisayev -
July 13, 2023 at 8:44 AM -
Thread is Unresolved
- Go to Best Answer
-
MOM
July 13, 2023 at 9:39 AM Approved the thread. -
I'm not aware of any. RoboDK, ProcessSimulate, and other 3rd-party programs generate programs for every robot brand, they don't translate between them. They achieve this by having their own internal "common" language, and a series of brand-specific postprocessors to translate from that common language into each brand-specific language.
These sim programs also produce very simple programs for each brand. In theory, such simple programs should be translatable between brands, but as soon as you begin adding complexity (say, Interrupts), these operations become so unique per-brand that the difficulty of translating just expands exponentially.
-
100% concur with SkyeFire
All the programming languages for robot arms are pretty similar.
I respectfully disagree.
Some Kawasaki commands (AS) are actually small macro's which include other functions.
eg:
- OPENI and CLOSEI - activate clamp signals and turn off CP for the motion and are motion commands.
You also have Block Programming too which again use hidden macros specifically targeting the application it is set up for.
These sim programs also produce very simple programs for each brand. In theory, such simple programs should be translatable between brands, but as soon as you begin adding complexity (say, Interrupts), these operations become so unique per-brand that the difficulty of translating just expands exponentially.
Couldn't have said it any better.
Just to move from A to B should be straight forward, but as SkyeFire mentions - complexity and additional functionality will be brand specific example above.
-
I respectfully disagree.
Well, I was speaking at a high level of abstraction. To a first approximation, it's MOVE XYZRxRyRz, SET/RESET Output, WAIT Input, plus IF/THEN, Loops, etc. If you know one robot, it's not too hard to figure out the most basic programming for almost any other brand.
-
SkyeFire I was respectfully disagreeing referring to the quote from the OP's statement not yours my friend.....
I got the impression the OP was 'lumping' all commands from ALL OEM's into 1 pot, for which a universal parser could be applied and you mentioned 'interrupts', I just mentioned the 'OPENI/CLOSE'I commands from a Kawasaki perspective to also enforce your original points too.
What you said I 100% concur with.........
-
SkyeFire I was respectfully disagreeing referring to the quote from the OP's statement not yours my friend.....
....
-
I'm not aware of any. RoboDK, ProcessSimulate, and other 3rd-party programs generate programs for every robot brand, they don't translate between them. They achieve this by having their own internal "common" language, and a series of brand-specific postprocessors to translate from that common language into each brand-specific language.
These sim programs also produce very simple programs for each brand. In theory, such simple programs should be translatable between brands, but as soon as you begin adding complexity (say, Interrupts), these operations become so unique per-brand that the difficulty of translating just expands exponentially.
Display More100% concur with SkyeFire
I respectfully disagree.
Some Kawasaki commands (AS) are actually small macro's which include other functions.
eg:
- OPENI and CLOSEI - activate clamp signals and turn off CP for the motion and are motion commands.
You also have Block Programming too which again use hidden macros specifically targeting the application it is set up for.
Couldn't have said it any better.
Just to move from A to B should be straight forward, but as SkyeFire mentions - complexity and additional functionality will be brand specific example above.
Thank you guys for your answers! But what if I have really simple VAL3 code like this and I need to translate it to AS language?
XML
Display More<?xml version="1.0" encoding="utf-8"?> <Programs xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.staubli.com/robotics/VAL3/Program/2"> <Program name="main"> <Code><![CDATA[begin close(tCurrentTool) pPointRx.config.shoulder = lefty pPointRx.config.elbow = epositive pPointRx.config.wrist = wpositive pPointRx2.config.shoulder = lefty pPointRx2.config.elbow = epositive pPointRx2.config.wrist = wpositive mCurrentSpeed.tvel = 100.00 mCurrentSpeed.blend = joint mCurrentSpeed.reach = 0.010 mCurrentSpeed.leave = 0.010 // Program start mCurrentSpeed.tvel = 200.000 call MoveJoint(0.000,0.000,-90.000,0.000,0.000,0.000) call MoveJoint(0.000,0.000,-90.000,-82.689,0.000,82.689) call MoveJoint(-0.001,-0.001,-90.001,-82.321,0.000,82.321) call MoveJoint(-0.002,-0.002,-90.002,-82.193,0.000,82.193) call MoveJoint(-0.004,-0.004,-90.004,-82.216,0.000,82.216) call MoveJoint(-0.007,-0.007,-90.006,-82.256,-0.008,82.256) call MoveJoint(-0.010,-0.010,-90.008,-82.252,-0.008,82.252) ....................... call MoveJoint(0.000,0.000,-90.000,360.000,0.000,-360.000) call MoveJoint(0.000,0.000,-90.000,360.000,0.000,-360.000) waitEndMove() // Program end end]]></Code> </Program> </Programs> -
Thank you guys for your answers! But what if I have really simple VAL3 code like this and I need to translate it to AS language?
You would have to examine each command and setting in VAL, and determine its equivalent in AS. Translating between AS and VAL should be relatively direct, as I understand it, as they are close relatives. But I haven't touched AS in 20+ years, and VAL in over 30, so I'm hardly an expert.
-
- Best Answer
You would have to examine each command and setting in VAL, and determine its equivalent in AS.
For sure......
Not knowing VAL but absolutely concur with SkyeFire and just looking at what you have:
Some standard real variables.
- Looks like you have some form of robot posture/configuration references.
- Your positions look like joint angles associated with Joint interpolation moves.
Grab yourself a couple of cold ones and the AS Manual and cross reference:
Defining variables and positions (POINT and #PPOINT).
Joint displacement values (#) and transformations.
RIGHTY/LEFTY/ABOVE/BELOW/UWRIST/DWRIST
JMOVE/LMOVE
call MoveJoint(0.000,0.000,-90.000,0.000,0.000,0.000)
JMOVE #PPOINT (0,0,-90,0,0,0) - At a speculative guess.
-
Is it possible to show the robot configuration (RIGHTY/LEFTY/ABOVE/BELOW/UWRIST/DWRIST) with the teach pendant?
-
Not that I'm aware of.
Advertising from our partners
