Posts by Famous_Fella

    The problem is the hostname and/or syntax you used. There are some very annoying configuration rules there and manual is not clear at all on how to proceed with the configuration. Let me explain:
    Robots are on the same LAN network with a PC that I have setup the FTP server. FTP server is setup using Windows IIS manager and is a shared folder on C: with path C:\Robot Backup Server. In this folder I have subfolders for every robot individually. I want robot with code 300 to save only inside C:\Robot Backup Server\300. For this to happen, after you setup hostname in the path name you must enter only the last subfolder of your ftp that you want to use, in my example "300/".

    I hope this helps, I have lost countless hours setting up the FTP for my robots.

    Hi,

    I have been struggling for the past couple of days to setup 5 robots to use PC Share option for backup and general file sorage. Everything seems configured as it should, both robot and the PC can ping each other individually but when I try to start the PC Share link I always get the same error: HRTL-054 Connection reset by peer. The alarm code manual does not give any insight as to how I can resolve the issue. Does anyone have experience with this function ?

    All 5 robots are on the same LAN network. All other network related functions work without any error (iPendant functions work ok - also FTP Robot server works fine)

    I had this problem trouble me a long time in the past. Check the following:

    1) clean the air ventilation housing and fan located on the base of the controller. Use pressurized air. Mine was clogged.
    2) if you measured continuity of the cables and resistance and you found them under the recommended numbers chances are the system simply can't dissipate the heat generated by the amount of regenerative energy the motor returns. Our robot for example that had this issue has an increased center of gravity because it is based on high ground and axis 2 had a lot of dive moves near the speed limit. Also the resistance measured at the resistor was somewhat lower than FANUC specifications cause its an old system.

    Problem went away with some fine-tuning of the program speeds.

    Hi,
    Short question.


    Since I am using a lot of TCPs depending the workpiece I am currently working on, I use custom .TP programs to save different TCP positions to PRs. If the workpiece I use is 301-130.tp I also have a separate file 301-130-TCP.tp for the TCP locations. My question is this: Is there a way each time I call a TCP program, to also update the tool comments ? I tried to look for a comment variable for the UTOOL list since I also have a variables manual but I was unable to find any. Any help would be greately appreciated.


    SOFTWARE zero position is the position that every axis reads zero degrees on the teach pendant position screen. This is only to verify that your previous calibration was done right and you didn't make a fault or forget something. Put every axis on zero degrees in the teach pendant and check if this position aligns the witness marks of each axis.


    This step is optional. After, go inside your program, move the robot to a point that you know it has shifted, write down the JOINT COORDINATES and try to correct the point in joint frame using as less axis as possible. Experiment by slowly turning each axis separately. You will eventually figure out which axis has shifted and to where (+ or -). Make a new point as I described previously and write down the difference between the new and old points in JOINT Coordinates. Then put the robot axis on zero position again and add or substract the differences you wrote down. After, quickmaster the robot to those positions.

    If there is a difference on the points after a master/calibration it means that the program points were modifed once or several times in the past. It's not uncommon for old robots to correct their programs due to reducer plays or bad calibrations. Put the robot joints on 0 position and verify that 0 software position is same as the hardware position (witness marks). Keep in mind that after calibrating the robot to witness marks its IMPOSSIBLE to hit the exact same spot as the previous calibration. In my programs at least I always have minor differences when I have to recalibrate the robot after a motor change for example. Even 0.1 degrees out of the previous calibration in one or many joints will cause program points to shift and sometimes this shift makes a huge difference in your program.


    There is a fix around that but I would advise you against it.
    1) Run your program and go to the first point or any point that the difference margin is noticeable.
    2) check your joint coordinates. Write them down.
    3) put the robot in joint mode, and adjust each axis separately to correct the point.
    4) make a new point below the original one.
    5) You may need to adjust 1,2,3 or all 6 axis to correct the problem by several degrees + or -.
    6) write down the JOINT coordinates of the new point.
    7) Now calculate the difference in degrees between the original point coordinates and the new one. For example, if J1 was at 123.600 degrees and you positioned your J1 to 124.500 to correct the point then the difference will be +0.9 degrees.
    :smiling_face_with_sunglasses: put your robot to SOFTWARE 0 position. (not witness marks).
    9) activate the position screen and switch to JOINT frame.
    10) add or substract the differences you wrote down to each axis.
    11) remaster your robot to those positions.


    Again, I would strongly advise you against this strategy. It effectively means your robot has a "custom" calibration away from its marks.

    I have been working with M710i to M710iC-50E robot models from RJ2 to R30iB and it's kind of my specialty model :icon_rolleyes:
    In the link above I have uploaded 2 videos demonstrating the speed these robots can reach on path sensitive applications like work-piece precision grinding operations. This is a mix of Joint linear circular and cirle arc motions. Also linear motions controlled in degrees/second speed.
    Also, HAWKME states it will take a longer movement to accelerate the robot to its maximum linear speed which is 4000mm/s. This is not true for linear movements. I can confirm that linear movements ignore (or semi-ignore) interpolation between previous and next point and can easily reach 4000mm/s in small distances (even less than 200mm point distance can reach 4.000mm/sec speed although it is pretty violent and hazardous for the robot happiness concerning the deceleration). Joint moves on the other other hand are highly interpolated and the speed is higly based on distance travelled and next point speed setup.


    https://www.youtube.com/watch?v=id5pCr9wtE4


    https://www.youtube.com/watch?v=Ot6bmwicUo4


    In my opinion, take a closer look at R1000iA 80F. It is a little Stronger than the M710iC and a little faster.



    RJ2 Controller motion planner was 1000times better than R30iB motion planner. :icon_neutral: I am sorry I couldnt hold myself. I had to confess.

    Long story short but my problem is what the title says. One of the robots during production time decided to roll back a file to a previous state. Some more info about the Cell integration:
    It is a treatment cell for metallic pieces. 2 robots are used FANUC M710iC 50E and the cell automation is controlled by an OMRON PLC. The robots comunicate with each other and the PLC with internet protocol. 1 robot is set as master the other as a slave. In both robots there is a MAIN_PROGRAM that handles the generic automation (such as manipulator grippers and pick and place parts) and the comunication of the robots with each other and the PLC, and inside the MAIN_PROGRAM there is a call for the process .tp file which is different depending the piece to be worked. I am also using USER_FRAMES on both robots so when I need to program a new piece for grinding and polishing I do the master and then copy the program to slave. The whole cell integration and the robots are also connected to our LAN network and I use Roboguide where I have created the cell and the robots (by creating an exact copy of them from the LAN).


    So 2 days ago a strange thing happened. I created a new .TP program. I tested it and after some minor changes I copied the .TP file to slave. I started the automation and after 2 hours I noticed that robot 1 (master) has rolled back the .TP file (in the state before the minor changes I described earlier). Robot 2 had the latest file. The automation never stopped and I am sure I never exported the older version of the file from ROBOGUIDE. Anyone has ANY clue as to what may have happened ???? :hmmm: :hmmm: :hmmm: :hmmm:

    what are you guys in this company ? :icon_mrgreen: Fifteen year olds ? :love029: Can't you just arrange a meeting and discuss the issue like professionals ? Sometimes the simplest solution is the best option.

    You need to Touchup the points the message pops at again in step mode by following the program flow from start to bottom in step mode. Just follow your programmed points from start to finish and re-touchup the problematic ones but dont try to jump directly to those points and re-touchup because there is a serious chance this will screw over the wrist alignment configuration. This will solve your problem.

    Yes you can.
    During point teaching while you are at the desired point press F1 'POINT'. Then instead of pressing enter after choosing the desired motion from 4 options press F1 again 'ED_DEF' which stands for 'Edit Default motion options'. Here you can customize the 4 options to your liking.

    provided you have TCP/IP Interface installed and configured you can use options like the robot's webpage and FTP in command prompt to send and recieve files from and to the robot. The best option though would be ROBOGUIDE with serialized robots directly from the LAN Network. This way you can have a live backup of all your files in real time.


    Please see attached. I did this in Roboguide with a R1000iA/100F running Handlingtool V8.20.


    Then it is robot dependant or Roboguide autotranslates the hexademical notation. My R30iB controlling M710iC robots still reports hexademical notation. The alarm manual for R30iBs still "talks" about hexademical notation too.

    While this was the case on R30iA and earlier, the newer R30iBs just list the axes in question that are causing the issue. You no longer need to look up the hex code.


    No it doesn't. I cannot really help you with your project as it is a development part never touched by me but I can tell you for sure the numbers still refer to hexademical notation even on the R30iBs.

    The number after the A is the hexadecimal digit that shows which axes are out of limit. The Hex indicates that the axis numbers are in hexadecimal format.
    Based on your message axis 1, 2 & 6 are out of their interaction limit. If you require further assistance you can contact me to give you the Hexademical table interpretation from the oficial FANUC manual.


    edit: A:2,3 is a bit misleading. If it is A:2 then its an axis 2 limit error. If it is A:3 Axes 1 and 2 are out of their interaction limit. If it is A:23 the Hexadecimal notation points to axis 1, 2 & 6 out of interaction limit. I never trust the motion planner when creating new programs anymore. Especially in my kinds of applications where the robot needs to move like a delicate human hand to perform fine grinding operations on small metal pieces. Motion planner apparently likes to mess up the rotation configuration of 4,5 & 6 axes for no reason when creating new points leading to a waste of cycle times and many times limit interactions. I made a habbit of always confirming kinematic configuration when creating new points.


    Hope this helps.

Advertising from our partners