Posts by inusO

Just as I thought you have Joint Instructions

4:J P[1] 100% CNT80 Offset    ;

I guess that's why when you teach the point it is saved automatically as Joint Representation

I am not sure to fully understand what you mean, but I believe it depends on the type of instruction you are teaching

Actually I didn't know about Markers and it could be a great workaround if you have few conditions that needs to be scanned many times;
sadly I need a more general method since I have a lot (and variable number) of WAIT FOR, that would mean I need to define an 'initializing' TP program for all those conditions.
Thanks anyway, appreciated!

P.S. I ended up using the brutal REPEAT UNTIL loop with a couple of functions to wrap the TIMER instructions

I have no issues when trying to WAIT FOR a simple condition like a single AND or OR, the issue arise when I try to mix ANDs and ORs

Seems like you are talking about a TP program that uses the RUN instruction, as far as I know the only way to continue a paused task in background is using the Karel instruction CONT_TASK.
I did this within Karel programs and I am not sure it will work on task launched from a TP program

I am trying to create a more robust WAIT FOR in a KAREL program by implementing a simple timeout condition;

let's suppose my old code was

WAIT FOR condition

where condition usually is a simple boolean expression (e.g. DIN[1] AND DIN[2])

What I want to do is

WAIT FOR condition OR timeout_expired

problem is the compiler doesn't like when you put mixed AND or OR in the same expression and gives me this error

Quote

"AND" and "OR" cannot both be specified in a condition.

Has anyone encountered this issue? How do you solve it in an elegant way that doesn't involve a brutal 'put the condition test inside a REPEAT UNTIL loop' ?

I believe you miss the directive to access System Variables in the program that doesn't compile, try adding

%ENVIRONMENT sysdef

on top of that program

I sometimes experienced TP freezing due to cpu overload by some cyclic KAREL program, solved by delaying it to let the cpu breathe.

I probably misunderstood what you meant; sadly when we pack up the TPP program (by setting proper PRs) the information we have is points in cartesian space and not joints, computing joints would mean a big change in our software, but I guess I'll give it a try.

Quote from Fabian Munoz

Hi
Is this a brand new program, was PR[26] working before ?
Could you post the values (all of them, x,y, config, etc) of point 25,26 and 27 ? Three pictures will be ideal

The program is not new and we used it a lot of times without having issues like this; in fact, the 'sequence' we are running launches this program multiple times (~ 10 times)
I cannot give the pictures right now or exact points because I am not anywhere near the plant, but the situation is:
point 25 -> same as 26 but with CNT100
point 26 -> L PR[26] FINE
point 27 -> moves with a linear motion in FINE along Ztool of 50mm
point 28 -> get back to point 26 with a LIN and CNT100

You can imagine the program performing a finger touch

Quote from Nation

Also converting the problem point to a joint representation may solve the issue. That way the robot doesn't have to call up the IK solver and have it spit out the position unreachable alarm.

We tried that and it doesn't pop up the alarm, but we need to perform this motion in LIN and with FINE since the tool is really close to the product and we must avoid damage to boht the tool and the product.

Quote from Nation

Is the position a PR?

Yes, the position is a PR

Quote from Nation

Could the wrong frame be active when you attempt the move?

I don't think so, since the frame is assigned by the TPP when it starts

This is pretty much the code of the TPP when the alarm pops up
MOTN-018 Position not reachable at Line 11
...11: L @PR[26] FINE...12: L PR[27] FINE...
Another strange thing is the '@' at line 11, suggesting that the motion to PR[26] has completed

It is not moving through singularity of the wrist and the wrist center is far from axis of joint 1 (this is a common case described in the Alarm Codes manual I have).
As for what concern the base of the robot I am not sure to fully understand what you mean.

Hello everybody,

I am pretty new to Industrial Robots (6 months working in this field) and I am currently working on a Robotic Milling plant for Foundry with a Fanuc M900iB400L.
We build complex processes by using small TPP as building blocks and combining them with KAREL programs; we got this problem where, in automatic mode, one of those TPP stops and gives error MOTN-018 Position not reachable.

We checked most common causes like changes in configuration or outside of robot envelope, but everything seems ok.
When we try to reach the same point in manual (starting in the same settings) the robot moves normally to the point and gives no alarm.
The same happens if we try to execute the same TPP in automatic mode but with reduced override speed.

Anyone has any idea?
Thanks in advance!