Posts by jba

    No I dont think we have encountered that problem. What program du you use to generate the program? You can try to upload the program and I can see if anything looks off.

    The stepper driver sends and voltage to the yaskawa controller. When the controller turns on/off the DOUT#11 the voltage goes back to the stepper driver which turns on the stepper motor. When it does not recieve the voltage the stepper motor does not spin. (it might be the other way around) So actually the yaskawa controller only talks to the stepper driver. The stepper driver is not connected to the duet.


    I'm sure that you could connect the controller directly to the Duet but that is too complicated for our current skill level.

    When the extruder needs to start or stop we call a program called EXTRUDERON or EXTRUDEROFF. As you can see we get a EXTRUDERON call for every movement of the robot. This is off course not necessary but that needs to be fixed in the postprocessor of ROBODK which is written in python. (we dont have anyone in the company that knows python) The Duet does not control when the extruder starts and stops it only controls the temperature and the flowrate.


    CALL JOB:EXTRUDERON

    MOVL C00211 V=27.6

    CALL JOB:EXTRUDERON

    MOVL C00212 V=27.6

    CALL JOB:EXTRUDERON

    MOVL C00213 V=27.6

    CALL JOB:EXTRUDERON

    MOVL C00214 V=27.6

    CALL JOB:EXTRUDERON

    MOVL C00215 V=27.6


    the EXTRUDERON/OFF program is a single line that turns on/off the output which comes from the stepper driver

    DOUT OT#(11) ON


    3. Im not sure exactly what you are asking for. Currently the extruder has a set flowrate which cannot be changed during a print. This produces fine prints and any jerks/acceleration of the robot does not affect the quality. It would be nice to be able to change the flowrate during the print.

    I 3d print using yaskawa robots (FDM)


    I normally use Prusaslicer for slicing and use the generated gcode in Robodk. With robodk I'm able to generate the JBI files. Currently the robot only controls the movement and when to start and stop the extruder. Temperature and extruder speed is controlled directly on the Duet3D.


    The problem with yaskawa controllers is that they do not have enough memory to run other than very small prints so we have an external PC which we use to drip feed the robot using a program called motoDCI which we bought from yaskawa.


    It is not easy to start 3d printing. We spend a lot of time to get everything up and running and we still not where we want to be.


    You can see our robots here https://www.flexible-products.dk/en/3d-print/

    Exactly.

    im not sure about DX200, on YRC1000 I've seen a small cable that connects two controllers to make them work together.

    I think it would be good idea to get in touch with yaskawa representative.

    I have talked with the yaskawa representative and he suggested a setup where the two robots talk together using I/O. That is sufficient for our current needs

    first thing first.

    You bought two robots, with 2 separated controllers?

    Are both manipulators are on the same controller?

    Each robot has its own controller. There is nothing that connects the two. They are completely separate. So off course some kind of physical connection is needed.

    Hi,


    We have bought two MH12 DX200 robots which we want to have working together. I have searched on documentation on how to control two robots simultaneously but cant really find anything. What is needed in order to get this to happen? Can someone point me in the right direction regarding documentation?


    In my mind one robot should be the master and the other one the slave but I have no idea if this is how it works.


    We program our other robots using RoboDK software.

    So apparently the Yrc1000 controller is different from dx100 and dx200.


    The problem I'm having can almost be solved with something called "Speed priority control function".


    By default the robot will slow down when the distance between teaching positions is too short to reach the specified speed.


    To overcome this you used the instructions HPVELON and HPVELOF the beginning and end of the program.

    It works more or less as I want it too but there are still some things that could be better

    Hi,

    I have the same issue with the old version MH50 (dx100) and MH50II(DX200). The only way to avoid the problem is to reduce the numers of point involved.

    I don't use RoboDK but I think that you can refine the path.

    As the robot is used for 3d printing every time it goes up one layer height it needs to move up by 0,9mm then 1,2mm to the side. This causes the robot to slow down and there is no way it could be done any diffrent I'm affraid.

    We got a new GP50 yrc1000 robot that will be 3d printing but during the first testprint it slowed down in different places.


    It seems that when ever the points a close to each other the robot slows down. I made a small test program(please see the attached files) to illustrate this.


    When running a similar program on our MH24 the speed is constant. No slowing down what so ever.


    The tool is calibrated and the robot is no where near a singularity.


    Does anybody have a good idea as to why this is happening?

    A small update. We had a guy from motoman to have a look at it. He did not have a solution but confirmed that for some reason the L axis did not move at the corret speed. He tried to simulate it in a program(motosim maybe) and it did the same. If he tried wit a MPL 500 robot there was no issues what so ever. So something is different in the MPL 800 robot. He will investigate further and get back hopefully with a solution.

    Once again: If You make a new video, You should show more parts of the robot: last segment of the upper arm with extruder, from the side.

    Don't know how Yaskawa calculates the transformation. If they use one model for all robots and for this special robot they block the Axis 4 and 5, may be there is a internal singularity.

    May be You can change the behaviour if You change the orientation of last axis.

    Here is a video from the side. It is the same square as in #12


    External Content youtu.be
    Content embedded from external sources will not be displayed without your consent.
    Through the activation of external content, you agree that personal data may be transferred to third party platforms. We have provided more information on this in our privacy policy.

    Regardless how many point the program have it does not change the fact that it runs with a constant speed at the begining of the print but as it moves further away from the table it slows down as shown in the video.


    I have tried to make a very simple program directly on the robot. 4 position variables that forms a 500x500mm square. When the z value is set to table height the program runs without any issues.


    Setting the z value to 650mm above table height the robot slows down but only when it going "in and out". When it goes from "side to side" it moves at the set speed.

    External Content youtu.be
    Content embedded from external sources will not be displayed without your consent.
    Through the activation of external content, you agree that personal data may be transferred to third party platforms. We have provided more information on this in our privacy policy.


    You should post a video that shows the axis 4/5/6 during the slow down. I bet, we will see a singularity.

    As requested:

    External Content youtu.be
    Content embedded from external sources will not be displayed without your consent.
    Through the activation of external content, you agree that personal data may be transferred to third party platforms. We have provided more information on this in our privacy policy.


    At around 0:04 it slows down and at 0:09 it speeds back up

    You are right. It is computer generated but I dont know how to determine which points I dont need. There is not good reason why the extruder turns on at every point. The reason is the way the software generates the JBI file. We cant avoid it wihtout doing some alternations to the post processor which is a phyton script. Currently we have no one in the company with the skills to change it. It will be taken care of eventually.


    I tried manually to remove all the extruderon/off commands but that did not make a difference.


    I tried to cut a slice of the hole print where i knew it slowed down. If I moved this slice to be printed directly on the table there was no slow down in the speed. If i moved the slice to be printed 35cm (14 inch) higher up it slowed down as usual.