Posts by mbull

    We had an A7020 error on our VR-006, and it wasn't a battery error (they were changed sometime in the middle of the error coming up intermittently). This error from my understanding has to deal with the power being received by the servo amplifier (or at least that's what Miller told me). In our specific case, we had a 3 phase circuit breaker that was starting to fail. You will probably not see the error for all of the amplifiers, only one. From what I was told, the controller checks the voltages at the amplifiers in sequential order. If it sees an issue with one, it will error out without bothering to check the others. Seems silly from a diagnostic perspective, but that's just my opinion. :neutral_face:


    Check the voltages at your three phases coming in, and going out of the disconnect switch. If those are both fine, I'd follow them to the amplifiers and check that they are receiving the proper voltage. If your controller is anything like ours, the compartment on the back side of the controller would have the amplifiers mounted to the panel that pivots outward.

    I wouldn't think that would. I think the full text of the error message is probably needed to get a better idea of what's going on. Can you check the error history?

    Hi all, I was wondering if anyone happens to know at what encoder battery voltage a BLAL alarm activates at?


    I'm curious, but not curious enough to hook a DC power supply up to the robot. :grinning_squinting_face:

    I don't think its been mentioned, but how about release notes for robot software auto-updates?


    It'd be really nice to know if the update that I'm about to apply can be expected to fix a given issue, or where I should be keeping an eye out for any possible changes. (Should I change my written operating instructions since a workaround isn't needed or might have an undesirable effect if said instructions are followed?)


    P.S: "General bugfixes" does not count as release notes.

    If I had to guess, the keys should probably be the same as Roboguide.


    The TP runs its own windows OS. The membrane keys are just sending standard QWERTY button presses to windows, and then it’s remapped for use within the software that is responsible for displaying the TP interface.

    Are you providing the e-stop board with an external source of 24V? If not, check on your e-stop board for a jumper between EXT24V and INT24V, and one between EXT0V and INT0V.

    A couple things I figure I should add. The first being that we are using the digital output on the keyence to detect the part. The second point is more of a question than anything... Could TAST be correcting for any error in mastering? I wouldn't think so, but then again I'm out of ideas. Should also mention that all of the zero degree lines stamped into each axis appear to line up perfectly as far as I can tell.

    Hi everyone. Our Arcmate 120iC/12L has me stumped. We're working with an OLP software vendor (non-Fanuc) to calibrate our virtual cell, but we're having issues once we try using touch sensing, or at least that's where we believe our error lies. I should also mention that this OLP software uses calls it's own .ls program to do the searching and offset generation using the skip functions.


    I'm trying to recalibrate the TCP of our keyence IL-600 to ensure our TCP is accurate. It seems that each time I recheck the TCP by having the robot move to the taught positions for TCP setup, at least one is off by 2-4mm distance wise. The dot is right on the center crosshairs of my target. (Literally just a target I generated from here, printed out, and taped to the top of the reamer station.)


    I'm teaching the TCP as a new UTOOL, so I don't have any effect on production programs, and we haven't had any major issues with production welds. Doe's anyone have any tips, anything I can try? Is it possible that the mastering of the robot is off? I would've thought that bad mastering would have had a significant effect on some of the parts we make, as some have the robot pretty close to the edge of the work envelope. The only other thing I can think of is that there may be an issue with the OLP software's search method, as all of our old programs use the fanuc native touch sensing routine.

    Another thing worth considering is if you have a linear move that is close to your last taught point, but with joint angles that have the robot in a different posture. The robot may try moving fast enough to error out on an axis speed limit, and if it's already moving fast enough the sudden stop may trigger a collision alarm. What is the specific error you are getting, and how does it appear? What I mean is are you getting a yellow warning like this one, or just an alarm in the message window and fault history?



    CdsHqqF.jpg

    Just wanted to update this with something else I just came across.


    Fanuc PN: A05B-2255-K204 which is described as "PROTECT SHEET KIT WITH X711"

    It appears to be five of the molded screen protectors, with what appears to be a gasket of some sort. It matches the general shape of the portion of the screen protector I highlighted earlier with arrows. (Sorry I'm not going to share a photo I've only been able to find in the crc site.)


    I couldn't find any seemingly relevant part with X711 in the part number, but I did find one ending in X719 described as "GASKET U FOR LCD WITH TOUCH PA". PN: A290-7213-X719. My best guess is this gasket goes around the screen on the back side of the pendant front case half to keep debris from getting inside from any gap.


    So I guess I don't have to be as concerned by not having the molded screen protector. :thinking_face:

Advertising from our partners