You cannot directly apply an offset to the positions, but you can send the position to a variable and add to that variable's coordinates the offset values.
Change your tools to match. Makes life a lot easier and it's easier later to modify, remember, train others with/for. Otherwise, in a couple of years if you come back to this program you may be tempted to retroactively kick yourself.
That's a corner weld, more or less, so you can go with a 45 degree angle of the wire between the surfaces. You need to push rather than pull the wire forward, so take a sharp angle, a few degrees, in the direction of the weld.
Granted, I've never programmed a robot for Al welding, so take my general, not-actually-a-welder, advice with a grain of salt.
I've never found this info in any manual, but luckily I have a much older mentor who passed this info on to me. I can't understand how Fanuc simply passes over this mandatory knowledge in their documentation.
This is actually mentioned in the M410iB maintenance manual, in a very short paragraph pertaining to the replacement of the J1 reducer. That is basically why I asked about tips as that seemed to be a bit too little to go on. My paranoid self even had the robot end propped up as we unmounted the balancer from one of the client's spare units.
At this moment, after changing a balancer and a J3 bearing, all that's left for me is to replace a J1 reducer for one of these robots and I can honestly say I know how to take one apart piece by piece.
Thank you for the info guys.
I can say the replacement went off without a hitch.
Has any of you had the chance to swap out an M410iB/450 Balancer in the past? If so, would you happen to have some tips for this?
I'm taking a 410 apart next week and, while the manual is very helpful, I could use some hands on information.
Get rid of archaic registers and implement user named variables, arrays, and data structures. All user created variables should be able to be monitored on the data screen in alphabetic order, or a filtered view.
Not get rid of it but add alternative. This is one of the best things that the people I train praise by comparison to ABB or MOTOMAN.
...why not just set a password?
Stop ahead of the part, get the force, calculate a max, create a loop that works while force < max, continuous check, send ther obot forward in that loop.
VAR_FORCE = Force()
VAR_MAX_FORCE = VAR_FORCE * 1.5
LOOP (FORCE () <= VAR_MAX_FORCE)
WP_EDGE_POS = Get_Actual_TCP_Pose ()
Something of the kind, I think,
Okay, ISRA systems work in WorkObject coordinates, rather than Tool. It's been quite a few years, but I did a lot of ISRA rack-picking with IRC5s way back when.
(Disclaimer: I'm talking about ISRA Mono3D here, their product line may have changed since)
The trick is that, during system configuration, you have to give the ISRA system the actual robot position, with (IIRC) the WorkObject you're going to be using, and Tool 0 active. Then, the ISRA will give you an offset to apply to the WorkObject. You apply that offset to the WorkObject, and run from there. ISRA has (or used to) a RAPID module they would give you that would handle all this -- you pass their function the active WorkObject, the ISRA function modifies the OFrame portion of the WorkObject, and then you run your motions.
Yeaaaah, not in this case. I got a pat on the back from ISRA mostly.
Thankfully, PROMIA to the rescue! Seems like there's a whole module dedicated to this stuff. Once we cherry picked all we needed from it, things ran smoothly.
Our problems stemmed from the fact that we didn't know exactly how to reference an object to an work object. This project has been very educational for me. Always a plus!
Close enough, you got it.
The camera feeds us an X, Y, Z, RX, RY, RZ offset of the Object Frame.
We defined a WOBJ with the cell zero coordinates, and defined the work object itself as an Object Frame on the WOBJ - which seems really obvious looking back, but it's our first time working with a camera system this complex.
After that it was just a matter of calculating a PDISP pose out of the information we got from the camera. We ran tests all day yesterday and it's working like a dream fortunately. Thank you for the input.
Independent in this case.
At the moment my colleague just had a brain storm where we'll try creating our cell WOBJ and then created a number of Object Frames related to this WOBJ which will represent the various work objects we'll be dealing with.
Here's an interesting question.
We're currently comissioning 2 ABB robots that use a 7th axis each (a track).
The cell uses a vision system to determine the correct position of the work object as it arrives in.
Now, the problem is such:
We use 4 cameras to determine the displacement of the work object and the rotation. The vision guy gave us the zero position coordinates for his camera system relative to a cell zero position that was measured previously. Each work object has its own origin for the measurement and we will be receiving X, Y, Z and RX, RY, RZ displacement offsets.
Using laser measuring, we've also determined the zero position for the work object for the two robots and created a WOBJ for each robot.
Now, where we're a bit stuck is this:
How do we define WOBJs for each work object origin now that we have a cell zero position on each robot? The robots are facing each other but their coordinate systems are rotated 180 deg one from the others.
I don't know if this is terribly clear as far as explanations go, but I'll only have access to the vision guy next week to pick his brains. I'd rather I get some trajectorie programmed this weekend so I won't have to go over them again later on when we're doing vision tests.
Let's say something of the sort.
When I ran the IDENT, I got back some payload values that exceeded the 12 Kg my M10 was capable of, and which was impossible for the gripper.
I've been playing around with the IDENT function on some of the FANUC robots we've been installing lately, but I'm pretty sure I don't understand how this SHOULD work or what I should be doing with the info it gives me.
Whenever I run the IDENT function I'm getting back rather crazy values for the PAYLOAD, and even crazier ones for the CoG, values that don't correspond in any way with our grippers / parts.
So...can anyone please write a "How to" for this? Thank you.
I know i have to put in an offset between the Robot and the External axis, but the question is where should i put this value of 45 deg. There is just one variable "Mounting angle", which i have already tried changing.
Could you please explain how can i set just the Robot at 45deg and external axis as 0deg? Thanks
Unfortunately, no. I've never seen a robot mounted on an external axis that way.
I'm really rusty on my external axis - haven't done one since my college master's project - BUT...couldn't you set the JOG as a Y+ instead of an X?
Sounds to me like this could be solved as long as the jog direction of the axis is paralel to one of the robot WORLD axes...which would be Y by my understanding.
I may be wrong or completely misunderstading the problem.
Is there any way to manipulate the CONF data of a PR in a program?
I've recently written a program where a robot loads one of two ports on a machine. Due to the robot position, each port has a different configuration.
Now, that would be easy enough to solve if I didn't want the program to be scalable in the future for more ports, more machines - because I'm lazy.
Does anyone know if there is a parameter anywhere that allows me to set, in a program, the CONF of the PR?
Thanks for your time.
Well...that makes sense I think. You've told your robot that his external axis is mounted at a 45-degree angle, which means that going on X, he's going up or down. Angle the axis at 45 degrees and the TCP will probably stay fixed in position.
Shouldn't the robot be configured as mounted at 45 degree and the axis at 0?
I've never mounted a robot like this so I may be wrong here.