Posts by SkyeFire

It's certainly not a bad idea. You might not get the benefit of modern I/O networking (ProfiNet, Ethernet/IP, EtherCat, etc), depending on what the Scorbot supports. But I imagine that using an old robot like that will force you to learn a lot about the nuts&bolts end of the robots.

Rather than invest in a modern PLC, I would suggest looking into CodeSys. The "free" version is non-crippled, aisde from requiring a reboot every 2hrs. You can also get a non-commercial license to run in on a Raspberry Pi for $35, last I checked. That would save you the potential issues of having to deal with one of the major PLC brands and their required extra bits. You can then use almost any eBay network I/O device, and generate your discrete bit-banged I/O between the PLC and Scorbot.

Quote from Shellmer

I ended just assuming there would be always a reorientation error, it was not much, but if the deviation was greater than 0.1mm while rotating the results were noticeable.

I've sometimes had to use different TCPs (or corrective offsets) for when the robot was working in different poses. Although that was when I was trying to align two robots to within .25mm over a very large 6DOF volume.

It depends on what you want to accomplish. If you want instant response, then an Interrupt is the way to go. But that means that you will have to have a safe "interrupt path" programmed for everywhere along your regular path, to ensure you don't hit anything.

The simpler approach would be to select certain points along your production path to be "branch points", and add IF/THEN statements at those branch points that check the inputs, and change behavior based on the inputs.

Quote from Matheus_Antonio

DE={X abs, Y odn, Z cot, A rx, B 0, C 0}

Illegal KRL syntax. Inside a STRUC variable's braces, only literal values are allowed. You would need to do:

DE.X = abs
DE.Y = odn

And so on.

Instead of editing point data, you might want to look at using Base offsets instead.

Key questions are: How much corkscrewing? On which axes? Some degree of it is inevitable, no matter how perfectly the robot is mastered or the TCP is taught. It's just the nature of robots.

In the past, I had cause to try creating some very precise TCPs, using a laser tracker and iteratively tuning the TCP values in 0.1mm increments, and quickly found a point where reducing the error on one axis increased error on the other.

Quote from machuca :)

in order to select bits to choose the job, could i only can configurate it in the config.dat A20 fold?? or can i just separe the bits with the expression

SIGNAL JOBSLC_FRONIUS $OUT[321] TO $OUT[326]

I'm not sure what you're trying to do here. The SIGNAL line defines the Integer variable JOBSLC_FRONIUS as $OUTs 321-326. Setting JOBSLC to an integer value (say, JOBSLC_FRONIUS = 17), will convert that integer value into binary and turn $OUTs 321-326 on/off to a binary pattern that matches that integer. So:

17 = 010001
63 = 111111
48 = 110000

and so on.

Quote from machens

However, due to the low accuracy of $OV_PRO, the robot shakes during the speed change.

That's... odd. I don't recall ever seeing this happen. This happens when you make a 1% change in $OV_PRO? How fast is the robot moving when this happens? How much does it shake? Is your $LOAD data accurate? What model of robot is this, and how old is it? What kind of joint pose is it in when you see this shake? What is the value of $FILTER?

Disabling Safe zones is something to be approached with EXTREME caution, so it's good to be leery.

I would NOT let anyone disable Safety zones from an HMI without additional safeguards. Just off the top of my head, I would add Teach mode as an additional interlock -- that is, the HMI signal can only disable the Safety zones if the robot is in Teach. Putting the robot into Auto would cause the robot to ignore the HMI signal.

I would also consider making that HMI signal edge-triggered. That is, we want to protect against someone leaving that signal on forever because "oops I forgot". So condition it based on, whenever the robot has been switched to Auto mode, the HMI signal gets ingored unless it's explicitly turned off and back on again.

What model KRC are you using? With what KSS version? And what TP options? How are these programs being generated?

The RAM available to KSS is much less than the physical RAM installed. The last time I ran into the RAM limit, it was ~4MB of KRL modules, IIRC. I don't think there's any way to load a set of program modules that exceed that total memory at the same time.

This forced us to use the DirLoader option, as Panic Mode suggests. Streaming data points from a remote computer using the EKI option would be another possibility. Or loading large arrays of data points from a large text file using the KRL file commands that have been part of KRL since KSS 8.2/8.3.

There are also ways to reduce the size of a KRL program module without losing any data. For example, most KRL modules include at least one line for every motion in the .SRC file, and at least one line for the point position data in the .DAT file. Many post-processors also generate multiple additional lines of frame data and motion data for every move in both files. Changing the module to an SRC-only file that uses explicit values instead of .DAT variables (basically, LIN {X 100,Y 200} instead of LIN xP1} can cut the memory load of a module by as much as 45%, depending on other factors.

Quote from Shellmer

Not the best of the world as I usually try to not use Karel, but the math functions are only avaiable from there.

You can buy the Math option for TP. Or, if your Fanuc has certain irVision packages installed, they bring the Trig functions with them.

But, yes -- Fanuc regards any math more complicated than basic addtion/subtraction/multiplication/division as a paid option.

Just spitballing, but... what if you created a UFrame whose Z axis passes through the center of the cone? Program a PR on the circumference of the cone base, then rotate the UFrame around its own Z axis and keep running to that PR. That should generate a circular motion (you might have to un-rotate your PR to avoid winding up the wrist, though).

Then, you might be able to generate your X,Y coords based on the Z value, and generate something conical that way.

Quote from Reflex

i think to use a counter for that but i'm not sure if it will work (i will try it for sure).

There are multiple ways to do this. Nested FOR loops are one. Counters would be another. A third would be a 2D array.

I tend to use a counter for each axis of the grid, and select my positions accordingly, usually using Base offsets. Something like

XCounter = 0
YCounter = 0
YDistance = 50 ; 50mm between parts in Y
XDistance = 75 ; 75mm between parts in X

REPEAT
	REPEAT
  		fOffset = $NULLFRAME ; set to all 0
  		fOffset.X = xCounter * XDistance
  		fOffset.Y = YCounter * YDistance
  		$BASE = BASE_DATA[1] : fOffset ; assuming Base 1 is set up to the table
  		PTP XAbovePick
  		LINE XPick
  		; close gripper here
  		LIN XAbovePick
  		XCounter = XCounter + 1 ; increment counter
  		; move to test jig sensor here
  		IF TestJigPartSensor THEN
    		; move to CNC machine and place part here
  		ELSE
    		; Move to a position near table here
  		ENDIF    
	UNTIL XCounter > XCountMaximum
  YCounter = YCounter + 1
UNTIL YCounter > YCountMaximum

Quote from panic mode

as i recall resuming relative motion after EStop or similar, robot still goes to the exact same point. only when instruction is re-selected (block select), robot would do complete new motion and thus adding distance to part already travelled. but... that is just my recollection, to be sure i would have to check that on a real robot.

I'm not sure I ever actually tried it. But I got (gently) raked over the coals by a KUKA Germany engineer for using LIN_REL instead of the Geo Operator, because (according to them) LIN_REL had this issue, and told in no uncertain terms to remove LIN_REL from all my code.

Granted, that particular project would have incurred damage between 5 and 7 figures every time the robot over-travelled on those LIN_RELs, so... but I took that instruction to heart and avoided LIN_REL religiously ever since.

"Straight down" in what coordinate system? The Tool or the Base?

There are two main ways.

The easy way is to use the LIN_REL command. This moves in Base by default, but you can also append the optional #TOOL argument to change it to a Tool coordinate move:
LIN_REL {X 0,Y 0, Z -100,A 0,B 0,C 0} #TOOL
One weakness of LIN_REL is that if the command is interrupted by something like an E-Stop, the command will start over when the program resumes. So in the above example, if an E-Stop occurred when the robot have completed 50mm of the 100mm Z move, after resuming the robot will end up moving 150mm in Z.

The less easy, but stronger, way is to use the Geometric Operator. There are lots of discussions of this in the forum archives, but basically it's a way to calculate the end result of a Cartesian coordinate and a Cartesian offset. So, to perform the same Tool -Z move as in the LIN_REL example, one would
DECL E6POS eTempPos
eTempPos = xP1 : {X 0,Y 0,Z -100,A 0,B 0,C 0}
LINE eTempPos
or
PTP eTempPos

One advantage the GO method has over LIN_REL is that LIN_REL can only perform Linear motions, and the joint equivalent PTP_REL cannot work with Cartesian coordinates, only Joint (E6AXIS) coordinates, while the "normal" PTP command can move to either E6AXIS or E6POS coordinates.

Details are crucial here. How is the ring mounted to the robot? How is your motion program rotating the ring? Have you measured the eccentricity?

As a general rule, programming any robot to hold the TCP in place and rotate it around one axis or another is not going to produce high-accuracy motion. The more complex the rotation, the more axes are involved, the worse the accuracy gets.

To a degree, this can be mitigated by fine-tuning your TCP, in the location/orientation where the work will be done (TCP motion error changes depending on the robot pose). Rigidity of the EOAT also matters a lot.

The ideal setup would have your ring dead-center on the axis of J6, and do the grinding motion by moving J6 by itself while keeping J1-5 completely stationary. That lets you rely on the mechanical accuracy of J6 itself and your EOAT, and remove inherent robot accuracy error from the equation entirely.

If the ambient light is causing, or contributing seriously, to your glare problem, an overhead awning is a mitigation I see used pretty often.

Quote from Chall234

I will try shooting with the ring light off, I can't, unfortunately, turn the overhead lights off, because safety will have a fit.

Just blocking the overhead light (with an umbrella, say) long enough to take the test shot would serve. The main goal is to get a handle on possible alternate sources of the glare.

I once had a MV operation fail because of a ceiling lamp over 75m distant -- my camera was looking through a hanging part at a slight upwards angle, and about 1 out of every few hundred parts, the camera's line of sight would line up through a hole in the part with that distant ceiling lamp. That one was easy to determine b/c I could see it in the images, but I couldn't get that light shut off (or shoot it, though I was tempted). Ended up doing a bunch of hacky software changes to try to work around it. Stupid thing never did work 100%....

Angle will definitely have an effect on glare, so fixing the bracket can't hurt. The key will be the angle of reflection between the light, bar, and lens. If you can duplicate that from the working system, definitely try it.

Are these cameras fixed or robot-mounted? If the latter, a quick way to play with reflection angles is to just jog the robot a bit in various directions and see if the glare gets better or worse.

Quote from alphatango

BTW: all work programs all marked with red "X"

Then look at which lines in those programs are causing the issue. That should point at what variable or subroutines are missing.

Quote from alphatango

the robot had to be reinstalled due to an error in the flash module.

What does this mean? There is no "flash module" in a KRC. Do you mean the hard drive failed? Does this mean you performed a re-intall of KSS from scratch? If so, did you also re-install all the TP options? The work programs might be attempting to access TPs that you did not yet install. Checking the actual errors will, again, help to point this out.

Which way is the polarizing film rotated? If the polarization is aligned with the long axis of the bar, that might be letting the glare through. Try rotating the film 90deg.

Try shooting the bar with the ring light off, and with the overhead lighting off, and with both off, and see what happens to the glare. The goal here is to determine what sources are generating the glare. You could have some lighting far away that's bouncing in unexpected directions.

What kind of camera, lens, and lighting are you using? What's the ambient lighting like? Are your irVision configurations in both robots the same? What version of robot OS and irVision are you using?

I doubt this is an irVision-specific issue. Rather, it's a standard issue that everyone using Machine Vision struggles with.

Rule 1 of MV: Lighting is everything
Rule 2 of MV: Sunlight always beats your lighting. I once had to have a plant skylight painted over b/c a system that worked fine all spring/summer began failing once winter sunlight started coming through at the right angle to hit my work area.

MV on round objects is always an issue, b/c a direct reflection from any/all light sources is almost guaranteed to hit the camera lens directly. This is typically addressed by using diffuse lighting rather than point sources like ring-lights around the lens. But diffuse lighting rigs tend to be bulky. My favorite solution (when possible) is to use backlighting, so the camera is looking at the silhouette of the object against an evenly-lit background

Also, most MV lenses have adjustable focus and aperture. Sometimes you need to dial down the aperture to reduce the amount of light hitting the sensor, although that usually drives up exposure time.

You could have an irVision config issue. irVision has exposure settings and software filters. If both robots have the same camera, lighting (not just hardware but angles), ambient light, etc, I would try comparing the irVision job setups in both robots. Were these units set up by the same person?