Welds perfectly fine in T2 with the teach pendent. Switch to auto, 100% speed, weld enabled, the robot goes down into place to weld, and it can't even begin the weld. "Arc- 013 Arc Start Failed" error comes up.... Again... It welds perfectly fine 30 seconds before this when I welded a part with the teach pendent... Been at this for 8-10 hours now. Trying all kinds of things. Cycling the power, checked ground cables, cleaned parts with acetone. What am I missing... Maybe some sort of electrical issue? Idk... Please... Someone save the day.
Posts by Chase
-
-
Thanks for correcting my mistake, noticed I posted to the wrong area.
-
I believe our robot to be drifting. We have a chuck bolted to an xy-table bolted to our rotary table. The robot simply brings a tungsten in between two surfaces and starts pulsing as the rotary table spins. I ran about 80 parts before the weld begins to stop attaching to one surface as if maybe the robot is slightly drifting over time. I feel that I am just about constantly touching up points. Any ideas to test for drift? Almost feels like there is too much slop in the end wrist joint or J5 I believe.
I already double-checked our fixturing. Indicated the chuck, and it has remained dead zero over several hours of running, so shouldn't be our fixturing.
-
3 Motion groups. Group 1 is the robot itself. Group 2 is the fanuc xy rotary table. Group 3 is an old mori seiki pallet changer out of a mh-50 cnc in station 2. I'm welding in station 1. I'm spinning group 2 while holding the robot tungsten still in group 1. Then trying to shift group 1 up in the Z-axis. For PR[13] and PR [14], I recorded those as the weld start and weld end positions. So PR[13] was recorded as the weld start, and PR[14] as the weld end, which is exactly how it was done for my other shaft weld program. In that program, I have the same exact program but it shifts in the x-axis 4 mm at a time, to lay beads down the length of an armature shaft. For that program though, I'm using PR[2] and PR[3], but using the same concept, PR[2] is the weld start, and PR[3] is the weld end. I copied everything the same, but changed the position registers to the next unused ones in my list which are 13 and 14, and taught the new weld start and end positions in space, and changed the 1s to 3s.
-
Attached are images of what I've programmed.
Specifically, I'm at a loss of what's going on with lines 19 and 20 with the red 3 values.
19: PR[GP1:13,3]=PR[13,3]+4
20: PR[GP1:14,3]=PR[14,3]+4
I'm attempting to set a looped program where it goes through and adds 4mm to the Z axis as many times as I tell it to.
However, I can only get the robot to cycle with an offset in the x-axis and y-axis using either a 1 for x or a 2 y where the 3 currently is in lines 19 and 20. Placing a 3 in there instead of a 1 or 2 doesn't work. I assumed a 3 would be for the Z-axis, as 1 works for X, and 2 works for Y, I feel it would be logical that 3 would be for Z. Apparently not? I get an error when I attempt to run the program and it gets right up to where it's about to index over. It throws a code "INTP-204 (PROGRAM TITLE, 19) Invalid value for index"
Again, it works flawlessly when either a 1 for the x-axis or a 2 for the y-axis are put in where the 3 is. As soon as I put a 3 in there, the program always stops right before it executes the first index. Any ideas would be highly appreciated. The goal is to have a program that brings the robot down into place to place a weld on a shaft that rotates on group 2 (rotary table). Then, as soon as the first weld is completed and the gas post flow is done, I want the robot to back up slightly higher and higher essentially laying weld after weld right on top of the previous weld and the previous weld, slowly building up a surface, almost acting like a 3D-printer. I believe I am close with what I have.
-
I found someone else’s thread on here. Followed someone’s commented procedure. Pressed the emergency stop on the teach pendent. Did a reset, and then was able to clear the chain alarm. Now I can program.
-
To get the full background, I’m not sure if these other alarms could be related, but I was running a welding program in auto last Friday, at the end of the day, literally (luckily) only had one more part for the day, and had an error pop up that read “SRVO-372 OPEMG1 status abnormal.” I went to the power cabinet and I physically turned the power switch off, left it sit over the weekend, came back on Monday, turned it on, and the alarm was gone. I ran all day Monday no issue in auto. Fast forward several days, to tonight, Thursday night, and I literally ran a single part on my rotary table in T2, now I switched over to this other station for the robot cell, to begin programming for a new part to be ran in auto, and the SRVO-372 OPEMG1 status abnormal alarm came back up. Did a reset and function abort all. Turned off the power at the cabinet. Turned it back on, and that alarm is gone, but now a different alarm won’t go away and won’t let me even program in T2, it reads “SRVO-230 Chain 1 Abnormal 0,0 (1)” I’ve tried cycling power at the cabinet, and with the teach pendent, and with the teach pendent in a cold cycle, nothing is working to get rid of this alarm. Trying to hopefully get this figured out tonight to try and finish an hour of programming to get a program ready to run for someone in the morning.
-
I have a program that welds two inside welds and two outside welds on a part. The two inside welds always do great. They never get porosity. The two outsides ones, mainly one of them in the same spot every time at the start of the weld almost always has porosity. I’ve checked my gun angle, wire length, travel speed, wire speed, I have the correct gas hooked up, I’m at a loss. I managed to change the angle slightly and that seemed to produce one perfect part after 20 bad ones. Then, without changing anything, the very next one, that I assumed would follow suit and be perfect, had porosity in the same old spot… so confused…
-
Also got a “SVOFF input” alarm as well.
-
I’ve never seen this code before, curious as to what might have happened? I’ve been running production, 300 or so parts in AUTO, no problems, just went to hit start again and this alarm came on. Running quick cycle parts, not sure if somehow I caused an issue by running a ton of parts way too fast? Not even sure if that could cause this error, just thought I’d include it just in case.
-
No idea where to find the “pulsecoder” battery?
-
Thanks everyone for the help! We took all the pieces to our metallurgist, sure enough the rod had a high lead content, meant for being machined easy, not welded. The tube came back as a low carbon content steel, which is why that had a much easier time fusing to the base plate. The rods registered as 12L14, which are going to be replaced by low carbon steel rods. Thanks again
-
I suspect they may be just two dissimilar metals that don’t want to join. Even mig welded by hand and tig welded by hand leave a crack after grinded down slightly.
-
Here’s the part with a crack every time.
-
Here’s the part with no crack
-
Anyone have any ideas as to why the part towards me fuses fine with no filler and doesn’t leave any cracks 8/10, whereas the part on the far side leaves a crack every single time with no filler, seems just about the same clearances/tolerances, really odd. Any input would be appreciated. Trying to weld both in the same program rather than setting up a chuck to center a part at a time and using filler.
-
Thank you both, got it to work!
-
It invalidates the point as a safety measure. If it left the point as is and you ran it, the robot would attempt to move that distance from wherever it was, likely resulting in a crash.
If you punch in 100mm in X and zero everything else, the robot will move from wherever it is, to +100mm X in the active user frame. So if it started at 500mm X, it will end up at 600mm X.
Just focusing on lines 14 and 15, would it look something like this? Where I put the INC statements at the end of the weld start and the weld end?
-
That or you could use the INC motion modifier. Tells the robot to move from where it is incrementally.
How would I go this route exactly? I made a copy program where I could play around with this. I found where I could include the INC at the end of my weld start position statement, and at the end of my weld end position statement. I'm not sure I'm incorporating it correctly. Right when I inserted the INC after the weld start, for example, the number for that position highlighted yellow and the text turned to red, it said the position was invalidated, and it let me enter values for the position. If you could go into further/more specific detail on an example of how to program it that would be much appreciated!
-
Use an offset with a position register.
...
5:
6:
7: R [1: SHAFT_TIG_PASSES]=0
8: L P[8] 944.9inch/min FINE
: Weld Start [9,1]
9: PR[2: SHAFT_TIG_START]=LPOS
10: L P[9] 944.9inch/min FINE
: Weld End [9,1]
11: PR [3: SHAFT_TIG_END]=LPOS
12:
13:
14: LBL[1:LOOP]
15:
16: PR[2,1: SHAFT_TIG_START]=PR[2,1: SHAFT_TIG_START] +1.5
17: PR[3,1: SHAFT_TIG_END]=PR[3,1: SHAFT_TIG_END] +1.5
18:
19:
20:L PR[2: SHAFT_TIG_START] 4724inch/min FINE
: Weld Start [9,1]21:L PR[3: SHAFT TIG_END] 4724inch/min FINE
: Weld End [9,1]
22:
23: R[1: SHAFT_TIG_PASSES]=R[1: SHAFT_TIG_PASSES]+1
24:
25: IF R[1: SHAFT_TIG_PASSES]<10, JMP LBL[1]
26:
27: R[1: SHAFT_TIG_PASSES]=0
28:
29:
...
I tried this, and it seems like my Group 2: Rotary table moves in the x-direction for the value of 1.5 and not my Group 1: Robot. Any ideas on how to make the 1 in PR[2, 1] and PR[3,1] represent the x value for the robot and not the rotary table? I'm guessing it's because between the weld start PR[2,1: SHAFT_TIG_START], and the weld end PR[3,1: SHAFT_TIG_END], the only values that change are the group 2: rotary table values, and not the group 1: robot values because the robot stays still while the table spins.