Posts by Famous_Fella

    I doubt high-speed skip will help you on this kind of application. Is the workpiece flat or contoured? does the suction path involve tool orientation change?

    you can try this strategy:
    First set $MISC_MSTR.$hpd_enb to TRUE and make a cold start.

    slowly move the robot TCP towards your workpiece monitoring at the same time axis disturbance screen. Split your screen in 2 windows. Continue moving towards your workpiece until you identify which axis has the highest disturbance. Let's say its axis 5 and the disturbance just before a collision detection is 3.5.

    Then you can make a routine like this:


    J P[34] 100% CNT10 (clearance before piece)

    SKIP CONDITION $MISC[1].$HPD_TRQ[5]<(-3)

    L P[8] 10mm/sec CNT100 (approach

    L P[30] 1mm/sec FINE Skip,LBL[5],PR[18:workpiece touch]=LPOS
    PR[18:workpiece touch,3]=PR[18:workpiece touch,3]+5
    L PR[18:workpiece touch] 5mm/sec FINE
    JMPLBL[6]

    LBL[5]
    Pause
    *Put here logic that will handle the case where the robot doesnt find a workpiece during the search routine

    LBL[6]
    *cleaning path*

    If your nozzle normally touches the workpiece at for example Z= 30, modify P[30] z coord to 10, robot will try to slowly reach 10 and it will stop when the disturbance on the axis you defined (in the example axis 5) will reach the skip condition limit and save that position to PR[18]. Then it will increase Z coord of PR[18] by 5 mm and move to that position. From there, you can create a cleaning path with multiple ways:

    You could create your path as an offset to PR[18] or by using incremental moves.

    You can use PR[18] as a frame and program your cleaning path to that frame. Every cycle the robot will recalculate the User Frame and modify the cleaning path.
    To define the mentioned PR as a working user frame you can follow this example:


    You need to give some more details concerning the application. What type of application is it? is it a pick and place? machine tending? arc welding? What is the robot model and which controller ?

    There are 2 functions that can help you with what you are trying to achieve. One is touch sensing and the other one is touch skip function. Touch skip usually comes together with high sensitivity collision detection function.

    If you have neither of these, then you can use High-speed skip instruction which is standard on all robots with a skip condition that monitors disturbance of the axis (or axes depending on the kind of move) but this is not really sensitive, that's why you have to give more info on the kind of application you are working with.

    You can save some hassle and look for a global vision system like pickIt which is very cost effective and a plug and play solution.

    From where is "home" pressed? Do you use a PLC ? If you are using a PLC then you first need to go to SYSTEM > config and set Enable UI signals, CSTOPI for abort and Abort all programs by CSTOPI all set to true.

    If you are using a PLC then you should map your UI signals (Cycle stop is the one we are interested at) to a set of DIs. After completing those steps there are a ton of ways to send robot home. You can create an R_HOME macro for example and assign it to a DI bit. The PLC can raise both the CSTOPI signal from the mapped DI and the HOME signal.

    If you don't use a PLC you can map your UI signals to flags using rack 34 I think. Then you can use Background logic to raise the flag associated with CSTOPI and then another Flag to activate r_home macro. Be advised that mapping your UI signals to flags is compromising safety and is not considered good practice. It is not advised at all and it adds additional thought on the design of the system.

    You cannot use BG_LOGIC to call a motion program.

    Ok lets see.

    1) Press MENU > SETUP and choose prog select option. From here you can customize several things concerning how the robot will start and what to check during production (AUTO) mode. The first option is your program select mode, press F4 CHOICE choose OTHER option, enter, press F3 DETAIL and manually modify variable $shell_wrk.$cust_name by pressing CHOICE and choosing PROG_1 TP from the list. You can also configure several safety checks before a program starts such us if the robot is @ home pos before start.

    2) Yes you can. Create your desired function by using Argument Registers for your parameters. Here is a sample function that initializes a PR for me (notice the indirect addressing I use to assign the parameter):

    PR_INIT.TP:

    R[80]=AR[1]

    PR[R[80]]=LPOS

    PR[R[80],1]=0

    PR[R[80],2]=0

    PR[R[80],3]=0

    PR[R[80],4]=0

    PR[R[80],5]=0

    PR[R[80],6]=0


    CALL PR_INIT(55)


    3) This is called standard I/O assignment and it is performed automatically. Depending on the communication protocol you have selected for your project (Profibus, ethernetIP, modbusTCP etc) and provided you have set up the connection properly, you configure the DI/DO based on the rack and slot number of the logical signal with the physical signal (the signal from the connected device). You map the logical signals (DI/DO) to the physical ones. If for example you have the EthernetIP option and you have already configured the connection, you can go to MENU > I/O > Digital press F2 > CONFIG and map the logical signals to their physical locations. Here The rack indicates the kind of I/O module installed on your system and slot indicates numbers of I/O module which compose the rack. For ethernetIP rack is always 89, for ModbusTCP for example rack number is 96, and the slot is 1 because i do not use adittional I/O modules. So DI[1-80] is located on rack 89(EthernetIP) slot 1 starting from physical address 1. DI[81-272] again on rack 89 slot 1 starting from 81 etc etc.

    4) For all the above options you need to have EthernetIP optional function on the robot. EthernetIP includes FTP, Advanced Internet Connectivity and Customization, and Socket Messaging. If you do have it, you need to configure host comm properties through MENU > SETUP > host comm. There you configure the robot's TCP/IP params (be carefull as to configure the port you actually use), IP, subnet, router, pretty easy stuff, After that, you can load your TP programs to your robot (provided it is on the same LAN network your PC or LAPTOP is connected to) using Roboguide or the robot's FTP. You could even use external FTPs to save or backup your robot programs daily, or access and download files and programs from other robots' FTPs provided they are connected to the same network of course.

    EDIT: you also need to Ascii Upload option too as HawkMe says, I didnt mention it as Ascii upload comes as standard in Europe. But then again you also need roboguide too, who writes .TP programs in notepad nowdays ? :grinning_squinting_face:

    concerning the palletizing program, you could automate the function:


    This way you only need to teach 3 positions relating to approach and deposit of the first piece. Robot will calculate everything else.

    The correct way to do what you want is to use Diag_GRP[1].CUR_TCP_X, Diag_GRP[1].CUR_TCP_Y, Diag_GRP[1].CUR_TCP_Z system variables to determine the currect robot TCP position in Cartesian Coords (WORLD) insite a BGLOGIC program running on High Priority.


    Use your own DOs depending the TCP Location. Create a home routine and use those DO signals to safely exit any danger zone (defined in the BG logic) and return home. BG logic will constantly update those DOs based on its current TCP location. Each time you will call your Home routine, the robot will use some branch logic (IF-ELSE) based on the signal ON from the BG LOGIC to decide the exit strategy and safely return home.


    You can even use CUR_TCP_W, CUR_TCP_P, CUR_TCP_R which represents your TCP orientation to better define your danger zone. Or you can use Space Function which is a standard function although I find that creating my own Space Function is a lot more reliable than the embedded space function that has a lot of bugs (especially when using continuous turn axis).

    This is a sample code that defines 3 "hazard zones" for my robot and constantly checks for them.




    and this is my R_HOME macro:


    But a Vernier read by human eyes does lie, if only just a little.

    For the procedure I mentioned above you dont care about the human error involved when you use the verniers to identify the gear ratio from the pulse coder count. That is because even if you miss the vernier by lets say .2 mm you still get the gear ratio by dividing the pulses by the ppr of the motor. The division will give you something like 5,04 or 5,0008 but you have still identified the gear ratio being 5.

    That's what I ended up doing -- as it turns out, the mfgr data for the gearbox was incorrect or incomplete.


    Although I simply rotated it 360deg until the vernier lined up again, calculated the ratio between 360 and the POSN value the pendant showed for J7, then adjusted the gear ratio again. Worked a treat (well, the second time -- the first try, I got the ratio backwards and made the problem worse).


    Now, at 0 and 360, the verniers line up perfectly. I imagine that if the axis were to be used in an infinite-rotation style (which is is physically capable of), any rounding errors would build up over distance, but this application has J7 limited to between 0 and +360deg, so it's not an issue.

    Pulsecoders never lie. You just need to be sure about the ppr of the motor.

    If I may add, you don't need any gearbox or reducer data to calculate the gear ratio.


    1) declare and master the external axis in Controlled start under maintenance, use the Vernier marks for zero as this mastering is only temporary.
    2) Boot into Cold Start, go to STATUS > PULSE. Be sure to choose Group 2 from UTIL menu and write down the Pulse count. Your external axis should be aligned to the Vernier marks.
    3) Jog the external axis 1 full rotation until it is realligned with the Vernier marks. Substract the pulse count of the full rotation from the pulse count obtained from the previous step and divide by 1.000.000.
    I am 90% certain, αi/βi series motors use 1 million pulses/revolution encoders but you can verify that on the motor manual and the manual number is posted on the motor sticker.
    4) By dividing the difference in pulses for a full rotation by the ppr (pulses per revolution) of the encoder you get the motor shaft revolutions required for a full rotation, you return to maintenance in Controlled start and modify the gear ratio of the motor you added.

    5) you can now remaster your axis by performing a Cold Start and jogging the axis to your prefered position.

    Thank you all very much for your help.

    FANUC finally agreed to send me a new image containing the AOA backup with the correct files. I am still experiencing minor issues compared to the robot behaviour with the old software (mainly constant path and CPMO errors) but I can live with them and I am still investigating into what's changed to cause this weird behaviour (Constant path is disabled but I still get errors concerning CP) but all in all it is back in working condition with all the old files loaded.

    Of course Sysvars will not load. You changed your hardware, the old variables won't work with the new hardware. There is now a new array for each system variable for the new motion group.


    I've been down this exact road before. Fanuc will not have a solution.

    Again, if you want help with posreg.vr, just let me know.

    yes, yes I dont forget about it. I just want to see where the FANUC road leads. They strongly insist the backup restore process should finish and cold start regardless of the conversion problem.

    Update on the matter:


    Forget about being able to load all but sysvars.vr and posreg.vr.


    After the installation of the equipment hardware (aux axis servo amplifier and motor) I proceed installing FANUC_IMG, image installs fine, I am also able to Start COLD on a fresh system, but trying to restore the all of above backup and then START COLD system hangs before booting the operating system with a black screen. Fanuc Rotational logo never displays. If I force a power restart when in black screen, system starts booting, FANUC logo appears, and after 20-30 secs I get a robot page error "Controller startup timed out". I also tried an INIT START (as suggested by FANUC) before restoring the all of above backup but to no success...

    Digging a bit through the matter, I came to the fact that 3 files are responsible for crashing the system: SYSVARS.VR, SYSSERVO.SV, SYSMASTER.SV. Loading any of the 3 files causes the controller to crash and not load the operating system. I know I can live without SYSMASTER (and even SYSSERVO maybe) but not without sysvars.

    Fanuc has no clue as to why this is happening, they never faced such a problem before and they are very skeptical about it. They say there is no problem between new image containing a newer version than the previous controller version I was already running and system should handle the conversion of the files fine.

    Tommorow I have a video call with one of FANUC Italia's chief techs concerning the matter. He wants to run some tests.


    Of course, POSREG.VR refuses to convert (I mean even if I skip those 3 system files I mentioned)

    I would have suggested installing a PAC instead of new image, then you wouldn't need to reload any files. There's likely nothing you can do now besides ask Fanuc to convert for you.

    This is what I asked from the begining but this is the standard procedure used by Fanuc Italia. They don't use PACs. They only provide new images when you wish to add a new software option.

    Hello,

    after some months of R&D I decided to create a servo-gripper for one of our robots with a fanuc servo motor directly attached to the gripper of the robot. Long story short, we had to upgrade the software suite with Independent Axes and multi-group motion so fanuc asked for an all-of-above backup of the robot and an image backup also and after some days they sent us back a modified image with the needed software.

    The idea is that after upgrading the robot with the new image sent from Fanuc reloading the all-of-above backup would give us a working robot just as it was with the addition of the new software. Image installs fine, robot upgrades controller firmware and tp firmware, everything goes as planned and after the image installation I do an Init start and proceed to controlled start to load my old all-of-above backup to load my registers sysvars tcps frames programs etc etc.

    When the restore procedure hits the posreg.vr file though, it prompts a message if I want to convert the file and shortly after hitting yes it reports an error "array mismatch" and proceeds with the next file. Same happens with sysvars.sv file.

    Digging a bit more into this and with the help of roboguide I discover surprised (=because it should have been obvious to me from the begining) that in the new software the position register structure has changed from
    PR[...]: [GP1]:{x:..., y:..., z:..., w:..., p:..., r:...}
    to
    PR[...]: {[GP1]:{x:..., y:..., z:..., w:..., p:..., r:...},
    [GP2]:{x:..., y:..., z:..., w:..., p:..., r:...}}

    and I guess this is the array mismatch that doesnt let the system convert the old posreg.vr file. Is there a workaround to this other than the obvious of manually filling every coordinate value on 118 position registers ? even if I get in all this trouble for the posreg.vr file I can't do the same for the sysvars.sv file as there are so many variables I had changed that I can't remember.

    I use OMRON Machine Automation Controllers and I am really very happy with their controllers. Ethernet/IP is our communication choice and the intergration is really smooth and nice. I am very pleased with sysmac studio suite and all omron tools.

    Siemens controllers are really overpriced for what they offer and we really found some omron entry level products offering twice as much in comparison to their siemens equivelants. Maybe because omron is trying to get a bigger cut from the europian pie ? Maybe. I also find TIA portal a bit overwelming and bloated in comparison to sysmac which is a bit more straightforward on what you want to do.

    Sounds to me like your power supply is failing.

    That is why you lose power after set time, a winding opens or a solder joint separates from heat then as it cools it re forms itself. By the time you restart it things have cooled and it is all good. Reheats and re-fails. Lather, rinse, repeat.

    Just my thoughts.

    My thoughts were also along these lines but as these parts cost several hundreds of Euro, I can't order a part and charge my company based on a notch or on the fact that nothing else fits as a failure. There should be a way to diagnose abnormalties on the PSU and nothing is documented.

    Hello,


    I am facing an odd issue on one of my robots and I would like some feedback.

    One of my production robots, an M710i with RJ2 controller is experiencing loss of power in a really strange manner.

    The power loss happens during production cycles as well as idle times.
    The power loss is not exactly a power loss, the teach pendant goes off, the operator panel LEDs go off and the servo amplifier also, but on the PSU board both PIL (green) and ALM (red) LEDs are active.

    If I use the OFF switch on the operator's panel the ALM led on the PSU switches off and the OFF button seems to work as intended cutting the power to the controller. I can the restart the Controller using the ON button and the system boots up as it normally does. After a time period of 10 to 20 minutes no matter if on production or idle, same thing happens.
    There is no alarm recorded.
    There are no signs of over temperature.
    Both system fans are clean and working on the backplane.

    There are no alarms on the Main CPU board and the system otherwise behaves as intended.

    There is no documented case on the FANUC RJ2 Controller maintenance manual to guide me on propable causes and corrective actions to take.

    I could not find a similar thread no matter how hard I tried the search function and that makes me scared a bit. :smiling_face_with_sunglasses:

    I have spent many, many hours trying to convert the values from system variables concerning torque, max. torque, disturbance torque to match the Teach Pendant monitor values and I have concluded that the numbers in system variables concerning the HPD_TRQ[] array are double types and they in fact represent Amps (A) and match what you see on the Teach Pendant. So this you can use safely.

    Now concerning MOR_GRP system variables this is a whole lot different story. Values stored in $TORQUE, $MAX_TORQUE, $CUR_TORQUE are of type UINT and they are raw data coming straight from the Servo's DSP (Digital Signal Processor) cast internally by the Teach Pendant's Kernel to represent a measured value for MONITOR. I have not found a way so far to "pull" the value of the TP monitor screen because that value in my opinion is not stored in a system variable rather it is processed on-the-fly and updated.

    A method around I used to tackle this problem was to collect a big sample of data seperately for each axis from both the value of the variable and the value on the teach pendant and compare the mins and max between specific time intervals to find MINs and MAXs as a percent.


    Creating a Real-time robot torque monitor in PLC HMI


    This was a project of implementing a Live Robot Monitor directly on the PLC's HMI. Scroll to my last post and you can see a video.

    I guess from using an offset that your Pos. Registers are unlocked? I have never used DPM but from what you describe the only thing similar that comes to my mind is trying to run a path when your moves all have offset to PR motion command and your Pos Regs are unlocked. Can you separate your commands into segments of commands, unlock your Pos Regs recieve the offset from the socket, lock Pos Regs, run the motion commands unlock P Regs update from socket etc ?

    When your Pos Registers are unlocked the robot cannot make use of its look ahead function as a safety measure. (your Pos Regs are unlocked so they can change anytime from any source, so the robot's motion planner reads the position register you use for offset and applies it to the motion line by line)

Advertising from our partners