Posts by Fester1981

  • SETE TL#()

    Quote from Motouser

    You write a code different from the one in the image:

    here you have SETE P001 TL#(FSU_actGripper) that for sure will be an ALIAS for an integer.

    Until you will pass a value that match a tool number will be ok.

    In your previous code you pass a B-VAR and I don't know the controller (only DX200 or newer can use the SETE Pxxx TL# option).

    In the previous post I believe that you are doing an attempt of using those lines to get rid of SETTOOL/GETOOL instructions (that yes, 95devils, is a pay option), but seems not.

    I started cleaning up the code here and there,

    I also used the alias function to improve readability because there are so many variables in the code.

    I moved the reading of the gripper code to system

    Quote from 95devils

    The SETTOOL and GETTOOL can be used as long as the software is new enough, YAS2.50

    I have a YAS3.02.00A, but I haven't found the SETTOOL or GETTOOL instruction anywhere.

  • SETE TL#()

    Well, as you can see in this picture, it is an existing instruction...


    I also asked the system integrator why this is done.

    They said it's sole purpose is to assign the correct tool specific load values.

  • SETE TL#()

    Quote from 95devils

    The next line is not written correctly. It is either a different instruction or more information is written with the SETE

    That's what I was aiming at, since this is pretty much the entire job.

    I suppose this is more likely to do what I was thinking of?

  • SETE TL#()

    Hi all,

    I found this in some job:

    REFP 1 C00000 BC00000

    GETS PX001 $PX011

    DIN B150 IG#(19)

    SETE P001 TL#(B150)

    '--------------------

    MOVJ P001 BP001 VJ=20.00

    DOUT OG#(104) 1

    '--------------------

    So this sets the tool for P001 to the current connected end effector's toolcode.

    I'm tryng to figure out what it does exactly.

    I tried to set it t to different tools and I would have expected to see some shift depending on the TCP, but they I can'see anything happening when I try to move t the same position with another tool...

    Anyone who knows why this is done?

  • SETPRM command

    Quote from 95devils

    I was able to run a system job and a robot job with something similar to your code successfully. When I had two or more system jobs and a robot job running I would get the alarm.

    I missed the DX200 part. The GETPRM/SETPRM instructions came out on the NX100 controller. Yaskawa has made changes to what job type the instructions can go in. NX100, I believe, was a robot job. DX100 and DX200 those instructions are available in a macro job.

    I tried executing the command in every type of job that had it in the instruction list. GETPRM works fine every time while SETPRM yields the same error. I'll e-mail Yaskawa tomorrow for more info...

  • Yaskawa Motoman DX100 communicstion issue.

    Your controller has an ethernet switch inside? What was connected to it before you connected it in between the pendant and CN105?

    Do you happen to have a ethernet hub or switch with mirroring function available? Most managed Cisco switches (as does the relatively cheap Netgear ProSafe switches) have this option. This way you could monitor the traffic with Wireshark...

    In my experience, (in case of these non-fatal recurring faults) the parts that were moved the most, are the ones that are most likely to fail first. Being the cable between the controller and the pendant...

    Did you check both sides of the cables connectors for any bent/retracted pins or busses? The pins or busses of the controller and pendant connectors? The connection of the wires inside the connectors?

  • How to attatch a laser to a dx100 and create a job that turns it on/aff

    This would not work for several reasons:

    - the condition for the loop is only checked at the beginning (or at the return from "ENDWHILE")

    - this also means that the loop would not be executed (considering D001 is 0 at the start of the loop)

    - if servo is off, non-systemjobs wouldn't even be running (and movement is not possible in systemjobs)

    - if conditions for the while loop are not met, nothing would happen to D001 since it is inside the loop.

    - setting D001 to 0 (or to 1) would do nothing to the state of universal output 12.

    If a systemjob is available (paid option), the turning off of output 12 in case of "servo off" (just to name 1 possible reason) could be performed from here. But systemjobs can be stopped, concurrent IO cannot.

    STILL, THIS IS NOT A FAIL-SAFE SOLUTION!

  • Dx100 external control / jog

    Don't know for sure if this is what you are looking for, but this code should move 1mm or 1° (or ...) in X, Y, Z, rx, ry, rz, on the positive edge of resp. inputs 1..6. And in the other direction if input 9 is active.

  • SETPRM command

    If I'm not mistaken, I only have one system job running. I reduced the integrator's 3 to 1 by moving most of it to the ladder. But I will have to check tomorrow to be sure.

    I only found the SETPRM instruction in the systemjob instruction list. That's the only reason that I've put it there. The code that I've put at "MASTER" in my first post was in fact a simplification. It is not actually the masterjob but the job called from it, if a specific EoAT is installed.

    It only needs to be checked/modified if the masterjob is started from the top.

  • SETPRM command

    I want to change the "work home position", being CUBE 64 by code with the SETPRM command on a DX200. The Inform manual is a bit vague on this topic however.

    This should be possible with:

    Code: SYSTEMJOB.JBI
    0001'***** systemjob
0002 DOUT OT#(4082) OFF                   OT#(4082)=HOME VALUES SET
0003'
0004*top
0005 IF( IN#(4082)=ON ) THEN              IN#(4082)=HOME VALUES ACK
0006  SETPRM KIND=6 PRMNO=I050 D050       D050=HOMEPOS TMP
0007  DOUT OT#(4082) OFF                  OT#(4082)=HOME VALUES SET
0008 ENDIF
.
.

    and

    This would change parameters S3C1072(MIN)/1080(MAX) to S3C1077/1085 to the values from LD001 to LD005 in the master job.

    When starting the masterjob, I receive following error message:

    The SETPRM instruction was executed while another system was in execution
    		Setting error 
    		(1)Check the following settings.
    ·The SETPRM instruction cannot execute while another system is operating. Correct the job. 


    What am I missing here?

  • How to attatch a laser to a dx100 and create a job that turns it on/aff

    Quote from jba

    The program is generated by some software(robodk) and currently we do not have the coding skills required to change the post processor which generates the program.

    But you were able to write your M3 and M9 jobs? It is basically the same. The command you wrote in M3 (DOUT OT#(12) ON) can simply replace the "CALL JOB:M3". Same with the OFF command and M9.

    This doesn't mean you can't use separate jobs for the turning on and off off the laser... All I'm trying to say is that, if you have no-one to your avail who is familiar with programming ladder, and your programming skills are indeed what you say they are, I would highly try to discourage you to change the ladder program yourself.

    I think that in your situation, it is more feasible to go with a hardware solution instead of software. My suggestion would be to install 2 safety relays. One to interrupt the laser when opening the safety gate and one to turn off the laser when there is no "RUNNING" signal.

    The "RUNNING" signal should be readily available at your controller's connection terminals. Beware however that this output could have been replaced with something else by changing the ladder program. The as-built schematics of your installation should contain all the information needed for a certified industrial electrician to implement this.

    Question: do you have a procedure to go through when something goes wrong? Some kind of "reset job"? Because when something goes wrong when the laser is turned on, it should also return to the off state when the robot returns to its home position. So, one of the first lines in this reset job should be "DOUT OT#(12) OFF".

  • Yaskawa Motoman DX100 communicstion issue.

    You could try to ping the controller and the pendant. It is not really a solution but a way to pinpoint the fault.

    Add a network switch in between the controller board and the pendant. Set your computers IP address to 10.0.0.3 and the netmask to 255.255.255.0 and connect it to the switch. Then open a command prompt and type "ping 10.0.0.2" or "ping 10.0.0.4". When you can't reach 10.0.0.2, the problem is in the controller. When you can't reach 10.0.0.4, the problem resides in the PP, cable or connectors to it.

    In this, I presume that the IP addresses of the DX100 and the DX200 are the same. If you are not able to reach either one of the IP addresses, my presumption might be off.

Advertising from our partners