It sounds like we have different controllers. I believe you may benefit more from having a manual so if you share your email i can share the manual i have with you on resuming a prog after a fault during a weld.
Posts by latendal
-
-
For whosever is reading this and has a similar problem. The MP60 F1 fuse like all other fuses in the rj2 controller i believe uses deflection on the internal pins holding the fuse thread to determine when the fuse is blown. If you wish to adapt any of the fuses all you need do is weld the equivalent fuse to internal pins and use a non conductive material to eliminate deflection in the pins.
The downside to doing this is you loose the ability for the system to detect future fuse burnouts. -
Four fuses burnt, i finally figured out that the issue has been with my CRM2A cable. I believe it created a short on some of it's I/O pins which then kept burning fuses. I fixed that and now i can inch forward/backward with all controllers and i do not expect welding to be any different.
Thanks again for being so helpful.
-
I am quite new myself working with Fanuc robots and presently i'm using an rj-2 controller. Not sure which you are using but i've anticipated something like this with the welding robots i'm setting up and how i've overcome it is by taking advantage of the error recovery function option my controller provides. Do you have manuals!? You may want to look into that!
If you are working with an rj-2 controller i can provide you steps how i did this. (NB: At this point I've only been able to simulate the actions of error recovery)Good luck!
-
As racermike has suggested, i believe you have Quick Menus enabled too. I'm currently working with an rj-2 controller and QUICK/FULL MENU is option 6 on my FCTN menu. If yours doesn't correspond to 0 or 6 you may need to read all options displayed and find the QUICK/FULL MENU option then press Enter on your teach pendant or check to see your controller doesn't require a sign in. #HappyProgramming
-
Shipping to our facility is way more expensive than purchasing a couple of fuses(F1:MP20) hence we broke the fuse casing, took out the burned out one and soldered a 2A, 250ACv fuse to the fuse casing leads. I have observed a few things.
1) If process I/O board is connected without F1 fuse, the alarm status indicator red light for burned fuse on process I/O board is off
2) If F1 fuse is substituted with self made fuse as described above, alarm status indicator red light for burned fuse on process I/O is on and the fuse burns when weld I/O commands (e.g. inch forward/backward) are sent out.Noteworthy: Connectivity test on self made F1 fuse indicate i have a travel path for current
-
I will try this but in order to do so i need to find a way to get my fuses working. Shipping to our facility is way more expensive than purchasing a couple of fuses hence we broke the fuse casing, took out the burned out one and soldered a 2A, 250ACv fuse to the fuse casing leads. I have observed a few things.
1) If process I/O board is connected without F1 fuse, the alarm status indicator red light for burned fuse on process I/O board is off
2) If F1 fuse is substituted with self made fuse as described above, alarm status indicator red light for burned fuse on process I/O is on and burns when weld I/O commands (e.g. inch forward/backward) are sent out. -
I've been able to play with an F1 fuse and was able to restore weld commands on the rj-2 that was in good order before i swapped its Process I/O board with the faulty RJ-2. I replaced the F1 fuse in the original-'faulty'-RJ-2 and it keeps blowing fuses.
Still looking into why it is doing this. There isn't much information in the manuals as to what could be causes of the fuse being damaged (On the process I/O PC board that is).
-
Thank you for mentioning the LED's on the Process PC board. I just found Fuse1 on the Process PC board is blown on all faulty controllers. We are taking steps to have fuses replaced, however I'm not clear why the fuses would've blown in the first place. The situation is indicative there could be another problem i haven't discovered yet.
I do hope replacing the fuses resolves the issue if not wish me luck i can find the bug/cause. (FYI: I did check the procedure for replacing the Process PC board/ fuses from the manual and its as simple as powering off, removing component, replacing component, and powering up)
Thanks again for all your help.
-
Thanks for the question about purging gas. Not sure why i didn't think of that
I have done a couple of things now and these are the results
-Tried purging gas on 'bad' rj2 and that didn't work
-Swapped Process I/O between 'bad' and 'good' rj2 and couldn't get any Weld Output working (purging gas, or cold wire feeding) on both rj2's. Weld I/O displayed signals did turn on. Wrote weld progs for Purging gas and that didn't work on both controllers either.There is now a new twist with my setup. I re-swapped Process I/O boards to their original respective rj2's and now i can't get even the 'good' one to cold feed wire or purge gas anymore.
I hope i didn't fry something by swapping. I'd look up maintenance manual to see if i get pointers. If you have any yourself that'd be much appreciated.
.. and I am running Arctool Software V 4.30
Thanks again!
-
Also if i were using my RJ2 with the S420i and had no need for welding is there some system config i can fiddle with to disable all weld I/O completely!?
-
Yes when i press wire+/- from the TP i see Wo4 and 5 go on respectively from the Weld I/O screen.
I created a program and pulsed WO4 and still no luck getting it to feed.
I have been able to establish both wire feeders work because i checked with a second RJ 2 and i was able to cold feed wire from TP.
I haven't attempted welding as i presume this would be a futile effort if i can't even cold feed wires.
Thanks for all your help and pointer thus far, when you say a macro in the Arctool software is there some way to check its installed!?
-
Thanks for your suggestion, I have checked my Weld Output and Cold FWD is linked with WO4 and BCK is linked to WO5.
My boss just mentioned these machines were used as slaves before we acquired them. I haven't found any piece of information at this point that suggest this would affect cold feeding wire especially as they controlled independent welders.
The Manual suggest ICOM3 should be set to a B position for an arc to be detected however my opinion is this should be independent of feeding wire so not sure if i should even invest time in checking this. I should probably try measuring the voltage output of WO4 and 5 to be 100% sure my CRW1 cable is in good order.
Besides these i'm not sure where else to turn for a solution
-
Hi guys,
I'd really appreciate it if i can be pointed in the right direction.I have 2 RJ2-controllers connected to two independent powerwave 450 welders. The problem i have is i can't seem to get one of this controllers to induce Cold feed command (+ve or -ve) on either powerwave welders and i can't seem to figure out what the problem might be. I have done a few things thus far.
-I used my second controller (non faulty RJ2) on both PW450's and they all work fine which tells me the problem isn't with the PW450's
-I have performed a controlled start on the first controller (faulty RJ2) and reconfigured the welder in use (first to general and back to PW450) so I/O ports can be reinitialized but this itself didn't resolve my issue
-I compared Welder Equip, Setup and Prog parameters and Variables on both controllers and they are near identical
-I performed a connectivity test on my CRW1 cable and it appears fineI have a strong feeling there probably is a system variable i just need to change values from a true to a false or vice versa for the system to work but at this moment i have no clue what this is (if at all this is the cause of my troubles)
-
I have fiddled with UOP and Digital Configs yet i get no meaningful results (as in: if i reassign signals to a rack and slot i believe is incorrect i can't send signals to the controller and assigning them to a rack and slot i believe is correct i correct, i can't send signals out of the robot)
I've done some test and i had some very odd results. I'm using four of these controllers and for two of them i can receive DI signals but can't send out DO signals. For the remaining 2 controllers i can send out DO signals but can't receive DI signals and there is a twist. For these last 2 controllers they send out DO signals whilst being off (that is controller isn't powered) connected to a plc as shown in the schematic, and i measure 9.3V across any DI signal and a com port (e.g. CMDENBL and COM-A4)! So odd!!!!
I'm not sure what to think now because the nature of the anomalies look a little too ordered for me to blame it on the controller being broken in some way yet i get a feel this might be the case!!
-
kluk-kluk attached is the wiring method i've used.
doctor C unfortunately these are the options i have on my teach pendant
Menu -> System-> Variables
Menu -> System -> Motion
Menu -> System -> Axis Limit
Menu -> System -> Master/Cal
Menu -> System -> ClockI'd presume Enable UI signals is something i'd find under System Variables. Would you happen to know the exact variable i need to edit (e.g. $ETCP_VER)!?
-
The teach pendant shows the status of CMDENBL signal to be ON, however peripheral device can't read this signal!
Can the teach pendant indicate a signal is ON and not send any output to peripheral device when the Signal is UNSIMULATED (i.e. base emitter of transistor in output circuit not forward biased)!? If so how do i get it to send a signal to peripheral device!?
Is there a way to check if the transistors in output circuit is fried for DO signals on CRM2A port!? If so how do i go about checking!?
Thanks!
Noteworthy: port rack and slots have been verified, can send DI signals to controller, wiring triple checked
-
Hi
I am working with an RJ2-controller and at the moment trying to establish comm with a DL205 PLC (http://www.automationdirect.com/static/manuals/d2user/ch2.pdf - Page 31) I am using the sourcing wiring config to establish comm with the controller, however i am at this point still unable to read the DO signals from the controller at the PLC end. When i send DI signals to the robot, they work perfect!! I've monitored the outputs from my teach pendant and it indicates signals are being sent out. I am at the completely confused and not sure what to do next. i thought maybe input terminals at my PLC were fried however i checked by measuring the resistance between comm and PLC input and it looks right. Not sure how i can check for the robot but i tested multiple signals and ended up with no result which landed me to the conclusion it most probably isn't/wasn't a pre-existent condition. I have attached a rough sketch of my connection if anyone can point out what i may be doing wrong, i'd be more than grateful. -
Thank you!! The problem seems to be solved.
We suspected something of this sort earlier on and tried to add a new motion group defining the mount to be at 90deg through a controlled start but once the motion group was created and a cold start initiated we got a SRV-021 (Servo SRDY off error) on all axis in the new group (GRP2). Couldn't figure out why and once we deleted this second motion group everything went back to normal.
I realize defining and using a user frame in our current mount position can solve the problem with the world frame, however it'd be nice to know what we might have been doing wrong to get the servo error. Thanks!
-
I am trying to setup a program on my controller for production, however when i put the robot in certain positions(orientations) i get an OVC alarm. I've checked the phase to phase voltage at the servo amplifier and its well over 170VAC, also checked the brake connector and it seems to be fine.
I've considered restricting motion on the J1 axis by defining a motion group that excludes it because it is the author of the OVC alarm in the hopes the brakes would be applied to the j1 axis and prevent this motor from drawing more current but even this is proving very challenging as i do not have the software installation manual
I am literally out of ideas on what to do next!