You just have to check if a position violates the workspace before you go there.
Posts by benjamin.lundgreen
-
-
This is an issue with endless axis, what you can do is to check the variable $REVO_NUM[Number of your axis here] (keeps count on your revolutions with an endless axis) and as long as you are on a higher revolution than the start pos,
you go "ptp_rel {a6 -179}" (-179 to avoid that it instead goes positive 180..). Then you are on the correct revolution.
Depending on what angle your starting point is at, you might need to go "ptp_rel {a6-10}" before your last movement to make sure it ends up correct.I am not so experienced with endless axis, so i am not really sure why you want to do this, but are you concerned that the calibration willl "drift" after many rotations?
Have you experienced this yourself or is it just something you "fear" will happen? -
When you teach a position in an inline form the robot uses the current tool and base, not the one specified in the inline form, so that argument does not hold.
The other way is to do it through the variable monitor, but it requires more button presses.. You have to copy the value of $POS_ACT to the position that you want to touch up. -
If you boot up the controller without the smartpad connected it will automatically log in "on your monitor".
Otherwise you need to enter a password, which can be found if you search around here.You can also remove the key when you are in external automatic, then you can't change anything.
-
One small trick you can _SOMETIMES_ use when you have problems with status/turn is to change the motion to a linear, run there and touchup, then change it to ptp, as status and turn are only considered in constant path movements.
Also, if you approach a singularity during the linear motion you will probably get an unwanted movement with much reorientation of the wrist axes during the ptp motion.
-
Make sure that you select the program and not open it.
-
There are some system variables which you can do this, for example, $RED_VEL_C instead of $RED_VEL or $OUT_C[10] instead of $OUT[10]. Below is a list of most of them. $POS_ACT is unfortunately not included, so you have to stop the main run pointer, or do some crafty programming..
$ACC_AXIS_C
$ACC_C
$ACC_EXTAX_C
$ACT_BASE_C
$ACT_TOOL_C
$BASE_C
$CIRC_TYPE_C
$FILTER_C
$GEAR_JERK_C
$IPO_MODE_C
$JERK_C
$LOAD_A1_C
$LOAD_A2_C
$LOAD_A3_C
$LOAD_C
$ORI_TYPE_C
$OUT_C
$RED_VEL_C
$ROBROOT_C
$ROTSYS_C
$SPL_TECH_C
$SPL_TECH_LINK_C
$TECH_C
$TECHANGLE_C
$TECHPAR_C
$TECHSYS_C
$TOOL_C
$VEL_C
$VEL_AXIS_C
$VEL_AXTAX_C -
Check the attatched image for commands/variables that causes advance run stop when reading/writing.
In some cases you can add '_c' to the variable to read it in the main run instead of the advance run. -
-
I haven't looked so much at the problem, but i think it should be possible to solve using an interrupt that triggers directly after start. This could be done by having the submitter looking at the current program state and setting an output. Just some ideas to start with.
-
Quote
Thanks, I think I'm on the right track, I'll start experimenting.
I did not realized that points are in the context of the current tool to the current base.
At the moment my tool is 0,0,0,0,0,0 to the flange, so my results align with that.
So, I have to drill the holes, then go back and put a rivet in them with a tool offset slightly from the drill. How do I select which tool (TCP) I'm teaching in, or is a certain tool just selected automatically? Maybe I'm still missing something here.
Do you have a KRC2 or KRC4? I will describe for KRC4..
The tool and base you are teaching in is changed by pressing the tool/base symbol in the top right corner and selecting the correct tool/base numbers.
The tools and bases can be created under configuration->measure.
You can read how to do this in the help file on the smartpad or you can also download manuals in the kuka manuals section on this forum.The tool and base you select in the inline forum just decides which tool/base will be used to reach the specific point.
QuoteTool 2 (Riveter) is of course frame-offset from Tool 1 by the combination of their relationships to the flange.... but what that that mean with respect to my taught points?
I feel like points would make more sense with respect from flange to base, since it never changes with tool offsets, etc.
The reason for points being tcp to base instead of flange to base is many, for example, you can calibrate a new tcp if your tool (for example welding torch) gets damaged (though it's usually better to just repair the torch..) without changing the program. You can also use automatic tcp calibration with welding guns after tip dressing (cutting a new welding tip). Also it makes more sense when you think about linear motions.
QuoteShort of inline forms telling me where these are taught (which I'm not using currently), how do I select a tool and a base when teaching? Does it have anything to do with what mode I'm jogging in? Maybe there is a better way to teach, I'm currently just jogging in whatever mode helps me get where I want it to be, then manually transposing those positions to WorkVisual in named points.
I agree that there's no really good way to create a point.. (Or maybe i have missed this all the time?) I usually use the inline form to create the points as it's a quick way, then remove the inline forms from the .src file and the ldat's and fdat's from the .dat file.
QuoteHow do you select World once you have moved in a base? Currently I have:
Code: [Select]
DECL FDAT ARM_FDAT_T3={TOOL_NO 1, BASE_NO 0, IPO_FRAME #BASE,POINT2[] " "}
... Yet I have no bases defined. Maybe I answered my own question... a BASE with no definition is offset 0,0,0,0,0,0 from world I imagine..?When you supply base 0, the values in $nullframe (frame variable with all members set to 0) is applied to $base (system frame variable for current active base). World is selected by selecting $nullframe in the drop-down list for selecting current base.
Have a look inside bas.src if you want to see how things are handled by the inline forms.
If you program in "expert mode" (without inline forms) then directly modifying system variables for tool($tool), base($base), speed($vel), aproximation($apo), acceleration($acc), etc is 'simpler' since you just change the variables you need to change and makes the program cleaner. You can find more information about these variables in the KUKA System integrator manual or in the System Variables manual. -
Quote
Hi folks.
I have my robot up and running, and we are about to mount the tool to it. I am in need of using our tool to drill an array of holes on this plate.
The plate is mounted vertically, more or less at Y=0. So, technically I could get away without teaching the plate as a frame, but I think a frame is still the best way to go, but I'm not 100% sure.
Teaching a base doesn't take long time and it's good practice to use them.
If your workpiece is angled in any direction, then jogging and calculating positions get much easier.
It also gives you the posibility to move your workpiece to another position in the future and just adjust the base.In this case, it doesn't seem like you have that many positions (you should be able to get away with one position or even calculate all of them) so you wouldn't have to re-teach many positions in case of moving the work piece, so there's really no big reason to use a base, other than if you want to duplicate your workpiece or if it helps with jogging.
QuoteSo, my question is...
Is Base[0] pre-defined as "World"? Would an ideal place for my work piece be Base[1]?
In KRL the index for arrays start with 1, so $base_data[0] would throw you an error. However, none of the bases are occupied from the beginning, so you have 32 at your disposal. Of course you can create more bases and store in frame variables if you would need to.
Base 1 would be a good place to store your base in. I usually order the bases by their position in the robot process, in this case it seems like you only have one.QuoteAssuming that is correct, I should be able to define my points in the Base[1] frame, so if I re-teach the location of the plate, the hole positions will move along with it, at least I think that is the whole point of the Base frame manipulation.
As i wrote before (i did not really read you question fully before answering...) this is one of the "features" of using bases.
QuoteIt seems points are defined with no base or tool associated, and you "run" them with a Tool and a Base assigned using the FDAT, correct? (my current program works, but with 2 tool frames and only a single base frame, so just making sure).
You are correct, a point has no idea which tool/base it was created with, although the inlineform has information about this.
The point is the position of the current tcp ($tool) relative to the current base origin ($base). Therefore, if you change your drill to a shorter on and re-calibrate the tool, you can use the same coordinates and still get to the same point in space. The same is valid for the base, as i wrote earlier.QuoteFinal question... assuming I've defined the plate, and have it drilling my holes. What is the best way to get the robot to come around and drill the same (or very similar) point on the back side of the plate? I suspect I'll need to take plate thickness into account as well. What is the best approach here?
There are a number of ways to do this, the first one you might think of is to measure a new base for the other side and run the same points with that base. Another way is to invert the working direction of the tool to make it "point" at the same point from the backside. If you are drilling through holes, then i guess it doesn't matter if you drill too far, otherwise a simple base shift would take care of the thickness.
Insted of changing the tool, you could also change all the points.QuoteAs you can tell, I'm new to 6DOF robots, and I can do the code once I've landed on the theory.... but experience is always best. Thanks!
We've all been there, and there's always loads more to learn no matter how long you've been doing it. Good luck in the process!
-
-
Hello!
Try swapping servo modules between a1 and another axis with the same servo size.
Also make sure that the grounding of robote, controller and welding fixture is done properly, and that data cables and power/motor cables are separated and/or shielded. -
Yes, as you say, it can be used with cartesian coordinates. I looked it up, and it is the same even on KSS2.2. SkyFire, memory failure happens to the best of us
Yes, that code would probably work. However, using relative motions can be dangerous in case of an error.
If you press start after a stop, it will excecute the whole relative motion again, and not just the remaining distance.Calculating a fixed position before starting the motion will save you from this problem.
Another problem you may face with doing this kind of motion is end limits of the axes a4 and a6, but that's a future problem.
You could for example use endless axes, but you have to watch out so that the energy supply to the tool (if present) doesn't get tangled. -
If you have an early KRC4 then your motherboard is missing the DVI port and you need to connect a pci-express graphics card.
-
-
Have you also added the moments of inertia for the load?
This "irritating" control feature is there to show that the current load data is not correct.
Running with wrong load data can depending on the application increase the wear and tear on the gearboxes. -
-