Posts by Famous_Fella

  • delay of movement when switching motion groups

    Quote from HawkME

    There can be a slight delay when changing frames or groups. I think it would be less that a second. More like the delay between 2 fine moves.


    Are there any WAIT statements or code that iterates (loops) a lot?

    No waits no calculations. I jumped them deliberately to check if this was the case. The delay is still the same and the only difference is that from a single Group Mask program I call a Group Mask 1,2 program. Everything else is the same. Also the delay is the same when exiting the subroutine. One other thing to note is that on group 2 (servo gripper) the Continuous Rotation function is enabled. I don't know if by entering a program with a motion group that uses Continuous Rotation function the motion planner does any magic to calculate or store a zero value for that axis.

  • delay of movement when switching motion groups

    Hello,


    I am working on a new application with extended axis configuration. A seventh axis for a servo gripper. The main application is the palletizing and cell logic process, counters, register manipulation and pick and place of the workpiece. Inside there, we nest our custom program depending the workpiece. What I experience is this: When robot picks the workpiece, moves to home position and calls the sub program dedicated for the workpiece, there is a slight delay before the robot starts moving. More or less a second or maybe less. I cannot figure out what causes this delay, as there is no custom logic or calculations involved before the first move command.

    The main program (palletizing program) is with Group Mask 1 because I dont need to use 7th axis as much, and If I have to, there is already a list of programs I have created all with Group Mask 2 that just manipulate 7th axis, such as external_0.tp for 0 degrees, external_45.tp and so on and so forth. Although, this is not the case for the workpiece process subprogram which is of Group Mask 1,2 because in there, I NEED to be exact when using 7th axis.

    Can this be the reason why there is a delay when entering and exiting the subprogram ? Because there is also the same delay when I finish the subprogram and return to the main routine. Is there a work around this delay ?

  • SRVO-68 DTERR Grp :1 Ax: 5 & Ax: 6

    1) when you replaced the cable, did you also replace the connectors too? Are you sure both the encoder connector AND the amplifier connector (CRF8) are new?
    2) Do you have a spare motor to swap in place of axis motor 5 for example?
    3) does the fault occur on certain positions/postures?


    This is strictly a communication fault between the encoder and the amplifier, amplifier requests encoder data but encoder returns nothing, its either a bad connector (encoder pin connector or CRF8 connector), a faulty, maimed, scratched or not properly shielded cable, a loose ground or lastly a bad encoder.

  • Position of touch

    Quote from PavelB

    Hello,

    today I finally try to do some tests and I have a little problem. In the options of SKIP instruction is not the $MISC[]... choice. Do I have to turn it on somewhere?


    Thank you.

    Pavel

    In the options of Skip instruction you select Parameter option, you highlight the inputwith the 3 dots you press enter and you write the parameter MISC[1].$HPD_TRQ[x]<or>y where x is the axis you want to monitor and y is the amount of disturbance that the skip condition will return true

  • UTool and UFrame after Re-Master

    Quote from jflick99

    What you are saying is to jog the robot to the coordinates of the tool frame or the user frame? IF the coordinates relate to a position in space IE a pin. Than switch to joint mode and jog the robot to the tip of the 'point'. Than take the values from the joint cord system and calculate the differences than jog the robot to the Vernier marks and re-master. But where would I input the differences that I calculated. I'm gonna send you a PM maybe you could call me to explain in detail if you wouldn't mind :)

    Go to your frame screen, Enter the frame you want and write down the Direct Entry coordinates. Now create a program and inside declare a point anywhere, doesn't matter but ake sure you use the correct UTOOL and User Frame 0 (UF0), and change its coords to the frame coords. Move there. The robot should now be close to an identifiable reference point. A point someone (the integrator or a programmer in the past) used as the frame reference point.


    Open the point's position data and change the representation to joint. You should now see the joint angles of each axis for this position. Write them down.


    Now switch your jog mode to JOINT and try to correct the position of each axis separately so that the robot tool is aligned and touching the reference point. You should be carefull as to not correct one axis too much but better spread the fault difference by applying small corrections to every axis.


    Now when you are done and you have aligned the robot with the frame reference point, declare another point in your program. You should now have 2 points: point 1 is the original point from the Frame Coords used as direct entry and point 2 is the modified version of it in order to touch the reference point.


    Write down the JOINT angles of each axis for point 2 and calculate the difference. You should come up with a result of minor degree difference for some axes or all of them negative or positive, the difference margin should not be large. If it is large something has gone wrong.

    Now, put your robot axis to ZERO position and using the results from your previous calculation apply them to each axis. Again, you should check to see that after applying the correction to each axis the marks are not way off of where they were supposed to be, it should be +-2 max 3 degrees. If the Vernier mark is visually way off then something has gone wrong. When you are done applying the corrections, master your robot with zero mastering, Calibrate and you are done!

    Repeat the procedure by moving to point 1 (the frame ZERO point, not the corrected one) and verify that the robot now correctly aligns with the frame reference point by using the direct entry values.

    Things that can go wrong:
    Identifying and using a reference point that is not a good reference point. (worn out, or with excess tolerance due to wear and tear or age).
    The frame may (and most propably) has been set when the system was brand new and before any tolerances to the system's parts were introduced due to normal aging and wear. The same goes for the mechanical parts of the robot. Machines age, and as they age new tolerances are introduced and we copensate our programs to correct any faults due to aging.

    If you come by any of these possibilities, remaster to zero as before using the marks and your eyes and just reteach the user frame. The tool frame does not need to be taught, you can use the direct entry values.

  • UTool and UFrame after Re-Master

    Quote from jflick99

    Famous_Fella The pick and placement position is off after the remaster. We did a Zero Master. But since we did the remaster we have to reteach the user and tool frames because those values are entered directly, they aren't taught positions.

    Yes I guessed so. For the sake of it, verify mastering by putting robot on zero. Also keep in mind it is not a good idea to use Direct entry for User Frames. User Frames should always be taught imo.

    There is also another trick you can do that is a high-risk high-reward move and it can produce great results but it is a bit more advanced. Using the same tool frame as before and without teaching it, I would try to hit the zero (reference) position of the frame. If the directly entered frame points to a solid reference position in space (a pin, an edge point etc), move to that position and then correct the JOINT positions of each axis separately until the robot is correctly aligned with the frame reference point. Write down the difference. Lets say you had to correct +1.3 degrees on J1, -0.7 on J2 and +1.3 on J4 in order to hit the reference position of your frame. Put your robot to zero. Apply the corrections to the specified axes and re-master them to zero.

  • UTool and UFrame after Re-Master

    Are the frames taught or directly entered?

    By repeatable do you mean that each cycle the robot position changes or that the placement position seems off after the recent remaster?


    How did you master the robot? Zero mastering? quick master?

    I bet you just mean that your positions are a bit off compared to before the mastering. Unfortunately we cannot exactly hit the Zero marks with the eye. Every re-mastering using the vernier signs will produce slightly different programs.

    Put your robot to Zero position and verify that all Vernier marks are aligned in every axis and then reteach your User and Tool frames. This is about as close as you can get to your old configuration when using Zero mastering.


    If by not repeatable you mean that each cycle the same position is shifted then this is a different story that suggests a mechanical problem on the robot or complex logic used inside the program that is not accounted for. (a change in a PR, a calculated PR, a wrong offset application etc etc)

  • Distances off after making changes

    Roboguide has different saved points from different dates. Did you check those saved points for the possibility of reverting your roboguide cell back in time?

    The photos suggest you use an R30iB+ controller, if so have you set up your Auto Backup feature on the real robot? how many copies have you declared ? If you go to FILE > Auto Backup there you can check maximum number of versions the controller keeps before overwriting the back up with dates. Maybe you are able to restore the tp program you modified using a previous backup.

    If you dont have any of the above options then I guess this is a good lesson to start using them, I am talking especially for the auto-backup feature. I have it set to 3 loadable versions and the backup to start automatically every day at 09:00, this way I can revert any bad changes up to 3 days old.


    Option 3, inside roboguide from the project explorer expand robot > Tooling > double click the EOAT you use and find the "Calibration" Tab. Have you calibrated your UTOOL to much the roboguide tooling? Do a Calibration by following the steps mentioned in there.

  • fanuc robot

    You can get the manual from FANUC CRC portal. This is the one you are looking for:

    FANUC Robotics SYSTEM R-J3iB Controller DeviceNet Setup and Operations Manual

    MAROIBDNT20501E

  • Program transfer

    Chances are you are doing something wrong. You do not need to use Frame Offset on the robot to recieve the copy of the program, only on the orginator and that is if positional data are not already recorded in respect to an already declared User Frame.
    Select case:
    1) Original program has positions recorded in a User Frame. Copy program to the desired robot making sure that the robot to recieve the program has the same User Frame taught in the same position in the list. if the program is using UF1, UF1 being the center of something, a table, a fixture, a shaft then you need to make sure that the robot to recieve that copy of the program has the same User Frame taught in the same position on the list, that being UF1_originator = UF1_reciever. Not coordinate-wise but space wise, do not copy the values of one UF to the the other, but teach it using the same reference position.
    2) Original program has positions not recorded in a User Frame. Make (teach) a User Frame on the originator Robot. Use the Coordinate shift function under UTILITIES > Frame Offset. Convert the UF of the program to the newly created UF.
    All these actions are done on the orginator robot.
    Now go to the reciever robot. Teach the same User Frame in the same position in the list, copy your program, done.-

  • Skip condition, jump label not working

    The first thing I noticed from your attached photo is that you have not declared the label segment you want to jump into…. In fact you have declared no LBL sections at all and I strongly believe this is the reason why you can’t move and modify that segment of the command. Try declaring a LBL[5] further down your program with a dummy instruction like R[10] = 0. Now the TP should let you navigate to the LBL portion of your skip command.


    You can always install a trial version of roboguide, create an exact copy of your existing robot, and make some tests in there like:

    Create a routine-like program with the skip condition and the high-speed skip instruction using the virtual teach pendant, what happens?


    Try to upload that program to your controller, what happens? Are you able to modify the label?


    Write the program in roboguide’s text editor then compile and load to the controller. What happens?

  • Program transfer

    There is no such thing as a "Dynamic User Frame" as far as FANUC terminology stands. The label "dynamic" is just a label used by the integrator to give the user frame a meaning. There are many ways to make a User Frame "dynamic" (=a user frame that changes based on parameters and conditions defined by the programmer) but all this is dependant on the application. You should talk to the integrator if you wish to know why he labeled this frame as dynamic, chances are the frame is used inside a program that manipulates it (the frame) based on conditions met, fixture used or workpiece to be welded, and there should also be an automated procedure (a tp program or a Karel program maybe?) that modifies it based on parameters or a search function?

    All these are wild guesses. You should talk to your integrator anyway. As I can figure out there are a lot of info left unclarified about your robots by them.

  • Program transfer

    Quote from Chardafon

    It worked good when I thaught the same UF, i have noticed that the integrators left few robots with UF that have almost the same coordinates that means that i don't have to teach extra UF right? I mean is it important that the UF is related with the item?

    Yes. As I already stated on my previous post it is very important that the User Frames are taught. Because teaching accounts for small tolerances of mechanical part assemblies. Almost is not same. The "almost" part is related to the difference in tolerances I explained before.

    There is no need to teach any extra UFs. But it is very important that you verify the UF of the robot(s) that will recieve a copy of the program you wish to run.

  • Program transfer

    Quote from Chardafon

    Thx for the detailed explanation. I have here 10 robots and each one is doing different models of a crane arm. The thing is the frames are thaught from the integrators so I'll have to copy the points coordinates in order to teach it to another robot 🤔 or maybe make a new frame

    No you don't. Take the robot with the taught frame for a spin. Get the robot to hit the FRAME's origin. To do that, go to SETUP > FRAMES press F3 OTHER choose user frames, go inside the frame you are interested and check the positions used by the integrator to teach the frame by using the MOVE TO command. By doing so you get a glance of which reference point the integrator used on the fixture. Another way would be to create a program, select the user frame, create a point anywhere and change its coords to zero. Move to that point and you got yourself a USER FRAME origin. USE SMALL SPEED OVERRIDES !!!!

  • Program transfer

    Quote from Chardafon

    So what i did is i copied the UF and UT from the source robot and transfered it to the new one via direct entry. Than i used offset UF TF to transfer the points into the new UF and TF. It worker but still the points are quite far from where they should be. So something is missing...

    What's missing is that you used direct entry of the User frame without actually teaching the frame to the robot. What basically a user frame does is translate a point in space in relation to the origin of the User frame. I for example have an application that uses grinding wheels to grind different kinds of pieces with the robots. I have 10 robots all in their own cells but many times I want to have the flexibility of moving the grinding process of a workpiece from onr robot to another.

    This is where User frames come into play. So by using a global tool (a tool that I can install on all my robots) I teach every robot a user frame that is basically the center of the shaft the grinding wheel is added onto. Now when using this User frame, all of the positions of the grinding program are saved as a translation of the distance the robot tool is away from the center of the grinding wheel shaft (the user frame). The key here is teaching the User Frame and not COPY the user frame. Because, even though all cells are identical, there are factors like cell assembly tolerances, robot assembly tollerances, grinding wheel position tolerances that will not be accounted for unless I actually TEACH every robot the center of their working shaft. You do not need to use any offset utility when copying a program this way, you just need to make sure that the UFRAME and the UTOOL used in the original program are the same on both robots. To clarify, if the original program was taught on a robot using UFRAME 1 (= the origin of the table the workpiece is put at) with UTOOL 1 being a welding torch, then you must make sure that on the robot that is going to recieve the copy of the program, UFRAME 1 must be the origin of the table the workpiece is going to be put, and UTOOL 1 must be its torch and both of them should be TAUGHT. You must also make sure that the reference used in teaching the User Frames, better be the same on both fixtures inside the cells. Use a DIN pin located on the same position on both fixtures.

    Also something worth adding here is that even if the original program to be copied did not take advantage of any user frames you can still create (teach) a user frame and convert the positions using UFRAME offset utility or by touching up each position in the program with the new user frame selected. The procedure is: choose the user frame the points are saved with, visit the point, change User frame with SHIFT+COORD press touchup, on the popup that shows up change the old user frame number the position is stored with the new user frame you created, press enter, visit the next point, and so on and so forth. Believe it or not, I use the second method because I dont really trust automated shift functions for a reason I dont know yet. 8)

  • Lock override speed in auto mode

    Quote from Mangesh Shenavi

    Hello,

    I am using fanuc robot, Model-R2000i 165 F


    I want to lock the override speed at 95% in auto mode.

    1) Go to SYSTEM > Config. There you can set option "Allow chg.ovrd. in AUTO mode" to FALSE
    2) Go to SYSTEM > Config. Another option there is "Signal to set in AUTO mode" which allows you to activate a DO signal when robot starts in AUTO mode. Using this signal, you can create a background logic program that turns $GENOV_ENB system variable to false when the DO you defined is on.


    The more professional way to do this would be using the "Override Select function" from Menu > SETUP. There you can define a pair of DIs and based on their state, the system practically disables the override buttons and sets the override speed defined in the setup. Then, you manipulate override signals from your PLC (ex. set DIs to true when pressing "CYCLE START" command)

  • Position of touch

    Press MENU > SYSTEM > Variables. There you will find a list of all the system variables. They are sorted alphabetically. find $MISC_MSTR press enter and inside there set hpd_enb to true.