[maexbecks]

Hi,

I still haven't figured out the best way to code in RoboDK to avoid redundancy in my workflow when creating programs for simulation and at the same time for generating offline programs for the real robot.

My latest state is that I am generating programs in the station with a Python script. This way I can call the programs to simulate the behavior and also generate offline programs for the robot. But this way my station gets messy really fast. The generated programs become huge and unflexible.

For example: I have a workpiece storage with 24 parts in it which I want to be able to grip. Now I want to create programs for approaching to grip the workpiece and I also need programs to retract with the workpiece so I can wrap them around with some logic and error behavior outside of RoboDK. This means there will be 48 programs alone for a single workpiece type. In the end there will be 5 workpiece types, so this means 240 programs alone for this station. This also means 240 generated subprograms in my robot module with mostly the same stuff in it.

Right now I am thinking about how to avoid this mess. My goal is to have one Python script "approachToWorkpiece(tray_number, workpiece_number)" and one "retractFromWorkpiece(tray_number, workpiece_number)". From RoboDK I would call this as subprograms with the respective workpiece and tray numbers for simulation purposes. This works fine in the simulation, but I also want to be able to generate a robot program which only has this two procedures in it without generating 48 procedures for each part.
Maybe anyone has a smart idea how to best achieve this?

Anyway, right now I want to call the python scripts program a program in the station tree and generate the program with the programs from the python scripts as subprograms, but this doesn't work. The generated program includes the call to the subprogram but does not generate the subprogramm itself. When I generate the program from the python script it gets generated without problems. See the attached station.

[Albert]

Python programs should be generated separately as they won't be included with the main UI program.

One option to prevent generating too many programs is to have a Python script that moves relative to the current position of a robot or based on an index and some criteria.

For example, if you want a relative move to the current position:

Code:

# Take the current position:
current_pose = robot.Pose()
# Move relative 100 mm along the tool Z axis
new_pose = current_pose * transl(0,0,100)
robot.MoveL(new_pose)

You would need to create a similar program on the robot controller side as generating this program won't work for generic program generation.

Another example that can integrate better with generic program generation is to use an index based on some criteria. For example, if you have different trays and different part numbers, you can create program numbers based on the corresponding indexes. It would be easy to use the API to generate all these programs automatically. But I agree it would be a messy station with many programs. You can still place them in a folder and hide them but all these programs should be available in the controller.

Also, you can inline subprograms in the same main program recursively by following these steps in RoboDK:

1. SelectTools-Options
   
2. Select theProgramtab
   
3. Check the optionInline subprograms
   

[maexbecks]

Hi Albert,

thank you very much for your answer.
Yesterday it hit me how constrained my thinking was and that I have the full power of python behind me.
所以我开始创建一个基于th python模块e post processor to generate the robot program as well as create the programs in RoboDK at the same time.