Posts by TylerRobertson

hey Andrew,

Just in addition to the manual of things that are a bit different when compared to FANUC

- the work object has two frames, the object frame, and the user frame. Because I first learned on FANUC, I just use the 'user frame' whenever I can and I keep the object frame undefined. The object frame would be a frame shifted from the user frame.. a frame on a frame if you will; the object frame helps if you have a frame on a table and then another frame on a fixture or multiple fixtures.

- the 4 points are X1, X2, y1 and Y2 ... you're basically setting the four points on two lines. it's a little odd feeling when you're used to setting an Origin, then X1, Y1
- The workobject is only active if it's called out in the move. you can name the work objects whatever you want. wobj0 is the robot base, or generally set to the same as your 'world' (not always).

MoveAbsJ start, v2000, z40, grip3; <- no work object

ie: MoveL start, v2000, z40, grip3 \WObj:= wobj1; <-work object

- You can have multiple work objects in a program and the definitions are all usually at the top of a program if you look at it in a text file (also ABB lets you save and load .PRG files easily from and to the controller and view them in text.). You can download Robotstudio and use the text editor for free. (it will highlight and check syntax)

- work objects that you want stored across programs (ie: the same frame in all programs, and if you update it, it will be referenced by all programs) should be stored in a system file

Very sorry - my e-mail started blocking forum notifications. That answer given was along the same lines I would have suggested.

Alternatively if it's easier to follow you can simply create a new workobject and call it STAGE1STN2; If you don't DEFINE the work object, it should look like this in text:

PERS wobjdata STAGE1STN2:=[FALSE,TRUE,"",[[0,0,0],[1,0,0,0]],[[0,0,0],[1,0,0,0]]];

Where

PERS wobjdata STAGE1STN2:=[FALSE,TRUE,"",[[0,0,0],[1,0,0,0]],[[0,0,0],[1,0,0,0]]];

The red values are your userframe XYZ and you can put values in there to do a linear shift in either direction

the blue values are your angles, but it's represented by a quaternion and this is harder to just measure and type in. If you need to also shift the angle, it's often easier to teach this with the 3 point define .... or if you're feeling handy, you can use a Quaternion calculator but you have to make sure it's using the correct rotation order (many on the internet do not present results in a useful ABB format even if they specify RzRyRx)

Which vision system? Set up a separate PROC in your RAPID program - your vision system should have a way to override signals so you can test values are true/false etc. If not (for some reason) make a new job in your vision system that is literally black/white. When I start up I just print a black circle on piece of paper and set up a job for pass/fail to get my communication and everything in order then I write my 'real' operation

I haven't tried this out in production so test at own risk but I believe you just have to specify name of the unit and define the axis, so you would have to set up 6 TestSignDefine for each axis

In the manual replace the mechanical unit name with the robot unit to get the joint reference - it'll most likely be ROB_1 unless it's been re-named.

I use this reference for resetting axis values like a rotary mechanical unit ie:

IndReset ROB_1,6\RefNum:=0\Short;

Quote from Tyler Robertson

Pretty sure you have to do an X start? At least I. Older ones anyway - check the manual for the key sequence.
I think it's go to restart and press 125 I don't have it in front of me. Do a backup before hand

Woof - not sure what I was doing on the weekend.

Here's my notes from the last time I did this:

On IRC5:
Service->Restart->Advanced->X-Start.
Wait the boot, then enter LAN Settings, etc.

On the S4C+:
Select Other Windows->Service->Restart, then before pressing OK, type 159 on the numeric pad. An "X-Start" option will appear where before was "OK".
Enter Lan-Settings, and input your data (IP address, mask, etc). Put the same address both in IP field and Gateway field.
Another warm-start will be requested. Perform it.
In the next session, you will have to select the system to boot (usually there's only one system, just select it and press OK).
At the end of the boot the procedure is finished and you can try connect through the LAN.
For what I know, no additional option is needed on S4C+ to connect on the 100Mbit port.

The points you taught are probablynin the world coordinate system so you're going to want to add an empty workobject to your points. Do this in the text editor of Robotstudio is the easiest/error free way of doing it.
If you post your code I can help.
From there we can infer a workobject origin or just add the ~37" shift into each of them.

I do this exact thing on multiple robots using the same programs for multiple tables and fixtures, it's exactly what workobjects are for like mentioned previously

Read up on them in the manuals for a primer on functionality

Pretty sure you have to do an X start? At least I. Older ones anyway - check the manual for the key sequence.
I think it's go to restart and press 125 I don't have it in front of me. Do a backup before hand

Just a heads up that I went to switch over two older robots to DHCP to save myself a couple trips in the future, and on each one I have had "Startup in Progress" boot fail. In the S4C+ it recovered after a power down, wait, power up .. but the other one I'm stuck rebuilding.

In the first case I went
> Service
> X-start
> Network Settings
> LAN Settings
> DHCP
> Do you want to restart? Yes
> stuck in "Startup in Progress"

I thought that there might have been no system selected so in the next case:

> Service
> X-start
> Network Settings
> LAN Settings
> DHCP
> Do you want to restart? NO
> Select System
> (Selected system)
> Do you want to restart? YES
> stuck in "Startup in Progress"

I've changed IP addresses many types and never had an issue booting up afterwards, so this seems related to DHCP settings. Still trying to get the other robot to boot up but I have a detailed list of things to do from ABB so I hope to be okay, just wanted to save other people the headache.

This is a great forum

Ah geez, I've been avoiding cutting things with robots as of late for these reasons entirely.
I'm with TygerDawg & SkyeFire as I believe we have all suffered similarly at some point or another. Cutting small circles with a 6-axis robot is not trivial and there's a limit to at which point the machine shines more for rough-cuts.

The circles drawn earlier in this thread show exactly the points where a joint is changing direction and either show backlash or 'floating' as one joint doesn't move as much as others.

Some things to try at first blush which have already been mentioned

- Smaller robots do better to cut smaller holes (ignoring cutting forces and just considering geometry)
- Make sure your tool mass load settings are accurately set! this makes a huge difference as the robot will be attempting to compensate for this. Cutting forces withstanding.
- cut slower, reduce acceleration and deceleration (VEl.CP, ACC.CP)
- linearize circle movements and try very small increments of linearization (small chordal deviation) ie: More points = Better, but motion 'smoothness' can be affected as the speed goes up
- Cut on a different plane to use more of one axis vs. another (ie: Axis 1 doing most of the 'circular' path will be the least accurate)
- C_VEL & C_DIS make a huge difference in how points are processed, try values for those but my starting point for C_DIS was 01.mm-1mm.
-

- you CAN pre-load axis 1 by mounting the robot on an angle and this can have desirable effects on one side of the cutting area, but the effect isn't a magic button and now you have to calibrate your work objects with this angle in mind (buy a decent digital protractor/level before you even start)

sudeep, a KR120 is a big robot, and not having HA calibration on it puts you at a bit of a disadvantage (assuming it's not HA). I understand the frustration - what kind of deflection from change of direction are we talking about? There is a ceiling with what robots can do - are you programming manually or from CAD/CAM? CAD/CAM can give you some more options to play with in how it generates the points.

I want to make this one work for you

Just a note, ACC Can go up to 150

+1 to the 'circle' of orientation changing on a square. I had to do this on some weird welds and that was NOT fun given how the welds would change.

Is your robot "technically" holding your work object, or your tool? It would require reprogramming all of the points (or doing some friday afternoon math) but this might help out quite a bit.

Since the dispensing system is your tool, and the robot your part you will want it calculating TCP speed and orientation from the dispensing nozzle, not the robot end. I'm 90% sure this would eliminate the stuttering issue and it will also make maintaining your process speeds and increasing them in the future.. MUCH easier.
So small pain right now for gain in the future.

I'm in the middle of reprogramming 10 years of buffing for this very reason.

going from offline to finished welds without a dry run was one of my most satisfying, and technically satisfying jobs ... although at the time I hated it.

I'm having to go backwards from the IRC5 to the S4, and I would say depending on the cost, and how much you're paying those 4 guys, the time it would take them to go backwards and get used to the S4 is starting to get to the point of justification. It would take them a couple days each to get comfortable, and I've found myself making errors I wouldn't normally on the IRC5.
The S4 layout/OS just makes no sense after you get used to the IRC5 - it's just faster with regards to switching between jogging etc.
Menus are easier to understand, it's easier to teach new people, etc.

how do you get programs on/off the controller or do work, take backups etc. if they aren't networked, then

- USB vs. floppy
- controller speed: navigating programs, files etc. is just that much faster on the irc5
- programming language functions: look at the functions in the RAPID 4.0 manual and then look at the functions for IRC5, would you potentially make use of any of those functions?
- does the S4 still comply with the robotic safety standards in your area?

You may want to use a regular IO trigger to fire after the robot executes a move so it's up to speed. You also may see some velocity change when the robot changes directions but it could be minimal depending on the speeds you're running at. In any case make sure you're using a large enough zone value

Anyone know how to refer to a module or PRG's name programatically?

ie: I want to output the PRG/module therein name in a log file but call the same program from different PRG files and not have to edit each time

Low brow solution, I just started writing the time into a data file and then I read the last stored time in there and take the difference. It's working now, but I want to display my seconds as minutes and I wish RAPID had a modulus% that I knew about..

edit: and there is, lets see if MOD does the trick

edit edit: Great it did, just had to remember it only does rounded integers

morning,

Been awhile since I used the S4c+ platform, and I'm trying to record robot idle time. Right now, all production programs are stored as separate PRG files (>30 in total) and they're all qualified so I don't want to try moving them all into modules.. as I know if they were modules I could just make a persistent and be done with it - I'm just trying to check a varaible, and then update it's time so I can record the robot down time. I have all the clock stuff working and I'm writing to a log fine. I'm sure this is something simple I'm missing

Thanks!

Are you using a work object

Quote from eureka

probably your base frame information is not correct in robotstudio. Right click on your system controller and then click edit system and come to robot base frame. There is a options on the page which name is "use current station values" then click ok and restart the system

careful, you probably don't want to be changing the robot base frame if just the program is off as potentially it is just the work object that is not calibrated correctly.

If you change values in your work object you can use the data to shift your whole program - but what Joan Murt said is correct in that you may not ever achieve the offline to online accuracy you want without touching up programs