Posts by Shellmer

Quote from hermann

As always on Karel programs you are digging blindfolded for a needle in a haystack.

You must insert some debug messages or setting variables, you can observe on TP into the Karel program to debug it.

Edit: you can compare source of old and new code to see the difference, as you said the older one runs on all robots.

Inserting messages is the way to go to debug when you can't see the code being executed... also, keep in mind that even while karel is compiled + encrypted and you can't see what is being executed, the line number from the .pc file matches the one of the .kl file.

So if the robot reports an error on line 8 of the karel routine and you have the karel source code, check the line 8 on the source code as it will be the same.

Quote from HKP

You wil get the error "MOTN-560 Hspd.skip speed limit (G:1)", when you go above the standard 100 mm/s. High speed skip is nice because of the short stopping distance compared to normal skip. In this application it's used for collision detection. But I have found the system variables.

$PARAM2_GRP[1].$QSKPLIM_END = TRUE

$PARAM2_GRP[1].$QSKPLIM_LIN= "wanted speed"

Restart required.

Yeah, I know that it gives an error if you try to exceed the default 100mm/s, I understood that you could not even use the search if you used an speed above 1.5mm/s or 15mm/s.

But I advise you again to not use that function with speeds above 100mm/s, if the condition is met the robot will brake harder than with the normal skip condition (you can even see the robot vibrating when stopping on some cases), and I remember I read on some manual that it is advised not to use this function over 100mm/s as it can damage the mechanical unit (Probably stated on the handlingTool manual, just can't check right now as i do not have the document here)

If this is the case and you use it and your reducer gets damaged and Fanuc finds out, your warranty will be voided.

You are free to do whathever you want of course, but if the only purpose is to monitor a detector and you have plenty of avaiable overtravel since that detection, just use the normal skip condition with a faster speed.

As far as I know, there is no way to do this even on new controllers.

I may be wrong... I can try tomorrow, but my bet is that it's not possible.

Edit: One idea, you may be able to use registers to test it, then after it works, use the replace function to replace each register with an AR. I do not remember if with RJ3 controllers you have the replace option but most likelly yes.

Have you checked if the mount angle is set correctly? Maybe it is configured at 180º so it tries to compensate against gravity incorrectly?

I programmed a lot of robots of that particular model, and the most weird issue I had was that an incorrect configuration (someone loaded sysvar.vr file from another controller...) caused collisions mid air. Other than that, no problems so far.

I would advise you to check the datasheet that is shipped with the robots and where it's the calibration data, there is also other variable that indicate the default torque value of axis 5&6, if this value is wrong the robot will not calculate payloads correctly.

This value can also be recalculated by performing a calibration without any tool mounted if you enable the "Calibration mode: ON" when doing a payload.

EDIT: Just to be SURE I advise you to make a image of the controller before messing with any settings, it's a safeguard if Fanuc ever checks that robot, you should always do this anyway after you power up the controller first time.

Also, if you perform the payload calibration with the calibration mode, ensure there is NO TOOL installed, do it just with the robot flange (but if you have the datasheet at hand, just verify these values as if the robots are brand new they should match... If the values do not match maybe you have mixed the cabinets and mech units, you can also check the serial numbers as they are on that sheet)

Quote from HKP

What system variable do I have to change to adjust speed limit for high speed skip.??

In this application we use it for collision check. We have springs with sensors to avoid damage to part and robot. So it's allowed to move furter then the 1.5 mm that is around the overtravel at speed 100mm/s

I've used the fast skip with 100mm/s without any problem or restriction... what error is showing?

Also, you must be aware that going over 100mm/s on a high speed skip is not advised as it can damage the mechanical unit. If you have ennough avaiable overtravel, why use the fast skip then?

On this case i would just use the normal skip, it will go a little further than the high speed but if you have springs and ennough overtravel it should not be a problem. The high speed skip is usually only needed when you need to stop very quickly or you need to measure something and stop quickly when the condition is met.

Quote from HalbesYoyo

You can use some code like this in a background logic:

Code

IF ($MOR_GRP[1].$JOGGED=1) OR (DO[8:TP enabled]=ON AND $MOR_GRP[1].$ROB_MOVE=1) THEN ;
!rob has been moved manually or by program in manual mode
ELSE ;
!rob has not beeing moved ;
ENDIF ;

$MOR_GRP[1].$JOGGED
A boolean variable, indicating that the robot has been jogged since last motion by program.
It is reset to FALSE on program motion start.

Keep in mind: It does not maintain TRUE state through power restart, and is always FALSE on power up.

DO[8:TP enabled]
A system signal indicating the TP is switched to manual mode.

$MOR_GRP[1].$ROB_MOVE
A boolean variable, indicating that the robot is moving (by program or by jogging).

This code will recognize jogging the FANUC or running a motion command via program (and therefore maybe leaving the path) while in manual mode.

Because the DO and $JOGGED are reset when switching on, the code does not (currently) recognise whether the FANUC has been moved to a different position and then switched off.

To do this, you could save the current position on the rising edge of $ROB_MOVE and compare it with the current position after switching on(!?) This is already on my TODO list.

Display More

Yeah, it could be a solution, but I just preffer to use the space functions as I know that the gripper is inside an area and I can know how and where to move to exit safelly. Been using this method for years and it works wonderfully, it rarelly collides and if it does, it's at a very low speed.

I also use the reference positions to return home, and sometimes even the axis degrees or word coordinates. The homing procedure is usually structured to first check if the robot is on any refposition, then if it's on any spcfunction, then if it's on a certain zone checking by coordinates or axis values, and if everything fails... it just aborts the program and someone must move it manually.

Quote from pdl

Have you looked at the door-switch?

Unfortunately, this rather vague fault title doesn't scream at you that it is referring to the door switch of the robot control cabinet

90% chance is that switch, I remember that particular message very well as It has also given me problem as it's vague... at least fanuc could have specified "SRVO 105 CABINET Door open or e-stop" as with the current message you would think you have a problem on the FENCE or the EMGSTOP safety channels...

Quote from ASUA1

Breadcrumb mentality is good for recovery in auto from auto. You use registers basically to update where the robot was at in a program when it was stopped your recovery program sees that and knows it needs to back out of the position to a safer position then on to its "Home".

For any recovery after manual movement, it gets much trickier as the robot doesn't really have a reference to rely on for it position or surrounding obstacles. Scara are easy though as you can send it to a known good z height and then home.

Personally I would avoid the use of registers to track where the robot was. The reason is that you do not really know if someone has just moved the robot manually before executing the homing sequence.

I would suggest to just create a few of SpaceFunctions and check these areas on the homing routine, then, knowing where the TCP is located you can guess how to move in order not to collide, or just move in one direction and then go to a reference point (you could also set reference points and check the associalted DO), then go home with a taught path.

I've had very awful experiences with robots whose recovery paths were programmed using registers, and it makes the code very dirty if you need to know where the robot was all the time.

Quote from Danishmuff55

I forgot to quote you but I posted all the images. sorry if they are scattered

First thing I notice with that images:

You have no rack or slot assigned to the welding signals, without it, your welding equipment will not work. That is also the reason it is giving you the digital port access error (you see the * on all your digital outputs? that should not happen)

You need to create a range of DI and DO and asign them the rack and slot of the device you are trying to communicate.

Check this thread as it is a list of rack numbers provided by Nation: Mapping UOP To Flag

The slot is either a fixed value (like when you use profinet) or is the device address (like when you use devicenet, profibus, etc). If you have a similar robot already working with the same boards and soldering equipment you can check there what rack and slot you need to put there, also, do not forget to do this both on the DI, DO and GI/Go if you use groups like when you send welding "jobs"

Quote from NathanJo

I previously undertook this installation process and will give it another try. Thank you.

Maybe your problem is that you are running a system where the current language is not english.

I had a similar issue recently with a similar software and the problem was that it was trying to modify the group "users" when on my system it's called "usuarios", I needed to create another group called "users" and add me to it.

Quote from Danishmuff55

The code is INTP-206 digital port access error. and no it effects all of my tp programs and I have never had issues with the bg programs they have stayed the same for years.

Post some pics of the TP segment where you are accesing the variable, also one of your IO config mapping and another one on the "monitor" screen where you can see the status of these bits/groups (these input or group inputs should appear with data, if it appears an * that group or IO is not defined)

The screenshots you pasted on your post do not work.

Check the alarm log, it probably is one or more previous alarms.

With your description I would bet is a payload issue as it works at 70%. Make sure your robot mount angle is correctly configured as if it's upside down the controller needs to know it.

If it is wrong, change it and ensure to remake the payloads.

Just add a new label at the start of your main program, and jump to that label just before the end.

Quote from guidam313

I guess that would also be true for a SET_VAR?

I doubt it, the max pr you can set is not a fixed value, it depends on the avaiable memory and installed options.

If you add more PR registers, you decrease the ammount of normal registers you can set, same if you increase payloads, frames, tools... etc.

Then... if you install more options it happens the same, more installed options == less space for registers. And it seems that the avaiable memory is in reality limited by the software options, not by the hardware, as if you get the "expanded registers" option you can add like 2k PR without modifying the hardware (at least this is what the fanuc sales guy told me)

Quote from sborchshev

Do not think calculation is the reason of slower motion. Calculating the pass consider total distance to calculate acceleration/deceleration. With many points even with CNT100 total distance for calculation is one extra point ahead and so on. So the acceleration/deceleration curve is different and so the speed over all. My thinking...

I think it is more a thing of the motion planner, think about this... what would happen if you put a condition betwheen two of these points like wait DI[1]=ON while moving at 800mm/s (assuming it reached that speed) seperated 8mm each point?

It would not be able to stop in case that input was off. If the read ahead instructions are set to 3 instructions, this will limit the processing speed as it needs to also take into account the program pointer being stopped mid motion.

I know, someone would say that if you need to check a signal, you should put a fine behind it, but this is not really needed and slows down the robot a lot if you do that for every condition.

As a rule of thumb, I always avoid adding more points than needed on paths, as since a lot of time some other guy demonstrated me that if you want the robots to run and be fast, the less points, the better, and this applies to abb, fanuc, kuka and more brands.

Quote from pegermain

Yes you can put a argument to R if you want. That not the issue here. In my case I would rather have kind of command that will "ignore" the R between the 2 movement.

WJNT is for linear move only and just act like Joint movement. Will still go to the position that I have.

FUT or NUT is neither configurations that affect/change my J6 rotation issue/ calculation.

Take care when using the WJnt modifier. If the path will always be the same, it will always do the same thing, but if the points are modified or automatically calculated applying some offset you can run into issues if the new positition forces a config change (like from FUT to NUT or viceversa)

The thing is that if the config needs to change, it will not perform a nearly linear path and instead J6 or even J4 may want to completelly rotate 180°, it will do a very weird movement and your tool may rotate almost 360° while performing the motion.

So do not rely on this with vision applications or any other application where offsets are adquired by external means, only use it if that particular path will be always the same.

Quote from Apkano

The biggest issue I think you'll run into is the encoder positional data for the gun. When robot 1 puts down the gun robot 2 has to trust that it was placed on the perch with the EXACT SAME SETTINGS / POSITION.

This can be overcome with a "autohome" every time the robot picks up the gun, but it will affect cycle time.

The biggest difference here is doing 2 guns on 1 robot, the robot remembers the data from when the gun was unmounted. When 2 robots share a gun, robot 1 can unmount the gun with the servo in a different position that robot 2 will not know about.

Umm, as far as I remember, the encoder battery for the welding gun axis is usually located on the controller cabinet, so a disconnection of the gun would imply it would lose the calibration.

One problem with this is that it will lose his zero, this is usually not a problem as you can recalibrate the tips again knowing the wear but as you are sharing the gun, the robot will not be able to know the current wear of the tip anymore. If compensation is pneumatic it will not be a problem if you track the dressing and wear through one of the robots or even the plc, but if it's compensated by the robot this wear data is important so the robot compensate and actually touch the surface with the fixed cap.

I am a bit rusty right now as I've stopped to work with spot welding a year ago, but one solution may be to handle this data externally and overwrite the wear through a routine that receives the data from the plc or the other robot.

Quote from SkyeFire

Key questions are: How much corkscrewing? On which axes? Some degree of it is inevitable, no matter how perfectly the robot is mastered or the TCP is taught. It's just the nature of robots.

In the past, I had cause to try creating some very precise TCPs, using a laser tracker and iteratively tuning the TCP values in 0.1mm increments, and quickly found a point where reducing the error on one axis increased error on the other.

Similar to me, you usually can't perfectly calibrate the TCP, on my case I used mechanical comparators and even lasers to measure the center of a cilynder, and no matter how much I tried, I always got deviation even while the measurements with the lasers were of less than 0.01mm difference when rotating the part.

I mean... I've done it using 4 points of the cylinder, rotating the part 90, 180, and 270 degrees while correctling the tcp after each iteration to recenter the tcp, but no matter how fine tuned the tcp was, when reorienting it always deviated a little. Also the same happened on my case, it reached a point where correcting on one direction would deviate into the other, even when correcting less than 0.1mm.

I ended just assuming there would be always a reorientation error, it was not much, but if the deviation was greater than 0.1mm while rotating the results were noticeable.

Quote from hermann

If you have only very raw (few) steps in angle, you can use a lookup table for sin/cos values in TP and don't need Karel.

Sure, thats what I usually do when I need to recenter the coordinates of a picking point of workpieces that go into V shape stops, depending on the workpiece radius and point of contact I offset the coordinates by that ammount.

You can usually do almost all through TP if you get creative, I remember that someone from here has even created from scratch the matrix inverse function on TP.

On my case as I have Karel avaiable on all our robots I prefer to just write little karel functions that do very specific things, so per example if I need the COS function I just write a karel routine that accepts an angle value and a register, and when called on TP it just gets the angle and writes the result on the provided register. That way that code doesn't need to be maintained as it's a simple operation that allows you to use karel math functions on TP without the need to compile a karel function with all your calculations.

If that karel source code is lost, well, it's not a big deal as you know that the function is a simple interface of the original math function of karel.

Quote from hoitzing

I don't know of any built-in methods either. But if you express your cylinder as a cone without any slant and create your own wrapper function/program to convert conical to cartesian coordinates (with the cone parameters saved in registers for example) you will only have to do the logic once right? Or am I missing something?

For this scenario I think it would be the best approach, you either generate a path using some cad software that can output code using an uframe set on the center or... you generate a path automatically using TP + Karel to calculate new points on the fly.

I've done something like this to create a pattern to grind the borders of some cylindrical pieces.

On this particular case I generated only one point located on the border of the workpiece, then rotated this point a few degrees using a little bit of trigonometry to get the new equivalent XY coordinates of the new position, then I repeated this procedure until I finished the full circunference. (only 5 points but... robots do not like to execute circular paths whose points have more than 89.999º of diference, on this case it was a point every 72º)

If you want to create an spiral path I would try this: (X= Radius, Z=Height)

• First point: Start point
  • X= Minimum radius of the cone
  • Z = Maximum height of the cone
• Second point:
  • Copy first point to second PR, add a few mm to X, decrement Z, rotate the point a few degrees so you get the new equivalent XY
• Third point:
  • Copy second point to third PR, add a few mm to X, decrement Z, rotate the point a few degrees so you get the new equivalent XY

Repeat until finished.

You would need to know the angle slant of the cone in order to calculate how much mm you need to increment to X and decrement to Z so it follows the slant of the workpiece. Nevr tried to do an spiral pattern but I am sure it's possible.

On my case in order to calculate the coordinates of the new rotated points I just used a Karel function that I made to rotate the point using SIN and COS from karel, this karel routine accepted an origin PR, and destiny PR and the angle I wanted to rotate the point around the uframe.

oE6No.png

Note that this approach doesn't take into account the rotation of the Z tool axis, I haven't needed as the tool was able to be used without rotating, if you need to rotate the tool, you may also need to increment the Z angle of each point manually so the robot tools rotate at the same time it does the circular motion (This is not a good idea unless you have a very well measured tcp)

Not the best of the world as I usually try to not use Karel, but the math functions are only avaiable from there.