Advertising

Posts by Robo_Eng_13

    The USB Devices had some intermittent issues when i tried them, but that was primarily caused in the setup and a minor revision that Fanuc says is fixed. Otherwise they were effective, but a hassle to plug in and unplug.


    It isn't the best thing, but as far as i know, as long as you do not use a non safe input to control a safety device, you CAN use a safety PLC as an intermediary between a non safe input and a non safety output.

    Not sure if it will be relevant, but an issue i ran into on R-30iB in the past.


    The robot had been backed up to UT1 before, but when that was done, it was in a deep directory, 4 or so folders deep on the flash drive. This was successful, but when i inserted a clean USB, it had saved the path from the previous, rather than automatically putting back at the root of the USB. When trying to create a directory there, it would give the same error of directory not found, because it is trying to create the new location inside of a location that does not exist.


    The solution was to use the Up One Level option until i reached the root. An additional issue i encountered here was that too many Up One Level actions seemed to crash the controller. This occurred multiple times, but not verified enough to say if it is a certain number of levels, or if i was issuing the commands too quickly.

    If you have access to roboguide, you could do a cad-to-path feature to accomplish this pretty easily.

    I guess i was thinking of a function which given Radius 1, Radius 2, and a touch point, could calculate and adaptively generate the path for ANY circle/cylinder combination on the fly in a TP program. If it is just a one-off thing, RoboGuide seems like overkill, you could just teach the point sindividually.

    Guys, I want to cut a circle on a cylinder.

    I have make circle and path its perfect, but plasma is not always perpendicular to the surface.

    A circle or radius R1 projected onto the side of a cylinder of radius R2, determining points which are in line with the projected circumference of the circle and in direct contact with the surface of cylinder, with the angle of the tool modified to be perpendicular to the surface at each point would most likely require the math option (or a homemade function using newton's approximation, which sucks but works), and a larger number of arc moves rather than a single circular move.


    It is a really cool math problem, and on paper seems pretty straight forward, but i can see a lot of little challenges with automating it on a FANUC robot.


    The angle of the torch will be a function of the radius of the cylinder and the current location around the circumference of the circle, and with a little trig could be easily calculated, but again, FANUC does not supply trig function by default, and i am not sure how those calculations might impact operation of the program.

    General explanation, more generalized in programming context.


    RUN and CALL are two different ways of executing programs.

    RUN is Non-Blocking, CALL is Blocking.

    RUN will, so long as there is no reason not to, create a new "thread", order it to execute the specified program, then move on and never look back.

    CALL will also run the specified program, but instead it will run it in the same "thread", waiting until the child program is completed to jump back to the line after the CALL command.


    As was said before, a motion group cannot ever be controlled by two programs at once, so whatever program you run must have a non-overlapping group mask to all other running programs, including the one in which the RUN command is executed.


    Also mentioned, CALLs within CALLs and RUNs within RUNs are always a hazard and likely to result in Stack Overflow or Memory Overflow, especially when loops are involved.

    Has anyone ever encountered a way to restrict choices on specific screen circumstances that do not have individual screen ID's? Specifically, when a point is touched up and that point's number is used elsewhere in the program, you are prompted to set new ID, which we want to only allow NO, and when touching up a point with an offset, you are prompted if you want to subtract offsets, which we always want to be YES. However, neither prompt changes the screen ID or SP ID fro m the generic of the EDIT screen. Is there a system variable or configurable point somewhere to restrict this?

    Not addressing how to remember, but a note to anyone who stumbles upon this wondering about the right hand rule, there is a secondary layer for rotations. If you point your thumb in the positive axis direction, your fingers curl in the positive rotation direction about that axis. Many people do not know this, and it is a helpful additional tool to teach.

    If you establish a reference point that is solidly mounted to the same base as the robot, and attach a secure touch point to the end of the robot, it should be able to go to a taught point (within about 0.5mm) over and over indefinitely.


    1. If you are just finding more points from before remastering that have not been touched up, that is normal.


    2. Ensure that whatever end effector you are using is not bent or damaged. Especially critical on weld torches.


    3. Consider the possiblity of someone making unauthorized position touchups that you are then re-re-teaching.


    4. If your robot is truly unable to return to the same location multiple times, then there is likely a major mechanical or electrical failure. Ideally, you would have another twin robot, and you can do swaps between components at different levels until the problem switches to the other robot, but sometimes that is not an option. An alternative might be to identify which axis is unable to achieve the correct repeatability, potentially by measuring the angles of the joints with a miracle point or a digital protractor.

    With the password system, you cannot export a password xml until you have imported one. Once you have imported one, you can export to a USB drive (or presumably to any other location). Best to put an empty xml file names password_export.xml on the flash drive before you plug it in, as i believe it can only overwrite an existing file with the export.

    I have had absolutely no success whatsoever in transferring passwords setup on one device to another. The best bet is to have the install user disable the passwords and take the backup, then re-enable the passwords. You should then be able to load it into RoboGuide without the passwords. I would be hesitant to put a modified version back onto the robot, as i have found transfering between robots seems to scramble the syspass file and change the passwords from what they were set at. I have not revisited this issue in 6 months.

    Here is generally how i would go about teaching a new TCP with the 6 point method.


    Point 1 - Square up your tool to your reference point so that you are as square as possible to the world frame, or have a printed grid handy to align to. This point will be used to position the Cartesian space around the TCP itself.


    Point 2 - Move directly along the first cardinal direction of the tool. For welding, we typically do X as along the path of a weld, and Y perpendicular to a weld, so that Z is distance from the surface. Once this point is set, your Cartesian space is fixed along that axis, but able to rotate around it.


    Point 3 - This will be the last point to minimally define your TCP, and would be the last point with a three point method. This will fix the direction of the secondary cardinal direction and the rotation about the axis defined by points 1 and 2. The exact positioning of point 3 in the direction of the axis defined by points 1 and 2 is irrelevant and not used in calculation, but there is no value in needlessly deviating.


    Point 4 - This should be the same as point 1, and i usually teach both at the same time.


    Point 5 - Rotate the tool a significant amount (30-90 degrees) and then jog until your TCP is back at your reference position but the joint angles are all different. The larger the difference of the joint angles, the better the calculation will be.


    Point 6 - Return to Point 1/4 and then rotate differently than you did for Point 5. The exact direction does not matter, just providing a larger spread of angles for the system to use to triangulate where your TCP is.


    As an additional note, i would get a printed grid and tape it firmly to a metal table with no chance of moving, and station it where the robot can easily reach and articulate. Mark three points on the grid, at least 6 inches apart in the shape of an L to define points 1-4, with 1 and 4 at the apex, 2 directly forward, and 3 to the left (we do it to the right so that Z- is away from the part, but to the left will most resemble the world coordinates. The robot will always follow the right hand rule). Orient the robot so that the weld tip is straight up and down perpendicular to the grid, and positioned at the center point. Define Point 1 and Point 4. Jog away from the grid, then move to the second point (forward, away from you and the base of the robot) and bring the TCP back to the grid and perpendicular to the surface to define Point 2. Again, move away from the grid and move to Point 3. You should always move away before trying to move sideways when teaching weld TCP because bending the weld wire while teaching messes up your TCP. Once you have taught 1-4 and returned to Point 1/4, then do your rotations. I try to rotate away from me as far as i can for Point 5, and to the side as far as i can for Point 6. Both of these will touch the same grid point as 1/4, but not perpendicular to the surface.


    Last note, there are three different 6 Point Methods available, X-Y, X-Z, and Y-Z. This specifies what axes of the Cartesian space you are defining with points 2 and 3.

    You may be able to enter a controlled start and de-select the welder in the ArcTool Setup menu. I can't find anything that mentions if it is possible to undo the setup of a welding system.

    You can always teach User and Tool frames in whatever orientation you want (as long as you follow the right hand rule). Jog Frame i believe is relative to the current User and Tool frames, and the World Frame is pretty immutable, although if the robot is properly set up as upside down, it may change orientation. I am not sure, we have never had a flipped robot.

    1. Only one and exactly one user frame is active at all times.


    2. All user frames are valid and present at all times, even when not set or active. A User Frame that has not been set is the same as the World and User Frame Zero.


    3. You should be able to use BG Logic and either regular commands or System Variables to store the value of the current active user frame into a register, if that is what you want.

    1. AR is an Argument Register, which means it takes a value that you pass to it at declaration. Example, you can call a program SQUARE(2,3) and then SQUARE will read something along the lines of R[AR[1]] = AR[2] * AR[2], which will then place the value of 3 squared into register 2.


    2. Yes, you can use any string, within limits, in a string register. There will be some characters that i am sure you cannot make, and length limitations, but otherwise, a string is a string.

    I believe you CAN accomplish this with a combination of BG Logic and Macros.


    BG Logic would contain a single program that would look for R[1] = 1. When R[1] = 1, it would then set DO[1] to ON. Then, have a Macro set up on DO[1] to abort programs. After a delay, have the BG Logic then set DO[2] to ON, triggering your home program in another Macro.


    I have never tried something like this, but the general idea ought to work, if nothing i mentioned is prohibited. But, why do you want to launch a program by setting a register rather than any other method?