Down the rabbit hole...Who wants to join in the fun?

    Good morning, hope you all had a good holiday!

    IRB6600

    S4C+

    M2000A

    A couple things of note to start with. Tools are my EOAT, wObj's are physical stations that do work on robot held parts or load tables. I can't get a good TCP when programming in new tools. tool0 has a good TCP and tracks well.

    We had a 20+ year tech swing by to check my work, he taught a TCP and it was off, we manually adjusted it till it tracked well. We used that TCP to define a duplicate wObj to one that is already in use. The y axis of the new Wobj is off by over 5 mm in X over 610mm (1mm every122mm) as demonstrated by tracking along y axis in jog mode (not dissimilar from all other wObjs at this location):wallbash:. This makes the use of program displacement difficult at best. The X axis tracks perfectly. How can this be? It would mean the X and Y axes are not Square, correct? (teach points were checked for square 3 different times) It turns out that the robot has been this way since I inherited control and it is causing issues with programming reliably. Notably, it does not seem to cause errors with repeatability!???? Is this just something I need to learn to deal with as a programmer, or is my gut feeling correct, that something is wrong? The Tech felt that something was wrong as well, and we both agree its probably the calibration.:bawling: There is a record of axis 5 being replaced. There is no record of what the new offset should be, or if a new fine calibration was done. All we know is that the offset for motor 5 is different than the sticker on the robot. All other offsets are the same.:gaah:

    As we all know, that could mean a lot of work ahead for yours truly, but also brings up another question. Does anyone know If ABB's "absolute accuracy" software add on even works for S4C+? I was told its the cat's A$$ by the guy who sold the robot to us, but told by others that the bugs were never did get worked out for the S4C+ platform.:censored: Could this be the culprit? If so, What to do? Does anyone have any thoughts or info on this?

    1) I could remove the software, do a fine calibration, reprogram all TCPs, all wObjs and then proceed to adjust all program points in all current programs in hopes that the problem is solved. That mean thousands of program points to move, migrate or force into the right spot. After all this is said and done, it may or may not solve the problem.

    2) Do nothing. Live with the repeatability as is, deal with the P.I.T.A. of initial programming due to the fact that program displacement is unreliable. Although tempting to that lazy corner of my brain, not really an option I can live with for long knowing it could be better.

    3) As Lemster68 proposed in a different thread, write some code to have the computer calculate each pose data set for me as opposed to entering the CAM offsets. A temping option that may or may not solve the displacement issue, but would also require a massive overhaul to the fundamental structure of the existing Main Program and still not solve the problem of poor accuracy when defining TCPS and wObjs.

    Which brings me to the final in the set of current woes. Even after a solution is found to the above there is still the issue of deviation that happens at load. Some times parts shift slightly when being picked up, despite my best efforts to date to get the perfect grab every time. On most parts it doesn't affect much and they fall within tolerances. This part however has a tendency to tip slightly, or rise up on the fingers. The latter is by far the easier of the two to deal with, using a LVDT and doing a pSearch to create a Z offset to apply to the appropriate procedures (I may be asking for pointers on this as well). The former is where I have need of more experienced minds than mine own. Is it possible to use an LVDT to test and record points from a perfect grab of a part as a template to establish a "Good" part orientation? Then find, record and utilize the variance of each subsequent part to automatically modify the orientation of the robot so that it is the part travels along the intended path in the proper "Good" orientation through the next 4 wObj zones ? If so, where is the best place to start reading up on the commands that I will need and does anyone have any experience with this? It sounds great when I say it out loud, but I have a feeling it is way harder than it sounds to get something like that right.

    I told you it would be a rabbit hole. Any company along the journey would be much appreciated!

    Kindest regards,

    Drew

  • Go to Best Answer

    Regarding checking the X and Y tracking, did you use the joystick lock to ensure that there was no deflection of the joystick? Is the robot properly leveled? You might want to see about paying for a service call to do the Cal Pendulum on it. How does the robot track in world coordinates?

    X and Y axes must be square to one another, could be a tilt in the Z axis.

    You could take a chance to do a fine calibration with axis five, see what the pre and post cal offsets are. Of course, take note of the value that is in it now. Then try to teach some TCP's and see if you get better results.

    I don't see a need for AbsAcc needed unless you are talking about significant payloads over a large area of the work envelope.

    Your last issue is one that would be best addressed by a vision system if you cannot get a good mechanical resolution. I.e., crowders of something that could make the pick repeatable.

    Yes. The Joy was locked during the test.

    The robot may not be properly leveled, I did not install it. Shouldn't the computer be able to account for the difference even if it isn't? I doubt it can be moved if it isn't level. Would the Cal Pendulum adjust for this? I would have to check the World Co-ordinate tracking.

    How would the Z axis tilt force the Y out of square with the X? The X was as perfect as I have ever seen no noticeable change in Z. Y seemed to track Z fine it was X that was out on the Y.

    Is it possible to do a fine cal w/o doing a rev counter update?

    The cage is huge, the actual work envelope is probably 2.4m x 3m, or up to max 2.4m out for 350 degrees of use. mostly about 1-1.3m out. Payloads are not huge <80

    kg but forces applied get pretty large sometimes.

    I am not familiar with the term crowder, but assume it is a movable spacer of sort that would help center or hold the part in the proper orientation? I was thinking of putting some spring loaded plates on the fingers of the grippers to keep the part from creeping.

    The robot has no way of knowing if it is not level. I think that Cal Pendulum might take care of leveleing or tell you to level better. I have not witnessed many, maybe been around for one.

    A Z tilt could make it leek like one axis track perfect maybe, but another look off, but not make them off perpendicular. You would see some ascension or descension as well in the "off" axis.

    You would put the axis at zero position to fine calibrate. That will set the cal offset and set zero right there. So if it wants a rev counter update after restart it is already there. Pretty much a must for that procedure. Did I ask you about the commutation offsets?

    Depending on that robot models' payload capacity, that is not a negligible load. I am assuming a longer robot arm because of the work area you described. AbsAcc accounts for the deflection of the arm due to the load, in most cases would be downward. Gravity, you know. I still think it would be unnecessary to fix the issue that you describe.

    A crowder could be a pneumatic cylinder that shoves the part into a nest or against a stop to ensure that it is located well before being picked up.

    I will check the base with a machinists level tomorrow.

    I see no real change in the z height along the x axis nor much if any along the y???? this is what is baffling me.

    The commutation offsets are all the same as the sticker except for axis 5, it makes me wonder if #3 should be checked as well.

    The robot pay load is somewhere around 205kg-246kg I can't remember off the top of my head. I believe the arm is 2.55_225. Just to be clear AbsAcc is something that is already on the controller, but I'm not even sure it is compatible with S4C+ at this point in time, I've heard conflicting stories.

    Most of the load tables we use have mechanical spring loaded crowders. However, this is a very difficult part to locate due to a lack of datum points, so much so that the company that orders them actually clamps on a ground face for machining purposes!??? Yet another reason this part falls to my lap. As such, it happens to be one of the least well held from the get go, which is what started this whole landslide to begin with.

    On a side note, I checked out the github stuff you guys posted a while back and was wondering if any of that might help with the last portion of the first post? Is what I want to do even possible?

    Sounds like you have a calibration offset issue or a load issue to me.

    Does the robot have Load ID as an option? If not, do you have an IRC-5 that has the same tool and parts that you can run Load ID with and transfer the resulting update to your TCP?

    I'd try to update the TCP using Load ID if possible first.

    Then update your tool with the part in it as a payload.

    Regarding the Cal Pend:

    It does take the base into consideration when run, so any rotation about either the X or Y axis is part of the calibration process.

    IF the robot has ABS-ACC, and any motor was changed, the ABS-ACC calibration is no longer valid, so it would have to be done again.

    Not only does ABS-ACC compensate for gravity, it also takes friction into account.

    Work arounds:

    If ABS-ACC is on right now, turn it off, reteach your TCP, and see if your results are better.

    As you most likely know, with a large robot like a 6600, and a very heavy payload gravity is going to have an impact on your repeatability in your "long reach" positions, so try to keep those critical points close in.

    When you teach your TCP, I assume you are keeping your orientations very close to what you have done on the prior attempts.. Switch it up to see if this has an impact on how your tool behaves.. I have seen this on lots of 4400s, so you can sometimes move your error to another plane to make it more tolerable to the process.

    Buy a nice digital level, and calibrate it off of the base of the robot for 0 degrees.. Take the T45(?) bolt and rubber pad off, wipe the grease spooge off, and set your level there.

    Run the robot to the calibration position, and put your level on axis 5 using a square.

    How close is it? Way off, you could try and tweak it in until you can get ABB on-site to use Cal-Pend, or ABS-ACC on it.

    Try doing some friction compensation to get rid of the issue.. User's Guide, Topic: Manipulator

    7.14 Defining friction compensation

    Friction compensation can be activated to reduce path errors caused by friction and

    backlash at low speeds (10 - 200 mm/s).

    The friction model is a constant level with a sign opposite to the axis speed direction.

    Friction ffw level (Nm) is the absolute friction level at (low) speeds greater than Friction

    ffw ramp (rad/s) see Figure 29.

    pasted-from-clipboard.pngpasted-from-clipboard.png

    The instruction TuneServo can be used to tune optimal values for each robot axis.

    Note The system has to be loaded in service mode in order to be able to change these

    parameters. See the Product Manual - Installation and Commissioning

    Tuning procedure

    The most straight forward way to tune the friction parameters is to consider one axis at

    a time. Choose a motion which has a characteristic friction “bump” due to a specific

    axis changing direction. Turn the friction compensation on for this specific axis and use

    the default setting for friction level and ramp. Use the TuneServo command to gradually

    increase the friction level until the bump in the path is removed.

    Repeat this procedure for all axes.

    • Choose Topics: Manipulator.

    • Choose Types: Control parameters (Friction comp for IRB6600,6650 and 7600).

    • Select the desired axis and press Enter .

    • Select the desired parameter and change its value.

    • Press OK to confirm the change.

    Parameter Description

    Friction ffw on Activates/deactivates friction compensation.

    Friction ffw level Low speed motor friction level [Nm].

    Friction ffw ramp Friction ramp [rad/s].

    I hope that something useful comes of this..

    Good luck, and don't eat too many carrots!

    • Best Answer
    Quote from Elderwild

    The commutation offsets are all the same as the sticker except for axis 5, it makes me wonder if #3 should be checked as well.

    This is quite likely an issue. It used to be that they would be different, but at a point in time it became standard with all ABB motors to be 1.5708 (from memory there).

    Are you referring to some of the stuff that Rob has on the github?

    #Lemster68 Yes, it looked like some of those procs and Functions could be the right things to get the info I need in order to do "the Maths" that would be necessary to adjust the angles. Individually they look pretty straight forward, taken together they get quite complicated quickly.

    Quote from D_Oster

    Sounds like you have a calibration offset issue or a load issue to me.

    Does the robot have Load ID as an option? If not, do you have an IRC-5 that has the same tool and parts that you can run Load ID with and transfer the resulting update to your TCP?

    I'd try to update the TCP using Load ID if possible first.

    Then update your tool with the part in it as a payload.

    The controller does have LoadID and collision detect, but I don't know if load ID is working properly either(unfortunately I do know that collision detect is working :grinning_squinting_face::grinning_squinting_face::loudly_crying_face::winking_face:). I used it on most of my tools TCP then with payload and the tech said there were some weird results in them. Idon't know maybe its the LoadID itself causing the issues?. Is LoadID compatible with S4C+, or is that why you asked if I had an IRC5(I do not)?

    I'm thinking I might need to check on arm loads and make sure they are correct as well.

    Quote from D_Oster

    When you teach your TCP, I assume you are keeping your orientations very close to what you have done on the prior attempts.. Switch it up to see if this has an impact on how your tool behaves.. I have seen this on lots of 4400s, so you can sometimes move your error to another plane to make it more tolerable to the process.

    We went to the other side of the cell to try in a different spot for a good TCP, no dice.

    As for level, I am having a tech come in and check as well as doing some PM. Going to have him check for backlash and any other mechanical anomaly as well, before moving on with a recalibration. Depending on what we find, loose joints or bad calib, I'll bring up the Tune Servo and Friction compensation.

    Thank you, Thank you Gentlemen! It's a lot to check on, but I couldn't be more thankful for the concise "road map" and directions.

    Ahhh! the joys of cleaning up after incompetence. Just printed out the MOC, there is a list Load_1 thru Load_4 but there is no values that I can tell. Damn, the more I learn, the more I see how poorly this robot was set up from the get go (not blaming the tool, just didn't know it was that dull). Add it to the list of things to fix!

    Com number for irb_5 ( correction MOTOR_CALIB: )

    original= 5.672950

    new= 4.28287

    Going after the load issues first, then on to the the mechanicals and possibly friction. service call is scheduled for 1/11 for a check up and possibly recal.

    Thanks again Lee!

    Edited once, last by Elderwild (December 1, 2021 at 10:05 PM).

    Commutation, or calibration offsets? They are two unique things.

    Do not make the mistake of assuming that those loads are for axis one through four, they are not. They are instances of that parameter. You could make more of them if you want. For the axis required you must go set the parameter USE_ARM_LOAD, then select Load_X. Then it will be set up properly. I suppose that you are saying that there is a substantial mass mounted to some axes?

    Correction, these are the Calibration offsets for IRB_5.

    Where are the Commutation numbers?

    Yes the are what I believe to be Empty Parameters at the moment.

    There is a steel box on top of the arm between 4 and 5 that holds some MAC valves, solenoids and air hoses. It does not rotate with the arm. Compared to the overall capability of the robot it is a relatively small amount of (unfortunately unknown) weight.

    Edited once, last by Elderwild (December 1, 2021 at 10:06 PM).

    Commutation is regarding the alignment of magnetic fields internal to the motor. Resolvers on ABB large robot motors for the last 30 years are factory set to 1.5708 rad (90 deg) from a specific motor position where the fields are aligned for maximum efficiency.

    Make sure all six motors have 1.5708 (remember pi/2) for their comm offset parameter and never loosen or adjust a resolver on a motor.

    Like Lemster68 says, best guess on the J-Box weight is better than nothing. Seemed to bring the CG a little closer to expected whenever I set actual upper arm load for LoadID in the past.

    Quote from Lemster68

    Armloads are a required prerequisite to doing an accurate LoadID. It has been around for a long time on the S4C+ and is accurate when done right. It may even go back another generation or two of controllers.

    Please don't forget to investigate the different commutation numbers for axis five.

    Got an oil change and a Calibration tune up on Sat before last (Expensive oil change$$$$$). Got Covid on Sun. Robot down for a week. back at it Mon. Put everything back together and re-entered all Wobjs after adding arm loads and new TCP. Reprogrammed first of 11 jobs, resetting to CAD offsets at load tables. SUCCESS! :beerchug: Robot moves to actual pick up position without the need for manual adjustments.

    Axis 5 and 6 off by .3 Degs each.

    Thanks for the help.

Advertising from our partners