Posts by gmumaugh

Hey all, apologies if this question is too similar to some of the other ones I saw, but I couldn't glean a clear answer from them. I'm setting up some SR-6iAs on R-30iB Compact Plus controllers, but it's been a while since I've had to set up a Fanuc. The factory mastering data was good, but I was getting a warning on one robot that the reference position for the quick mastering hadn't been set. The robot was not at its zero position, which I should have done just to be safe.

Since I didn't need to actually perform any mastering, I ensured $REF_POS were all at 0°, then copied the values from $MASTER_COUN to $REF_COUNT, then set $REF_DONE to TRUE. I figured since I wasn't going through the Master/Cal menu, it wouldn't actually perform the mastering at reference position. However, after checking my position values, J4 was sitting around 700 deg, mistake number 2 was not carefully checking the position values before starting this procedure. I restored the sysmast.sv file from an earlier backup, before I ever touched mastering, but J4 was still showing an extremely high position value.

I decided to check the current pulse counts, and J4 had a value of -16001079, which does actually seem accurate. So is it possible that the mastering is actually okay, and someone just decided to swing J4 around a couple times? Does setting $REF_DONE to true immediately perform the reference mastering? Either way, in order to be safe I am going to redo this procedure with the robot physically at its 0° position.

Error handling is done by adding the ERROR keyword to a procedure. Did you take a look at the SearchL instruction in the documentation? There is an example section that shows how to check which error occurred and what you can do in the error handler:

PROC ExampleProc()
	!...
ERROR
	IF ERRNO=ERR_WHLSEARCH THEN
		StorePath;
		MoveL p10, v100, fine, tool1;
		RestoPath;
		ClearPath;
		StartMove;
		RETRY;
	ELSEIF ERRNO=ERR_SIGSUPSEARCH THEN
		TPWrite "The signal of the SearchL instruction is already high!";
		TPReadFK fk,"Try again after manual reset of signal ?","YES", stEmpty, stEmpty, stEmpty, "NO";
		IF fk = 1 THEN
			StorePath;
			MoveL p10, v100, fine, tool1;
			RestoPath;
			ClearPath;
			StartMove;
			RETRY;
		ELSE
			Stop;
		ENDIF
	ENDIF
ENDPROC

There are some specific keywords that define how to return to normal operation. RETRY will try to repeat the instruction that caused the error, up to 4 times by default I believe. TRYNEXT jumps to the next command after the one that caused the error. Also, the RAPID Overview manual has more information on error handling in general.

This is the normal behavior, there is a note in the SafeMove 2 manual that sort of describes it:

If Manual Operation Supervision is active and the robot is jogged to a non-violation position and then into a supervision violation position again, the robot will stop again. The new violation must be confirmed by releasing the enabling device on the FlexPendant before the jogging can be resumed.

Nothing stops the operator besides the initial violation and common sense (always watch the robot when it is being jogged).

1,2, and 3 on X6 all need jumped together, as well as 4, 5, and 6. The provided jumpers are missing their middle legs so you'll have to use different ones or small wires.

Quaternions are much more computationally efficient than Euler angles and avoid some problems that arise when describing a rotation with Eulers. However, they are unitless, they only describe a given orientation. You can't "rotate by X quaternions", which is why all offset functions still accept Euler angles to build a new set of quaternions.

If you want to understand them more, I would recommend reading the section on the orient data type in the RAPID Instructions, Functions, and Data Types reference manual, which describes how quaternions are calculated. There are also several examples of quaternions being used for spatial rotation, like this one: https://en.wikipedia.org/wiki/Quaternio…patial_rotation

Yes it is a paid option, if it's not there and you decide to go with it, you'll have to contact ABB and get a quote, and there is additional hardware that needs to be installed.

If you can't go with that option, another solution is to use a distance sensor if you have one, either mounted on the robot tooling or mounted stationary above your elements. Then you can write a small program using a linear equation that translates the distance to a position.

You would need the Force Control option. Examples from the application manual describe exactly what you want to do.

Find object position

In this example, the robot will move in the z direction of the world frame. When it
runs into an object, it will stop when the force is 10 N and wait there with a constant
force. The position of the object can then be measured.

VAR tooldata tool1 := ...
PERS loaddata my_load:=[0.001,[0,0,0.001],[1,0,0,0],0,0,0];
VAR pos pos1;
my_load := FCLoadID();
FCCalib my_load;
! Setup the force reference with 10N in Z-direction of the world frame
FCRefForce \Fz:=10;
! Activate Force Control
FCAct tool1;
! Start moving the robot to achieve the specified force
FCRefStart;
! Wait 10 sec, so the robot will reach the ordered force
WaitTime 10;
! Read robot position
pos1 := CPos(\Tool:=tool1);
! Stop the reference values
FCRefStop;
! Deactivate force control
FCDeact;

It could be quite a few things. Is the position it goes to another taught position or somewhere random? Are you sure you are simulating the correct path with the correct points? If you are pressing play from the ribbon, do you have the correct path set as the simulation entry point? If you know you are in the correct path, maybe synchronize it to RAPID in order to analyze it there.

Uploading a pack and go or screenshots will also help analyze the issue.

There is the option 611-1 Path Recovery. You could technically use it to check for this, based on the following chart from the documentation:

To get this to work, you would need to start a recording and stop it before it can be used to check if the robot has moved off-path.

VAR pathrecid origin_id; !Define a path recorder id

PathRecStart origin_id;

MoveJ p1, vmax, z50, tool1;
MoveL p2, vmax, fine, tool1;

PathRecStop;

Stop \NoRegain; !Don't ask to move back when restarting program

IF (PathRecValidBwd(\ID:=origin_id) = TRUE) THEN
	!Robot has a valid path backwards, meaning it is still on path. Reset output
	Reset doRobotOffPath;
ELSE
	!Robot does not have a valid path backwards, robot has been moved since path recorder stopped. Set output
	Set doRobotOffPath;
ENDIF

If you don't have access to that option, you could write a function that returns the shortest distance to a line defined by 2 points. Here's something that could work:

FUNC num PerpendicularDistance(pos Point, pos LineStart, pos LineEnd)
		VAR num nDotProduct;
		VAR num nLineLength;
		
		VAR pos psLineUnitVector;
		VAR pos psLineVector;
		VAR pos psPerpendicularVector;
		VAR pos psPointVector;
		VAR pos psProjection;
		
		psLineVector := LineEnd - LineStart;
		psPointVector := Point - LineStart;
		
		nLineLength := Sqrt(Pow(psLineVector.x, 2) + Pow(psLineVector.y, 2) + Pow(psLineVector.z, 2));
		
		psLineUnitVector := [(psLineVector.x / nLineLength), (psLineVector.y / nLineLength), (psLineUnitVector.z / nLineLength)];
		
		nDotProduct := DotProd(psPointVector, psLineUnitVector);
		
		psProjection := [(psLineUnitVector.x * nDotProduct), (psLineUnitVector.y * nDotProduct), (psLineUnitVector.z * nDotProduct)];
		
		psPerpendicularVector := psPointVector - psProjection;
		
		RETURN (Sqrt(Pow(psPerpendicularVector.x, 2)) + (Pow(psPerpendicularVector.y, 2)) + (Pow(psPerpendicularVector.z, 2)));
	ENDFUNC

You could use this by getting the robot's current position and checking it against the part of the path defined by 2 other robtargets:

PROC PathMonitor()
	VAR num nTolerance:=3;
	VAR num nDistToPath;
	VAR robtarget pPoint1;
	VAR robtarget pPoint2;
	VAR robtarget pCurrPoint;
	
	pCurrPoint:=CRobT(\Tool:=tool1);
	
	nDistToPath:=PerpendicularDistance(pCurrPoint.trans, pPoint1.trans, pPoint2.trans);
	
	IF (nDistToPath < nTolerance) THEN
		!Robot is within tolerance to set path. Reset output
		Reset doRobotOffPath;
	ELSE
		!Robot is outside tolerance to set path. Set output
		Set doRobotOffPath;
	ENDIF
ENDPROC

There are downsides to this approach. You will need to know exactly which 2 points of the path you want to check and corner zones aren't accounted for, but maybe it could be useful.

If you move the mouse towards the top of the window, you will see icons appear. I highlighted the snap options in my previous screenshot. You can also view the current snap level at the bottom of the RobotStudio window. Here I have center snap enabled.

Make sure you don't have any snapping options on, which will be shown at the top of the viewport window and highlighted if enabled.

In your screenshot, you have "Jog Joint" selected which might be contributing to your problem. To do a freehand linear move like you want, make sure "Move and Rotate" is selected, and you have the correct tool, work object, and reference points set.

Quote from SkyeFire

ABB has a specific term for it

That would be "late binding". Essentially, instead of checking if the procedure exists at compile time, it waits until run time to check.

If you do want to change the name of the "main" routine, you can do it by changing the parameter "Main Entry" under the Controller -> Task configuration menu. Just like the default main routine, it can't have any parameters.

Based on your original goals, if you just need to monitor the signal you don't need to change the function mapping. I haven't had to use it much, but I believe that is just for changing what signals get activated when certain system events happen. The SC_Feedback_Dev is just the generic device that is used. From the screenshot, "InClampframe" will be logical 1 while outside the zone, and logical 0 while inside it (safety signals are inverted).

For your permission issue, it depends. If there are no other users on the system, you can log into the controller as the default user and it will have all permissions necessary to edit SafeMove properties. If someone else has gone in and added specific users, you will need to view the user grants, see which one can edit SafeMove, obtain the password for that user and then log in to the controller.

With SafeMove2, a zone by itself does not restrict any movement. You need to add a supervision to the zone. In the supervision settings, you have the option to set the activation signal, the function active signal, and violation signal.

Do you need the orient, confdata, or extjoint data? If you only need your XYZ, CPos will be the easiest to work with. To access individual parts of a record, use dot-point separation. It would look something like this:

VAR pos psCurrentPos;
VAR num nXOnly;

psCurrentPos:=CPos(\Tool:=tGripper \WObj:=wobjTable);
nXOnly:=psCurrentPos.X;

Rapid has 3 "atomic" data types: bool, num, and string. Every other data type is called a record type, and is made up of the 3 atomic types. In the "RAPID Instructions, Functions and Data types" reference manual, you can look up each data type structure to get the atomic data you need.

There is a dropdown arrow in the title bar. Click it, select Windows at the bottom, and make sure the Visual SafeMove Properties option is checked.

Did you try to measure the speed to see if it did in fact slow down?

Basically, VelSet reduces the maximum program speed. Even though the robot will be moving slower, this is the new 100% speed, hence the pendant still showing that.

SpeedRefresh on the other hand does update the override speed that is displayed on the pendant, noted by the fact that this will "update speed override for ongoing movement".

Just to verify, this is on IRC5? If you created the RobotStudio station from a backup of your real controller, you will see your code in the RAPID tab just as you would with a real controller. In the Controller tab, you have the ability to use a virtual FlexPendant which can be used to get your trainees familiar with the menus and such, and it will also let you modify a position using the modify position button in the program editor.

You need a virtual controller in order to execute a move along path or synchronize to RAPID, if that is what you were trying to do.

Don't forget about the built-in help documents, they are good resources. You can find them by clicking the "?" button towards the top-right corner.