[farhan]

Hello.

I'm using RoboDK to generate programs for my robot Motoman MH 80 with the DX100, for additive manufacturing with MIG welding. I tried with simple shapes, like cubes, prism, and cylinder. I imported the shape into RoboDK and generated the code. For cylinder, the robot movement in real is the same as the RoboDK simulation. But, there are problems with cubes and prism. the robot movement isn't same as the simulation. Although in the simulation of the robot movement as I expected, but its totally different after I generate the code and run it on the robot. I attached sectional pictures of cubes and prism shape below.

For prism shape, I expected the robot move from point 1-2-3-1 and so on. but, in real, the robot move with this way 1-2-4-3-1 and so on. 
For cube shape, I expected the robot move from point 1-2-3-4-1 and so on. but in real, the robot move with this way, 1-2-5-3-4-1 and so on.

i have no idea why the robot move like that even I double checked the RoboDK, I still get none. Do you know why is this happening? is there any correlation with polygon shape? Because this just happened in cube and prism, not for cylinder.

I attached the 3d model of the prism, cube, cylinder, and the pict of each shape, and the station I used.

[Albert]

The fill pattern highly depends on the slicer software you use, not RoboDK. What slicer software did you use?

Also, make sure you properly loaded your pulses/degree ratio in RoboDK if you generate the program using pulse data.

[farhan]

i use default slicer, slic3r. for pulse/degree ratio, i surely use the correct pulse/degree
do you know, Which part of the setting do you suspect I missed or got wrong? i have no idea about this one

[farhan]

even i tried to export the gcode and try to simulate it with gcode simulator in some website, the result have no problem. the problem just appears whe the robot move based on generated code from robodk.
actually this happened before, around 1 year ago. i use different robot, motoman sia 10D, for my bachelor thesis, and at the moment I wanted to make a cube. but the robot did not move as desired and instead made another shape similar to a pentagon. but, to make a circle movement the robot was good. because at that time I was not focusing on the cube movement, so I ignored it.

[farhan]

i tried import the same code (jbi) that robodk generate, and in the simulatiom there is no problem again. is this maybe problem with yaskawa robot motoman?

[Albert]

I was trying to reproduce the issues you describe but it looks like you are using a custom post processor.

What did you customize? Can you send it to us?

[farhan]

i just custimized the tool number to adjust with my tool number in pendant.
here's the post processor I used.

[Albert]

I'm unable to reproduce the issues you described. For example, I tried generating the PRSM file and load it back into RoboDK and it worked well.

After importing a Motoman JBI file you may need to properly link it to the robot base frame (default base for exporting, used by default in RoboDK) and the correct tool.

I recommend you to use tool numbers in the tool names for controllers like Yaskawa Motoman and Fanuc. This will take the ID you used in the name. For example, if your tool name is TCP 2, it will use ID 2 for the tool.

[farhan]

Hello, albert.
as u said, i tried again with default post processor, motoman, and regenerated it again. i do manually editing the generated code to adjust the tool number and remove command such as MC, JOB CALL, and etc that I don't need. i attached the code for cube and prism below. after that, I imported to pendat and ran the code. unfortunately, the result is the same with the previous experiment. the robot does not move as desired and makes like another polygon. for the evidence, I attached the result of current experiment  and the video in folder "result" in this link https://drive.google.com/drive/folders/1...sp=sharing
the results in jpg and video, which is in name cube_result.jpg, prism_result.jpg, cube_video, and prism_video

as shown in the result, the sectional area of the prism it should be a triangle turned into a diamond and for the cube it should be a square turned into pentagon

[Albert]

This is very strange... Can you try generating the program using the Motoman_Cartesian post processor? This will make sure it is not an issue with the pulses/degree ratio entered in RoboDK.

If you still have issues with the Cartesian targets:
Has the robot been mastered? For example, could you try moving all joints to zero?

You can then move each joint to 90 deg and make sure they moved to the right spot.