Posts by Elderwild

What is rotating the part? What is spraying? If the robot is rotating the parts, wait till you are finished spraying then do conveyor tracking. If the robot is spraying then use coordinated External axis to rotate parts and conditional conveyor placement to initiate spray routine. It shouldn't make a difference if the external axis is moving as you are tracking it with the conveyor.

Quote from Sahil Chaudhari

I was able to see it after a few tries. Thanks!

Nice job! Remember to use the service screen to do the backup.

Axis 5 and 6 needed calibration. off by .3 Deg each. Motor 5 had been replaced. Improper or no cal on initial reinstall.

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! 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.

I have not had issues using a "normal USB" on S4C+. Insert the USB, go to service window, select backup, change "UNIT" to hd0, select NEW DIR, create directory, create back up. The USB will not just show up, it needs to be selected.

Hope this helps.

***correction bd0 not hd0. hdo is the hard drive, bd0 is the usb port.

Quote from jarm

do you not have a backup? open the backup in robotstudio or notepad and find the orig wd2 weld data. Rename it and copy/paste it back to the controller in Robotstudio. Edit your programs weld instruction to use new wd3 or whatever you call it. Apply changes...done

jarm seems to have nailed it as far as the fastest way to get back on track. You wouldn't even need robot studio to do it. I use ultra edit to do all of my offline programming ( it has a Rapid highlighter), but notepad will work too.

Quote from SkyeFire

Really? They do have those lights. I never knew they were a critical path item in the runchain, but I'll definitely give them a check.

They are tied to the motors on light on the front panel. May or may not be a critical component in the chain. They should go on when you hold the deadman or press the front panel button.

As for the pendant reset, If the Joy or deadman were out of place on start up it could be a problem. Supposedly there is a button on the back for this purpose.

Sounds like you figured it out with the missing PLC.

Quote from SkyeFire

This worked in eliminating the Memory error, but we still have the Rev Counts error (not surprising, I assume that the mismatch and wipe/update forces this), and still have the Motor Contactor error.

Did you reset the Flex pendant yet?

Are the robots equipped with safety lights on top? Check to make sure they are hooked up properly as they are part of the runchain.

Did you reset your safety contactors from the PLC?? (shot in the dark)

Also check that the Runchain pins on the connection ends are fully seated.

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.

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!

#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 ). 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.

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?

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.

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). 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. 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.

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. 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

What would the manual update of a single position look like? Say (4,5) was off, how would you update just that position using the code you showed me?

Lemster68 Forgive my inexperience, what do the prefixes fo and fi stand for in the code you shared with me? I am trying to better understand how exactly I can apply this to my current setup. We don't have any sensors really, just an LVDT I haven't used yet. As far as error handling, I haven't coded any cause there is nothing to check anything with. Its a very basic no nonsense cell. Luckily, it has collision detect. Very rarely does stuff go wrong, but when it does its usually a quick jog and rollback to where it went awry. It looks like I would code something similar to Your TeachTray routine, but some of the rest is foreign to me. I am also trying to figure out how much of my current code would need to be changed in order to add something like this. I'd like to do it in a way that I could have a Generic Routine I could use on any table regardless of size of the array. So it seems I would need to attach it to my main program and treat it as a kind of supervisory part of the program, or have it as a stand alone that I put in and took out as needed. If its the former, I might have to rethink my entire PDispSet strategy.

Either way, thanks for sharing and opening my mind up to a better way to use the computer instead of just my noggin. Now I have to do some research on some of these terms and commands and figure out a way to program in some of that "fudge factor" you mentioned. I may have more questions later. Thanks for the homework!

.18, ?, 3.4 I think. Not great, not terrible. I will retry when I have more time. I figure I can move forward with the rest of the program. Either I can fix the Displacement problem, which affects the load proc with the better TCP or I can't. I'll create a new tool for the load portion then switch back to the old one between procs for the rest. Not great practice, but I need to get back to processing again instead of programming.

Quote from Lemster68

The motor may have been changed, but on that model it is common to just change the whole wrist, axes five and six would show different. But changing the cal offsets would also wreck all your programs.

Regarding this quote. If it fixes the PDispSet going forward and avoids all these manual corrections that need to be done, it may be worth it to try. What would be the odds of it working and if so what would be the order of operations to test.

Backup, change resolver offset, test? If it doesn't work, restore old backup? Or is it like updating revcounters and there is no going back?