Posts by motomichael

    Hello gentlemen,


    I have a relative job on DX100 MH50. I can save it normally to ftp or flash drive. When I try to load it back to the controller the "error 3190: error in job record" arises with code 12, which is said to mean "Record on the teaching coordinates for relative job FRAME is wrong for the format."


    I found that the cause of the error is the RJ teach frame UF#(25) or higher, for UF#(24) and lower numbers everything works fine.


    Why is it so?


    Best regards,
    Michael

    As far as I could understand, with Ethernet server function of DX100 and DX200 you can send instructions (including movement) to the controller "on the fly". Check the manual, probably it is what you need. It is a paid option, though.


    BR,
    Michael

    Hi all!


    Just wonder why I can't log into my dx100 with telnet. TCP/IP is up, I set s2c1119=2 and reboot, then telnet to default port (23), get "Connection refused". Ethernet server on port 80 works fine meanwhile.


    Michael

    Yes, I know it now. The problem was that right after the crash there was a mess of plastic fragments, that powder-metal things sitting on the shafts were partly broken too. We prepared to buy a new encoder, and pulled damaged metal part off from the encoder shaft (merely out of curiosity), but didn't take care of its position. Then we looked at all that stuff and figured out what did it look like before the collision. We used that metal part as a matrix on which we assembled the broken plastic coupling using epoxy glue. Now it is up and running, but all that arrows are in rather arbitrary positions with respect to each other and shafts. I hope we'll never have such an experience again.


    I'm just curious about such a behaviour of servo. Why does is rotate in the wrong direction with a certain encoder position?


    Best regards,
    Michael

    Ooops,


    problem solved. Just rotated the encoder shaft several times in proper direction. Going to re-create the home position.


    Thank you all for attention.


    Best regards,
    Michael

    Hi guys,


    this week we had an accident with our MH50/DX100. As a result, an U axis encoder was torn off its place. Actually, a mechanical damage to the encoder turned to be not so hard, the most serious problem was a destructed plastic coupling between the motor and the encoder shafts, so we managed to repair it using the epoxy glue. Naturally, the position of the encoder shaft w.r.t. to motor was lost, as well as ABSO data. Nevertheless, after setting the encoder in its place, I created a new home position, and after some tuning of the ABSO data for the U axis in the "Home Position" screen the robot ran again just normally. After some hours of production I inspected the repaired encoder and it seemed to produce an unusual sound (maybe that was just a wrong impression).


    Today we decided to see if there is something wrong with the encoder or the coupling, so we took it off. I thought that the recovery after such an inspection would be not harder than after the accident, so I set the robot in the standard home position (L axis vertical, U axis horizontal), hoping that it would be sufficient to re-create home position after the encoder position change and possible ABSO data loss, as long as robot did not move. The repaired coupling looked nice, but after setting the encoder in its place, the problems started.


    After the initial accident, all the axes moved only when I pressed jog buttons. Now when I turn servo on, the U axis starts moving by itself, and after some tenths of second stops abruptly (the brake turns on), and I get an alarm 4327 "Wrong motor rotation". At first, each time this happened, the U axis moved downward, i.e. in its "-" direction. At some moment I put a wooden support under the axis, so now when it reach this support, the next time I turn the servo on it moves upward. And the next time - downward again.


    Have you any ideas?


    Best regards,
    Michael

    95devils, BwillieS,


    well, i thought a bit... Yes, the job with moves is called from the outer job, and the stack is quite deep... And there are a bunch of conditions check in the beginning of cycle. So I shall not demand more from it. The strange thing is that when I try to cycle the inner job the robot behaves istself in the same way, and the first line (after NOP) and the last line (before END) are the same MOVJ VJ=100.0, and the positions are exactly the same.


    I'm pretty sure that there are no accidental low speed moves between the end and the beginning.


    Thank you.


    Michael

    Hi all!


    I have DX100/MH50 tending a pressbrake. I always teach it in such a way that the first and the last positions in the cycle are the same. In the end of cycle a short stop occurs, just like in the situation when there is, say, PL=0 in the move. I tried to omit the last move, so that the start and end position were different, but in this case the robot moved between them at low (safety?) speed. Is it possible to make the robot move smoothly and at full speed between the end and the beginning of the adjascent cycles?


    Michael

    Hi Dan!


    Well, really, TL#(0) seems to be DX100-only feature.


    > I tried to write a short program to move the robot over 50mm using the tool frame but I would get an error.


    Base frame, you mean? There is no mention of tool frame in the program. Base frame is that linked with the floor; tool frame is linked with the current tool, it moves with respect to BF (and floor) as the robot moves.


    What is the error message? Is your P001 variable initialized? I cannot say for sure now, but it seems to me that in order to be able to do


    SUB P001 P001


    you must initialize P001 first; and to be able to do


    ADD P000 P001


    you must have both P000 and P001 initialized and be in the same frame.


    I would try something like this:


    NOP
    MOVJ C00000 VJ=25.00 PL=0
    GETS PX000 $PX000
    CNVRT PX000 PX000 BF
    ' Initialize PX001 to be in
    ' the BF as well
    CNVRT PX001 PX000 BF
    SUB P001 P001
    SETE P001 (1) 50000
    ADD P000 P001
    MOVL P000 V=35.0
    END


    or (even better)


    NOP
    MOVJ C00000 VJ=25.00 PL=0
    GETS PX000 $PX000
    CNVRT PX000 PX000 BF
    GETE D000 P000 (1)
    ADD D000 50000
    SETE P000 (1) D000
    MOVL P000 V=35.0
    END


    Best reagrds,
    Michael

    Hi Dan!


    > Would I need to have the command line:
    > CNVRT PX000 PX000 UF#(1) TL#(0) after every GETS command?


    Yes, as long as you are working in carthesian coordinates.


    > I have not defined any user frame that I know of. Can the above just be CNVRT PX000 PX000 TL#(0)?


    You may write


    CNVRT PX000 PX000 BF TL#(0)


    So the position will be in the base frame.


    Best regards,
    Michael

    Hi Dan!


    Seems that you are working in tool coordinate frame rather than the base CF. In the configuration shown in your picture the Z axis of the tool CF is normal to the arm flange, not to the floor.


    How do you obtain the value of your position variable? I'm not sure which CF the command "GETS PX000 $PX001" do use. I prefer to do it as follows:


    ' get current position in pulse
    GETS PX000 $PX000
    ' convert it to explicitly specified CF
    ' using specified tool number
    CNVRT PX000 PX000 UF#(1) TL#(0)


    After this the P000 variable contains the current position in user XYZ CF UF#(1). Of course you may use BF or TF instead of UF#(1).


    Best regards,
    Michael

    With the string 'CNVRT P006 P000 TF T#(0)' you convert some P000 to P006, so you lose current position stored in P006 in the previous step (GETS PX0006 $PX000). May be you meant 'CNVRT P006 P006 TF T#(0)'?


    Michael

Advertising from our partners