Posts by bull_boxer454

Worked on a program where an engineer set up recursive calling of main in an error handler of an IRC5 controller. It worked initially, but after around a dozen uses it would have an overflow error that just needed pptomain to be performed manually to clear. Solved this problem by using the ExitCycle command in the error handler instead. I wonder if the amount of commands in the program has a large effect on the number of times it can recursively call?

Look up Velset.

It will be something like velset 50,3000;

The first number is the percentage of programmed speed it will run, the second is the maximum speed. Make sure to have a command to turn it back to 100% when you're finished or the robot will continue to run at 50% speed.

The CamGetLoadedJob function can leave the .job suffix in the string it returns. This will make the <> comparison not match. For example, the string "camjob" does not match a string of "camjob.job". For testing, you can use a TPWrite instruction to show each of the two variables before during testing and make sure the strings are in the same format.

H.CHOI Attached is a quick powerpoint. Sorry for taking a few days on making it. Hope this can help you out. Switching up the vision to run with a single job will make you need change the routines that get data from the camera. Takes a little bit of work and is confusing at first, but it is a lot faster.

I'll make up a document and post it here in case it can help others. It may take me a day or so to get it made up. Things are pretty busy for me today.

If the each of the three inspections has a similar camera setup and takes the picture of the part at the exact same distance from the camera, you can run a single job with multiple tools. With one job, there is never a need to load every cycle, only in special scenarios. This is possible, but difficult and not well documented. If you are interested in trying this route, I can give some pointers but it will be lengthy.

Another option like ColoradoTaco mentioned is to load the job early. If you have the multitasking option, you can load the camera job in a second task while your robot is doing something else

Is the CamLoadJob command being executed before each inspection? Are all three inspections under different jobs?

If so, you can compile all of it into a single job that has multiple tools. Connect each tool to a variable and set the variable to the same number of the tool you need to use before each inspection. Create a different Output To RAPID part for each tool. Use a for loop with the GetCamResult instruction to get all results. It is more tedious to set up, but is much quicker than loading a job between each inspection. There is not any documentation that I am aware of that tells you how to do this, I had a teams call with a local ABB group and they helped me get started.

If you have a licensed version of robotstudio you may be able to get creative with the Jobs function. You can save the logs, or search for certain error types. Jobs can be called through command prompt, then scheduled in task scheduler to automate. Details on how to do this procedure is in the robotstudio manual.

Do you have the PC Interface option on the robot? This is needed to connect via robotstudio. If you are trying to put the robot on a network, the WAN port is the best option. Do you have the port configured?

If you want to test if you can connect locally, use the service port and make sure your PC's ethernet adapter for the port you are using is on the 192.168.125.XXX subnet on something besides .001 then click one click connect for an easy connection

I have used Phoenix Contact FL WLAN, don't remember the exact model number. It worked well with no noticeable lag. The main downfall was our IT team constantly taking over our channels for their wireless networks and causing interference, leading to communication drops. Also it had to be kept in line of sight for optimal performance. If you have a good mounting location and can keep it isolated on its own band, they work great.

If you have a compatible disk, you can go into the system builder of Robotstudio and select recovery disk. From here you can select a backup and save it's system to the SD card. You must have both disks on the card already for this to work

In the IRC5 controllers, you can use the file transfer in Robotstudio and navigate here: 'YourRobot'/hd0a/RobotSerial/PRODUCTS/RobotWare_6.04.0140/utility/service/EDS

There will be options with a few different protocols

Thanks Lemster68! This has shown me what I need to do

Hello,

I am looking to make a routine using RAPID programming to modify the TCP of the robot relative to a known point. The robot is an ABB with an IRC5 controller

We use a stationary pointer to verify the TCP of one of our robot tools. Occasionally after maintenance is done to the tool, the tip is off by a couple millimeters. If the tip is not aligned with the pointer, I would like to jog the robot to realign it, then run a TCP update routine to modify the tooldata so that it aligns with the pointer without changing the original robtarget.

I am using the CRobT function with a variable robtarget to get the new robot position and subtracting the pos data from the original point to get the difference. To get the orient data, I am converting to Euler angles and doing the subtraction, then converting back to quaternion. I am having an issue when it comes to modifying the data of the tool. The data in the robtargets are relative to the work object. Is there a way that the calculated difference can be aligned robot tool? Or a way to align the tooldata and wobjdata? I have tried using PoseMult, but didn't get the results that I am looking for. PoseMult is a new function for me, so I may not have been using it correctly

Here is my code for a better description:

!Tip position. Made with tool0 and wObj0 for calculation purposes

MoveJ pTCPcheck10, v50, fine, tool0\WObj:=wobj0;

!This is a separate routine. The above is to show the point for calculation

PROC rUpdateTCP()

CalculationPoint:=CRobT(\Tool:=tool0,\WObj:=wobj0);

!Convert from quaternions to Euler angles

Check_Anglex:=EulerZYX(\X,pTCPcheck10.rot);

Check_Angley:=EulerZYX(\Y,pTCPcheck10.rot);

Check_Anglez:=EulerZYX(\Z,pTCPcheck10.rot);

Calc_Anglex:=EulerZYX(\X,CalculationPoint.rot);

Calc_Angley:=EulerZYX(\Y,CalculationPoint.rot);

Calc_Anglez:=EulerZYX(\Z,CalculationPoint.rot);

!Calculate Angle Difference

AngleDifferencex:=Calc_Anglex-Check_Anglex;

AngleDifferencey:=Calc_Angley-Check_Angley;

AngleDifferencez:=Calc_Anglez-Check_Anglez;

!Calculate position difference

Xdiff:=CalculationPoint.trans.x-pTCPcheck10.trans.x;

Ydiff:=CalculationPoint.trans.y-pTCPcheck10.trans.y;

Zdiff:=CalculationPoint.trans.z-pTCPcheck10.trans.z;

!Calculate Tool Euler Angles

ToolAnglex:=EulerZYX(\X,tMyTool.tframe.rot);

ToolAngley:=EulerZYX(\Y,tMyTool.tframe.rot);

ToolAnglez:=EulerZYX(\Z,tMyTool.tframe.rot);

!Apply angle difference to the tool

UpdatedToolAnglex:=ToolAnglex-AngleDifferencex;

UpdatedToolAngley:=ToolAngley-AngleDifferencey;

UpdatedToolAnglez:=ToolAnglez-AngleDifferencez;

!Make pose out of the difference for frame manipulation

pose_FrameDifference.trans.x:=XDiff;

pose_FrameDifference.trans.y:=YDiff;

pose_FrameDifference.trans.z:=ZDiff;

pose_FrameDifference.rot:=OrientZYX(AngleDifferencez,AngleDifferencey,AngleDifferencex);

!attempted, but did not work

!tMyToolUpdated.tframe:=PoseMult(tMyTool.tframe,pose_FrameDifference);

!Convert Euler angles to quaternions and change the data in the updated tool

tMyToolUpdated.tframe.rot:=OrientZYX(UpdatedToolAnglez,UpdatedToolAngley,UpdatedToolAnglex);

tMyToolUpdated.tframe.trans:=tMyTool.tframe.trans+pose_FrameDifference.trans;

!Copy the load data of the tool

tMyToolUpdated.tload:=tMyTool.tload;

ENDPROC