+- RoboDK Forum (//www.sinclairbody.com/forum)
+-- Forum: RoboDK (EN) (//www.sinclairbody.com/forum/Forum-RoboDK-EN)
+--- Forum: General questions about RoboDK (//www.sinclairbody.com/forum/Forum-General-questions-about-RoboDK)
+--- Thread: Variable reference frames and targets in output programs (/Thread-Variable-reference-frames-and-targets-in-output-programs)
变量参考帧和公关的目标输出ograms-Maarten-11-10-2021
Hi, this is a follow-up on my questions in two previous threads (hereandhere), but if I can't solve the issue it would impede the use of RoboDK for our situation. And I think the visual way of building and simulating robot programs in RoboDK is perfect for it, don't get me wrong.
I have a main program which calls the same subprogram (joint move a Meca500 robot TCP to reach a Cartesian target) twice, and in-between the two calls the robot base is moved with respect to the target. In RoboDK's simulation the joint angles are updated automatically according to the movement, and the TCP reaches the target for each call. However, when I export the main program to a .py file (using the Mecademic Python post processor), the subprogram becomes a subfunction with move commands to a fixed robot pose target. It does not take the relative movement between the robot base and the target into account, and so the robot will only reach the target if the actual reference frame happens to coincide with the reference frame at the moment of export.
Could a viable solution be to provide the current reference frame as an input argument for the exported subprogram? I think this is what RoboDK effectively does behind the scenes when running the simulation. How could this be implemented when generating the export robot program (apart from laborious manual post editing)?
Kind regards,
Maarten
RE: Variable reference frames and targets in output programs-Jeremy-11-11-2021
Hi Maarteen,
I'm sorry for the late reply, I was out of the office for part of the week and your questions require more than just a quick reply, I need to test some things out.
If you can provide a simplified version of your setup/problem I will sit down and think of a potential solution for it. There's almost always a way to make it happen with RDK, but sometimes we need to be a bit creative.
Jeremy
RE: Variable reference frames and targets in output programs-Maarten-11-14-2021
Hi Jeremy, I attached a simplified model to illustrate the issue. It's a Meca500 on top of an X-stage. The main program calls subprograms moving both the X-stage and the robot. The robot makes a joint move to the same target twice, but since its base was moved in-between, it has a different pose for the same target. The simulation is as intended.
Now when I export the main program (also attached) using the Mecademic Python post processor, the subfunction which moves the robot to the target becomes a subfunction (def Meca_Tar01) which first defines a world reference frame and TCP, and then a move-to-pose command. It doesn't "know" anything about its base having moved by the X-stage; the world reference and pose target are as defined once in the subfunction, and when executed the robot will always move to one and the same pose. Therefore, calling this Python subfunction will not do the same thing as calling the subprogram in RoboDK.
So how can I extract the right commands to make the robot in the real world move identical to the simulation?
Kind regards,
Maarten
RE: Variable reference frames and targets in output programs-Jeremy-11-16-2021
Hi Maarten,
So this isn't really a RoboDK limitation and more of a Meca limitation.
For this to work directly, the Meca would need to support external axis natively, this is what we call "External axis synchronisation" (doc://www.sinclairbody.com/doc/en/General.html#SyncAxes)
With the robot brands that support such features, you can provide either A1 to A6 + E1 or Cartesian + E1.
For the brands that do not support such features, it's a bit more tricky, but not impossible.
I just finished a project with an Omron-TM cobot where the cobot was on a vertical rail for a palletizing project. External axes are not supported by this brand.
So what I did was to create a python macro that takes the Main program and runs it step by step and recreated each target as a "Robot base" target.
It pretty much brings the rail where it should be, move the robot in the simulation, create a target there with respect to the base, and so on and so forth.
For this to work it will create a new copy of the "Meca_Tar01" program for each rail position it encounters.
它可能本身em a bit silly, but it works very well and completely remove the external axis limitation of the robot.
The python macro I created is very specific to the project, so I can't just send it to you, but if this solution makes sense to you we could work on it together.
Jeremy
RE: Variable reference frames and targets in output programs-Maarten-11-17-2021
Hi Jeremy, that's right, Mecademic doesn't support an external axis. That’s ok, for now there is no need for motion synchronization of a robot and an external axis. There will be two robots and many external axes, and they can move either subsequently or simultaneously, with their own targets. But the movements of one robot and/or axes do affect the required pose of the other robot to reach a target at a certain moment, and should be taken into account.
I think your method of a Python script to add a copy of a target to the robot base reference frame for a given robot base position might work. Would it still be feasible for a machine consisting of two robots, many external axes, and programs of several layers deep, with subprograms in subprograms in subprograms, each of which may contain multiple move commands to more than one robot or axis? And without compromising the features and flexibility of RoboDK to design a program for the machine?
Zooming out, it seems risky, and a very complex detour to get a list of subsequent commands for the different robots and axes. This since the simulation already performs exactly the right movements; so the information is there, just not in a format I can export and feed to the separate robots and axes. Is there no easier way?
Could you send me a stripped down version of the Python script you made so I can try and build on that? Also, could you send me the uncompiled Mecademic post processor so I can make adjustments if needed?
Thanks for your help,
Maarten
RE: Variable reference frames and targets in output programs-Jeremy-11-17-2021
Hi Maarten,
If you own a professional license of RoboDK, you can reach us via "Help"->"Request support" and ask for the Mecademic Post. Make sure to specify you want the Mecademic Python one.
You can ask for "Jeremy" to be added in cc, I will provide you with the python script as I would prefer to keep it relatively private for now.
I will bring the subject to our tech meeting tomorrow morning and see if a simpler solution is possible, but I doubt it as the post would need to know the current position of the robot after the external axis moves... Which is not the case.
If you want to know what the post-processor receives, generate a program, then reach your temp file. You will find a "PostPROGRAMNAME.py".
Jeremy
RE: Variable reference frames and targets in output programs-Maarten-11-18-2021
Thanks Jeremy, I've just sent a request via that route.
You wrote "the post would need to know the current position of the robot after the external axis moves... Which is not the case". I think the model in RoboDK needs to know the base position of the robot, and it does know, as the simulation shows. Then a dedicated post processor should be able to take this into account, and export the commands for the corresponding robot targets and external axis targets to a file. The robot can perform its commands, independent of the external axis. The external axis performs its own commands, independent of the robot. But since their targets are derived from the RoboDK model which does take their dependencies into account, together they would perform the same as in the simulation.
I'd be interested to hear if you find any way to implement this.
Kind regards,
Maarten