The system had been functioning for around 2 years, it just started happening one morning. There were PM's over the weekend replacing fans but that was the only changepoint.
We ended up swapping out the servo amplifier and that corrected the issues. Would still be interested if there was any insight on root cause, but we are back running.
My only thought that the servo amp was on its way out, and turning in that direction required slightly more force than the other so it started on that side.
We have an NX100 that has a trunnion positioner giving us a 1105 System Error (Servo) [2007]. We cycled power and tried reseating the axis control card though the alarm still occurred, but only when turning in 1 direction at full speed. We reduced the speed of the trunnion in that direction and this stopped the alarm form occurring for now.
Any ideas on what could be causing this and why it was only occurring in 1 direction and at max speed?
Hello everyone, shock sensor errors on Fronius are usually related to the hose package. One of the shock sensor connection cables in the package may be damaged, so it may cause a lack of contact at some angles. If you measure the short circuit inside the package, you can get an accurate result.
We ended up running a new communication cable to the robacta and changing out the crashbox itself. It has been good since then. I have a feeling it was probably the communication cable, though it was causing some significant downtime so we just swapped out both and have been good since.
Awesome, thanks for the reply. I will look into this. I had also noticed that the connection to the wire feeder was a little banged up so going to replace the wire feeder as well.
Do you think its worth swapping out actual shock sensor or as you said its a pretty basic part?
I have a Yaskawa MA1400/DX100 that uses a Fronius TPS3200 CMT power source with robacta drive and a through-arm "Crashbox CMT-PAP (44,0350,2854)".
I am getting frequent shock sensor faults on 1 specific robot (code 4110 SV#1). These alarms are not due to actual collisions with the robot, most are with the robot doing a general air move and are not the same spot every time. A lot of them are even when the robot is returning to its home position (within inches of home).
I am planning on swapping out the crashbox this weekend, though was wondering if there is a way to adjust the sensitivity on these. Or if there could be something else causing repeated shock sensor alarms. I am not able to find a very useful manual online either.
Any help would be appreciated.
Wow that's alot. Ya the ground sounds like a good place to start. Good luck to you. I'd be interested in an update when you find and fix the problem. We had an issue with the liner running to the feeder from the barrel was grounding out on a mounting plate for a wire straightener that was causing arc start faults. I had to insulate the plate from the liner.
In a different circumstance i had the power cable rubbing on the robot when the robot was in one station and it was grounding out, in the other station the cable came from another direction so it wasn't rubbing. I was getting weld start issues on one station and not the other.
Still investigating the arc start faults, though I found a couple things that have helped.
1. Some of the welders had a background setting enabled for ignition timeout which cuts off power if an arc isn't established in a set amount of wire fed.
2. All the robots had the Feeder Creep setting (soft start) enabled which feeds wire at a slower speed when starting the arc. I have disabled this for now which has helped, I assume be breaking off any silica slag.
Ya I'll give an update once we find the underlying issue with the arc start faults.
Have you tried modifying that arc start in anyway? Torch angles, start Position or in the arc settings or is that not allowed?
Making any of the changes you mentioned doesn't seem to have an effect on the arc retry working on not. We are able to fix any reoccurring arc start failures on specific welds, but nothing seems to make the difference with regards to the arc retry.
As an example we have a cell with 2 robots. Over 2 shifts (20 hours) Robot 1 has attempted a restart 26 times, where as Robot 2 has attempted 0 retries. In this time Robot 1 has had one arc start fail fault, and robot 2 has had six. Arc start files are set up the same between both robots.
I am working on reducing the number of restarts needed (most likely a ground issue), but along with that being able to get the retry working will greatly reduce our actual faults.
Is it always the same weld start or does it happen on different welds
With regards to the arc retry not triggering it seems to be specific welds. In the sense that if an arc retry doesn't trigger for a certain weld then it never seems to. Though its hard to say for certain, because if it does trigger then it probably continues welding without throwing out an error so we won't be able to see that.
I try to eliminate the reasons for the arc start faults. Welding into another weld instead of starting a weld at the end of another helps too.
Thanks for the info. We are also looking into the cause of our arc start failures (grounding issues, tip wear, arc end conditions). Though with the fact a cycle start will usually restart the process with no further issues, I want to ensure that the arc retry is working as intended. The function is that anytime there is an arc start failure, the robot will retry the weld a designated number of times before faulting out.
The biggest issue is that any time we have any fault during welding we automatically call QC to confirm everything is ok on the part. This turns a quick fault reset into 5-10 min of downtime while waiting for QC. So I want to get the retry function working as intended so we can avoid faulting the robot and requiring the QC call.
I have confmed that the ASF's for the welds where the retry is not being trigger do have retry selected.
We are using CMT with Robacta Drives so consumables are always an issue lol. Though I don't think that's causing this issue because as soon as we fault reset and cycle start, it starts welding again first try and goes for another 200+ welds before any other issues.
I guess I also want to confirm that if arc retry is selected for the specific weld, any time we receive a "Missing Arc Start Confirm" fault that a retry should be attempted.
This is happening on robots with and without hyper start enabled (static start only), and the fronius SFI disabled on the pendant.
We are experiencing many "Missing Arc Start Confirm" alarms. These do not always trigger an ArcOn Retry and will fault out after the initial attempt. Then upon fault reset/cycle start the weld will start normally. Other times the retry functions works as intended and after 1 or 2 retries the arc establishes and we continue with no issue. The welding power source on these robots are Fronius TPS 3200/4000.
Should a retry happen anytime we have a "Missing Arc Start Confirm", or are there other conditions that determine when a retry is done?
There was actually no alarm on the robot at this point. We were able to reset the alarm from the HMI and continue running. This picture was taken while the robots were running. But the Teach pendant was frozen and still displaying both the alarm and error. The cell has been running for the past day with the pendant frozen like this. We only restart the controller if we need to jog the robots or something.
When Error 1111 is triggered this does not stop the system and the robots continue running. Sometimes we can hit cancel to clear the error, though sometimes the pendant is frozen and requires a restart.
Adding a picture of the faulted/frozen pendant. The error 1111 seems to be a comms issue from the TPS welding power source, though it doesn't interrupt anything and we can continue running. The primary issue is that sometimes this error causes the pendant to completely freeze.
Experiencing an issue where the Teach Pendant periodically freezes. Only happens when we receive a TPS 1111 error (error from fronius TPS power source). Sometimes we are able to clear the fault, other times the teach pendant is completely frozen and requires a controller restart. There are 3 DX-100 controllers connected to this pendant.
Any insight would be very helpful.
Hey,
A-B GuardLogix. have all of the IP and I/O sizes set up. The issue is when trying to reset ownership, it says that the SSN has not been configure so it cannot reset ownership. Is there something on the robot I need to do first to allow the SSN to be set?
The Tech came in and got the option loaded. Though I am now struggling with setting up the safety fieldbus comms. I have it set to Virtual mode to all me to function, though I'm not sure how to set up the safety comms.
Ok that is what I thought, thanks for confirming. Do you know if it will just be having them send a new file over, or the best way to get that added in? I'll have my customer contact their sales rep to get that process started though.
I am working with a customer who has said they ordered Ethernet/IP Safety with a YRC1000 controller. I am not seeing this option enabled anywhere on the controller, but I just want to make sure I'm not missing it anywhere. The only thing i'm seeing is under Optional Functions > EtherNet/IP (CPU Board) > EtherNet/IP (CPU Board Details > the EtherNet/IP Safety = NOT USED.
I don't have the ability to change this so I assume that means this option was not included? Or is there a way to enable this function?
Hey,
The external hold is control by the signal #40067 or SIN#0048 (Specific output page 6). This signal is manage in ladder program. You need to verify the wiring of your plc.
Thanks, I ended up jumping out the external hold from the ladder logic until we can get the PLC wiring fixed.
