Posts by gmumaugh

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.

If you right-click the action instruction there is a delete option. You can also use the Delete key on your keyboard.

In the Home tab of RobotStudio, you should have a Paths&Targets tab of your cell browser. You should find both the Bottom_Left_above robtarget and the Bottom_Move_to_Right path. You can drag the target onto the path and it will create a move instruction using the data along the bottom of the RobotStudio window.

Hey all,

From time to time there are threads posted about a system called IFWC in ABB robots at Ford facilities. Here is the application manual for it, it has some good information. Past this, you will have to take the training offered by ABB.

Fun fact, Ford Fanuc robots also use IFWC.

ContinuePathSeg is what you would want. Define a path segment for each position, and when in position use ContinuePathSeg and use the correct path segment in the argument. This will set goR1_PathSeg and your PLC can determine what you do next by returning a decision code.

I have the application manual for IFWC, if I'm allowed I can post it. It does a decent job of explaining what each part of IFWC does and how to use it.

Does it succeed if you try to run the check manually from the SafeMove Visualizer? You can also look at CBC_REPORT.log, it's saved in the HOME directory. Maybe it has more information than the event log.

Given that the error has CBC in the title, I'm assuming they are calling CyclicBrakeCheck now instead of BrakeCheck. However, maybe the brake check routine has an error handler that catches any error and spits out that message, which could be why it looks like it was written by ErrWrite.

IFWC doesn't have any instructions related to the brake check, at least the version I have: 6.08.0134.

Disabling SafeMove assistance will stop the 50511 error. It's under Configuration - Topic Motion - Motion System - system_1 - Disable SafeMove assistance.

I ran into a similar issue a few months ago. On controllers with RW6.14 and newer, this feature is disabled in manual mode, but for 6.13 and older it must be disabled manually.

Since RobotWare 6.12, RAPID execution operates at 44 steps per millisecond, per the release notes. I'm not sure if steps = instructions, but that doesn't seem too unreasonable. From what I have seen, the program pointer and motion pointer remain on the same motion instruction until the TCP reaches a position, based on the prefetch time, that allows the program pointer to start reading ahead. If the program pointer doesn't reach another motion instruction in time, the TCP doesn't know which direction to exit the corner zone, and that's where corner path failures come from.

For the original question, coordinating motion and logic instructions can be done by using interrupts and triggers. This is the best way to do it because you can still use fly-by points while also having precise control over when I/O based events happen.

For example, on a project I am currently working on, the robot gripper has 3 additional axes that are completely independent from the robot. When I drop parts off, we needed a way to tell those axes to stop moving before the robot reached its final position, so I implemented this:

TriggIO ChainEngaged,10\DOp:=oAtChainEngagePos,1;
MoveL RelTool(p52DropOP154_1,70,0,0),v50,z20,toolhand1\WObj:=wobj2;
TriggL p52DropOP154_1,v50,ChainEngaged,fine,toolhand1\WObj:=wobj2;

This sets a digital output when the TCP is 10mm away from reaching the fine point. Technically, according to the manual, distance-based triggers are used for fly-by points, but this still works.

Check out the manual RAPID Overview (IRC5) - Motion and I/O programming - Synchronization with logical instructions. It gives a lot of good information with visual examples that describe exactly when various events happen with relation to positioning.