Posts by WattUp

If you want to move up 300mm every time, just use an IMOV with a PVAR set to Z 300.
If you want to move up to a set height every time no matter where you are, you will need to read current position to a PVAR, edit Z to equal the new height, then move to that PVAR.

Do both those robots have the same tooling?
You could pull the TCP data from one to the other, and it should be close enough.

Two axis moving very fast i.e. spinning to realign, is probably a singularity or pose issue. you might be able to adjust the taught positions as a joint level to correct for that.

I see why world / base would be hard to work with.

Your EOAT looks to just be a straight tooling of some sort, why is that difficult to setup as a TCP?
Why not just make a User Frame of the work area?

We use macro to actuate a tool a distance set by argument, and they do fire as one instruction while teaching / going through the job step by step.

Maybe MACRO? I think that is a purchased option though.

Exactly. I typically create a 'auto recovery' job that can IMOV safely away from dangers then go home.

I never new work home position could be triggered like that. But I use them on every robot for home confirmation outputs

I have run into that problem before with Pvar that are saved in tool / robot coordinates only care about the TCP position, and the R joint was 180* out.

By saving the PVAR as pulse positions that was corrected.

I have never tried to take PVAR and separate them out to standard moves in bulk, but i would try to edit a JBI file with like 5 moves and see how well that works.

You say they made it work but now it doesn't. Two thoughts come to mind first.

1) Are you sure that they were doing it safely ? Wouldn't be unheard of for someone to bypass safety
2) are you following the correct procedure? I imagine there is some trap key, request for entry, or other means of controlled access.

You can create a destack program by setting a Global Integer with the number removed

then set that # x thickness and set an PVAR with that offset , increment the integer then shift on that PVAR

What exactly are you trying to set up? OSSD outputs to the YRC?

And take a CMOs backup of any other robot you have to save that headache in the future.

I am planning to add a conveyor tracking to an existing chain drive conveyor, does anyone have recommendation of a brand / type to use?

I know exact part number will need info on the mounting shaft and such, but I figure there was some feedback to help narrow down to field

If your P-var is taught as a TOOL Coord, all it cares about is the TCP is in location, the other joints don't matter. If you set it as PULSE, then every joint will be exactly in position.

Q4 If you want to restrict the movement for safety use the FSU menu safety range limits

80-90% of all my robots are programed with standard (insert+enter) move types.

We use PVAR on model specific positions where a common job is running for every model, but some positions are exclusive and we call a PVAR with a integer pointer.

p in mind that if distance between points is close, then the robot may not even be getting to top speed.

There is a option on the pendant called TRT that lets you set a target cycle time for a series of moves.
For example, If i select this group of moves:

Select TRT from the EDIT menu

It will show the current cycle time of those moves, You can enter a target time for those moves, and the speeds will update to try to reach that target time.

I use the timer just to slow the scan down as it loops. The software does not (at least older ones didnt) like scanning through loops at full speed.

LABEL 1

IF COND

JUMP LABEL 2

ELSE

Timer 0.1s

JUMP LABEL 1

I commonly use the IF and label jump method; but make sure you add a timer in that loop. It gets angry otherwise

You could maybe do a JUMP *Label IF IG#1 = #, if your inputs are on the same input grouping.

Setup a posvar with tool coordinates, and set X to 127.00 (5in in metric )

SFTON P00x

MOVL

AFCON

MOVL

AFCOFF
SFTOFF