Posts by Muteki

What version of Roboguide do you have?

Quote from HawkME

Changing the area where the robot was moving had a big effect on speed.

What exactly do you mean by this?

   1:  UFRAME_NUM=1 ;
   2:  UTOOL_NUM=2 ;
   3:   ;
   4:J PR[1:Home] 100% CNT100    ;
   5:   ;
   6:J P[1] 100% CNT0    ;
   7:   ;
   8:L P[2] 10000mm/sec CNT0    ;
   9:   ;
  10:L P[1] 10000mm/sec CNT0    ;
  11:   ;
  12:J PR[1:Home] 100% CNT100    ;
  13:   ;
  14:J P[3] 100% FINE    ;
  15:   ;
  16:L P[4] 10000mm/sec FINE    ;
  17:   ;
  18:L P[3] 10000mm/sec FINE    ;
  19:   ;
  20:J PR[1:Home] 100% CNT100    ;

It is a super simple program, I was just trying to get an idea for cycle times with different robot types. I tried everything FINE, everything CNT100, mix and match. Nothing got the robot speed above 1500mm/s.

I tested this and this is not the issue, the peak speed remains about the same never going faster than 1500mm/s.

I am trying to mock up some cycle times for a proposal to a customer. I am using a delta robot M-3iA/6A with some simple paths to get a rough estimate for cycle time. However even though all my speeds are set at 10000mm/s and 100% the robot never moves faster than 1500mm/s.

Is there some setting I'm missing? Does Roboguide not support full speed for delta robots? Has this been happening to every robot on Roboguide and I just never noticed?

Fun fact about the String Registers, you can add them together and use them to indirectly call programs or vision processes.

SR[1] = 'ANY'

SR[2] = ' STRING'

SR[3] = SR[1] + SR[2]

Now SR[3] = 'ANY STRING'

I use them a lot for choosing vision processes when my system has several different parts it needs to check or move.

Another thing is to make sure you set the correct Z height of the part. I have forgotten this setting plenty of times at it always causes some pretty bad error in the positions, which gets worse the father away the parts are from the original taught position. It is especially annoying because you have to possibly reteach the part if you moved it from the original taught point (pro tip don't do that).

HawkME has the best solution to this.

Instead of letting the operator choose the program and then double checking with the PLC, you should let the PLC choose which program to run. You can set up a remote program check that allows the PLC to select which program is going to be run.

Like HawkME said if you still want to monitor which program has been selected take a look at the $SHELL_WRK.$rout_name or $TP_DEFPROG system variables.

Check your PMs

First you would need to keep track of which welds you finished before the robot faulted. You could use a register to keep track or maybe send a signal to your PLC after each weld is finished. You then use whether or not the weld was finished as a condition for turning on your torch, so that the robot doesn't try to reweld seams during the dry run.

When the robot faults you need to store the robots current position, you can use the LPOS command to set the current Cartesian coordinates to a Position Register. You can send this info to the PLC and the PLC can check when the robot reaches that position before turning on the torch. Or you can do it on the robot side, by just heading to that PR when you get to the weld instead of the original Position and start from the PR instead. There are several different ways to do it, you can do it in whatever you feel the most comfortable doing.

I am not certain what deficiencies the R-J3 controllers have versus the R30 controllers since I don't work with them often. Personally I would try to do as much control logic through the PLC because I don't know the R-J3s as well.

I worked with a lot of companies that start out the same way, by doing contract controls integration. They can do panel builds and basic PLC programming, and anything mechanical that they need done is contracted out to another integrator. This would be a good way to get your feet wet, and also get your foot in the door for future costumers. Panels can be built and tested in house, you would need someone to install everything onsite, but most of the wiring that needs to be done onsite is not high voltage, and won't need a certification to do.

Another big ticket item for small integrators is upgrades. Every shop in the US will have equipment that is more than 20+ years old. They have panels full of obsolete parts that the manufacturer no longer supports, and the costumer can't get spare parts for. Most manufacturers have white pages for what parts have gone obsolete and what parts have replaced it. It won't always be as simple as swapping the parts out, but it is relatively straight forward and there is a lot of documentation on it.

Robots are very powerful automation tools, but it would be hard to jump straight into robot jobs first thing. Robots are the center piece of an entire system that needs a lot of support. Mechanical teams need to design the frame, tooling, harnesses, and dressouts for the robot. Usually a PLC and HMI to handle all the processing for your sensors, and communication to other systems. There is a lot that goes into robot integration. But there are some integrators that contract out specifically for robots, so it isn't impossible to break into integration from a purely robot background.

I can confirm that HawkME 's code gives the correct position coordinates. Make sure that the configs match with the solution and the rest of the positions though. When I did it the Matrix gave the config NDB, I don't if there are sysvariables that can change this or not.

Fanuc's iRVision system is processed through the robot controller. You can even set everything up from the Teach Pendant, but it is much easier to do from a laptop connected to the controller.

You can also monitor the vision system from the teach pendant as well, but again it is way easier to do from a laptop or PC.

Quote from WhyAmIDoingThis

Now our "issue" :

2 mechanical engineers claim that all movement commands should be implemented on the pendant and create program for every single movement , which is

impossible since our vision service is sending position data constantly via pcdk .

Technically all movement commands are being implemented on the teach pendant. The robot is the one that executes the movement you are just updating a PR with new position data.

The robot knows when it can't move to certain positions, and if you have DCS set up correctly it isn't going to run into any other equipment. So the robot isn't going to hurt itself or other equipment in the cell.

So long as it is safe and works well comments about how the code is written seem pretty nitpicky to me.

Also making a program for every single movement sounds super dumb. It would waste processing time if I had to call a different program every time I wanted the robot to move.

Fanuc's standard operational use is in regards to actually using the robot, not programming it. There is nothing in their user's manual that say anything about how you should program something.

When you get the IMTP-222 error it should also give you the program and line number where the error occurred like this; IMTP-222(Program name, Line number).

If you go there you can see which program it was trying to call when it faulted.

Check you PMs

you can use the RUN command to run a separate program that updates the Z direction of a PR by a R then sets a UFRAME to that PR. That way you can adjust the UFRAME just by setting a Register value, which can be done through the Teach Pendant while the robot is running.

This way you can change the value on the fly without downtime.

These errors are related to the Safety board in your controller. The first error you listed is the robot looking for a safety PLC connected through PROFINET, if this is on one of the new robots it might not have PROFINET set up.

If you do not have a safety PLC you need to set PROFINET safety to bypass in your DCS settings.

It would be easy to fat finger the program shift if it was used previously and wasn't cleared. If you go to the Program Shift menu and hit the Next button there should be a softkey option to clear all the data.

Quote from ericwiz7923

How do you prevent those programs from being run in unsafe positions but still be functional in a practical sense? I'm familiar with the concept and application of program calls via a HMI but they generally make me nervous because I've seen some pretty great crashes start that way. When perfected its a great labor saver though. I've also seen/worked on cells where if you didn't stop the sequence and run home from exactly the right position then it either wouldn't call the program due to the safety interlocks or if it DID then you'd have a robot try and go through something it shouldn't.

It can be a little tricky to get right. For a return to home program there are some different ways to approach it. One way is to keep track of each position the robot goes to, usually setting a unique number for each position to a register, then the robot backsteps from that position.

You can also set up a unique path for returning to home, and when the robot stops, you compare the robots current position to the positions on the safe path to determine which point along the path is the closest.

Also setting up Dual Check Safety is a must on any Fanuc robot. It can prevent collisions before they even happen, and force the user to jog the robot to safety manually.