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
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.
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.
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?
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?
It seems to me that your files are in the root folder of your FTP server (content of / @ 192.168.0.20). Did you try to leave the "DIRECTORY" field of the FTP profile empty?
What kind of data do you mean?
Let us know what Yaskawa says. I'm curious.
They want me to make a CMOS.BIN backup. The robot is occupied with a production run for the moment so I will have to get back to them next week.
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...
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?
While D001 =1 AND (IN for servo on) = ON
DOUT OT12 ON Laser ON
SET D001 1 (laser should turn on)
SET D001 0 (laser should turn off)
SET D001 1 (laser should turn on)
SET D001 0 (laser should turn off)
END WHILE (disables the function)
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!
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.Code
0001 GETS LPX000 $PX001 0002*TOP 0003 SUB LP000 LP000 0004 IF( IN#(9)=ON ) THEN 0005 SET LD000 -1000 0006 ELSE 0007 SET LD000 1000 0008 ENDIF 0009 IF( LB000=0 ) THEN 0010 IF( IN#(1)=ON ) THEN 0011 SETE LP000 (1) LD000 0012 ELSEIF( IN#(2)=ON ) THEN 0013 SETE LP000 (2) LD000 0014 ELSEIF( IN#(3)=ON ) THEN 0015 SETE LP000 (3) LD000 0016 ELSEIF( IN#(4)=ON ) THEN 0017 SETE LP000 (4) LD000 0018 ELSEIF( IN#(5)=ON ) THEN 0019 SETE LP000 (5) LD000 0020 ELSEIF( IN#(6)=ON ) THEN 0021 SETE LP000 (6) LD000 0022 ELSE 0023 TIMER T=0.02 0024 JUMP *TOP 0025 ENDIF 0026 IMOV LP000 0027 SET LB000 1 0028 ELSEIF( IN#(1)=OFF AND IN#(2)=OFF AND IN#(3)=OFF AND IN#(4)=OFF AND IN#(5)=OFF AND IN#(6)=OFF ) THEN 0029 SET LB000 0 0030 ENDIF 0031 JUMP *TOP
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.
Ok, thanks for the info
I think you would be more likely to get a correct answer to that question on a "welding" forum rather than on a robot related forum.
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 SET LD000 63948 0002 SET LD001 -295875 0003 SET LD002 -63009 0004 SET LD003 444067 0005 SET LD004 168215 0006 SET LD005 -188758 0007 'home position 0008 WAIT IN#(4082)=OFF IN#(4082)=HOME VALUES ACK 0009 FOR LI000 = 0 TO 5 0010 SET I050 LI000 + 1072 0011 SET D050 LD[LI000] D050=HOMEPOS TMP 0012 DOUT OT#(4082) ON OT#(4082)=HOME VALUES SET 0013 '***** 0014 TIMER T=0.40 0015 WAIT IN#(4082)=OFF IN#(4082)=HOME VALUES ACK 0016 SET I050 LI000 + 1080 0017 DOUT OT#(4082) ON OT#(4082)=HOME VALUES SET 0018 '***** 0019 TIMER T=0.40 0020 WAIT IN#(4082)=OFF IN#(4082)=HOME VALUES ACK 0021 NEXT LI000 . .
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?
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".
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.