That sounds horrible. It should be a lot easier that that. You should be able to do tracking and teaching of a tracking path in roboguide's not sim mode. I've done dozens of tracking simulations, and never had to resort to that.
If you package up the cell, I can take a look at it and see if there is something messed up with it.
HI Nation,
Do you have a code example for this?
regard Bjarke
Sure. UTOOL1 is the master tool, and UTOOL2 is the shifted tool, from master.
UFRAME5 is a frame taught in the center of the switch.
The speed you do the search at will impact how accurate the shifted tool is.
The code is slightly different than what I described, as it does 5 searchs, as in roboguide the collision input tends to fliker. Got around it by searching for rising edges only.
Code:
/PROG TCP_SET
/ATTR
OWNER = MNEDITOR;
COMMENT = "";
PROG_SIZE = 1430;
CREATE = DATE 22-12-15 TIME 11:09:40;
MODIFIED = DATE 22-12-15 TIME 11:09:40;
FILE_NAME = ;
VERSION = 0;
LINE_COUNT = 30;
MEMORY_SIZE = 1814;
PROTECT = READ_WRITE;
TCD: STACK_SIZE = 0,
TASK_PRIORITY = 50,
TIME_SLICE = 0,
BUSY_LAMP_OFF = 0,
ABORT_REQUEST = 0,
PAUSE_REQUEST = 0;
DEFAULT_GROUP = 1,*,*,*,*;
CONTROL_CODE = 00000000 00000000;
/APPL
/MN
1: UFRAME_NUM=5 ;
2: UTOOL_NUM=1 ;
3:J P[1] 10% FINE ;
4: !Laser Switch. Normally off if no ;
5: SKIP CONDITION DI[10]=ON ;
6: !X direction search ;
7:L P[2] 5mm/sec FINE Skip,LBL[100],PR[20]=LPOS ;
8:L P[2] 100mm/sec FINE ;
9: !Other side of tool, in X ;
10:L P[1] 5mm/sec FINE Skip,LBL[100],PR[21]=LPOS ;
11:L P[1] 100mm/sec FINE ;
12:J P[3] 10% FINE ;
13: !Y direction search ;
14:L P[4] 5mm/sec FINE Skip,LBL[100],PR[22]=LPOS ;
15:L P[4] 100mm/sec FINE ;
16: !Other side of tool, in Y ;
17:L P[3] 5mm/sec FINE Skip,LBL[100],PR[23]=LPOS ;
18: !Calculate the delta from the mas ;
19: R[20:Tool X Shift]=((PR[21,2]+PR[20,2])/2) ;
20: R[21:Tool Y Shift]=((PR[23,2]+PR[22,2])/2) ;
21: PR[25]=UTOOL[1:Master TCP] ;
22: PR[25,1]=(PR[25,1]-R[20:Tool X Shift]) ;
23: PR[25,2]=(PR[25,2]-R[21:Tool Y Shift]) ;
24: UTOOL[2:Shifted TCP]=PR[25] ;
25: UTOOL_NUM=2 ;
26:L P[5] 100mm/sec FINE ;
27: !Do Z search in the shifted TCP. ;
28:L P[6] 2mm/sec FINE Skip,LBL[100],PR[24]=LPOS ;
29: PR[25,3]=(PR[25,3]+PR[24,3]) ;
30: UTOOL[2:Shifted TCP]=PR[25] ;
/POS
P[1]{
GP1:
UF : 5, UT : 1, CONFIG : 'L, 0, 0, 0',
X = 0.000 mm, Y = -10.000 mm, Z = -15.000 mm,
W = 180.000 deg, P = 0.000 deg, R = 90.000 deg
};
P[2]{
GP1:
UF : 5, UT : 1, CONFIG : 'L, 0, 0, 0',
X = 0.000 mm, Y = 10.000 mm, Z = -15.000 mm,
W = 180.000 deg, P = 0.000 deg, R = 90.000 deg
};
P[3]{
GP1:
UF : 5, UT : 1, CONFIG : 'L, 0, 0, 1',
X = 0.000 mm, Y = -10.000 mm, Z = -15.000 mm,
W = 180.000 deg, P = 0.000 deg, R = 180.000 deg
};
P[4]{
GP1:
UF : 5, UT : 1, CONFIG : 'L, 0, 0, 0',
X = 0.000 mm, Y = 10.000 mm, Z = -15.000 mm,
W = 180.000 deg, P = 0.000 deg, R = -180.000 deg
};
P[5]{
GP1:
UF : 5, UT : 2, CONFIG : 'L, 0, 0, 1',
X = 0.000 mm, Y = 0.000 mm, Z = 10.000 mm,
W = 180.000 deg, P = 0.000 deg, R = -180.000 deg
};
P[6]{
GP1:
UF : 5, UT : 2, CONFIG : 'L, 0, 0, 1',
X = 0.000 mm, Y = 0.000 mm, Z = -15.000 mm,
W = 180.000 deg, P = 0.000 deg, R = -180.000 deg
};
/ENDAnimation of it working:
If you don't want to spend the money on Leoni's solution, you can do this with a through beam sensor, and 3 search moves. I did this 6 years ago. Turned out to be very repeatable, and it has been running production since then.
What you would do is set a frame to the laser, then search for the rising and falling edges while moving through the beam in X, Y, and then just the rising edge for the Z search. I would then take a 'master' TCP, and then shift it by the found deltas.
Does your STOP program have a motion group assigned to it? There should be an additional error detailing why it failed in the alarm log.
I used visual studio 2019 community edition, and just wrote everything in C#.
I used roboguide to verify the results, and to generate the test programs.
That is a call from a teach pendant program to a compiled Karel program. While you can call other Karel programs from Karel, I don't think that is the intention here.
EXT_LOAD isn't a karel built in. I would use LOAD. Also, you will need the file extension if you want to load something ('MC:\list.tp' for example).
Its my business laptop, I take it with me when I leave. The debug information is only really needed for when I run some conversion utilities I wrote.
I'll just reboot the controllers to reset the AUX count, and be more cognizant of disconnecting properly when I leave.
Damn. Really just my personal connection. I mainly use it for printing debugging information.
The fact I am just shutting my computer lid and leaving for the day without properly disconnecting is probably causing the AUX increments.
Like the title says. Is there a way in AS to determine which AUX ports are currently connected to a krterm instance? I want to print exclusively to krterm, but it seems random on which AUX port I get connected to.
Here is my configuration for connecting to the first simulated robot in roboguide:
<?xml version="1.0" encoding="UTF-8"?>
<FileZilla3 version="3.48.1" platform="windows">
<Servers>
<Server>
<Host>localhost</Host>
<Port>21</Port>
<Protocol>0</Protocol>
<Type>0</Type>
<Logontype>0</Logontype>
<PasvMode>MODE_DEFAULT</PasvMode>
<EncodingType>Auto</EncodingType>
<BypassProxy>0</BypassProxy>
<Name>Fanuc Simulation Robot 1</Name>
<Colour>7</Colour>
<RemoteDir>8 0 3 md:</RemoteDir>
<SyncBrowsing>0</SyncBrowsing>
<DirectoryComparison>0</DirectoryComparison>
</Server>
</Servers>
</FileZilla3>I'm not in control of the touch up of the path, so when the people responsible for the the touchup finish, I want to verify if my chosen CVWAIT positions are still valid.
Also, the robot is overloaded in terms of its path. I need every mm of upstream real estate I can grab in order to not fall behind.
In addition to all that, the entire path is shifted by a vision system. One point that may be reachable at a certain conveyor position may be reachable in one offset, and not another.
Since I got it working I was able to make a graph of the upstream reachability of one of the paths:
I got it to work.
Inrange does function as a reachability test, but with how Kawasakis do their line tracking point teaching, it is pretty counter intuitive. From my testing, INRANGE checks reachability of the XYZOAT position of the pose, and then just checks to see if the ext axis is within the motion limits.
Since how I was originally using INRANGE was effectively testing taught points, so of course every point was reachable. The key is to shift the XYZOAT of the along the conveyor tracking vector by the delta of where the point was taught, and where the conveyor currently is, then run the inrange test.
What is it you are actually looking at being reachable and at what point in the process?
When you start tracking, at what point are you looking whether it is reachable or not?
It all depends on how fast the algorithm for reachability checks ends up being. Ideally I would like do to the check repeatably while the conveyor is moving before moving to a point, and then releasing the robot to move when the point becomes reachable. Maybe with some padding so the robot doesn't get into an elbow lock position.
If I can't do it real time, I would like to develop an offline check that would output a range on conveyor for when a specific point is reachable.
Is this for outside of the robot envelope (error), or within a certain zone to cancel the tracking of it?
For outside of robot envelope.
Have you looked at CVPOS command?
Yes, I will need to use that command to pull out the current conveyor value for in range testing.
Have you looked at ULIMIT and LLIMIT commands?
Haven't looked at these, but after looking at them in the AS manual, I'm not sure they will help that much. I'd like to keep the joint limits of the robots as open as possible.
Have you looked at DISTANCE and DEST commands?
DISTANCE will be used if I have to go with the IK solver idea. I don't plan on using DEST as I only want to do the check before moving to the next point.
Maybe I can use distance to check the current position vs where the next point is. I would like to check orientation though.
Anyone have any advice testing to see if a point is reachable? I want to test to see if a point is reachable before attempting to run to it.
The kicker is that this is on a line tracking cell. The INRANGE function seems to not work on this type of robot, and after discussing with Kawi tech support, it only checks if the passed in point is within joint bounds, and not if it is reachable or not. It was returning a 64 everytime, but once I opened up the bounds on J7 (the conv tracking axis), it just returned 0 for every point tested, even for points obviously unreachable.
My next attempt was to attempt to convert a pose to joint, and use the error catch of ONE if the conversion failed. Either I didn't setup right, as the controller faults the moment I attempt the conversion. The ONE program is never entered/called.
.PROGRAM reachable()
ONE reachable_err
retry:
reachable = TRUE
POINT #jtest_point = test_point
IF NOT reachable GOTO retry
PRINT 4: "Point reachable"
.END
.PROGRAM reachable_err()
PRINT 4: "In Reachable_err"
PRINT 4: "Point not reachable"
reachable = FALSE
RETURNE
.ENDMy next idea is to write an IK solver in AS, but I would prefer not to do that.
I've had a couple of line tracking robots show up from Fanuc like that. FSSB was missing entirely. Wish they did a better job on their build before they shipped.
I reverse engineered what the sFc section does a while ago.
My comments:
' In the URL, the ending
' sFc=1 is for Registers comments
' sFc=2 is for Register values, and the URL template in the "WriteComment" Sub will not work
' sFc=3 is for Position Registers comments
' sFc=4 is for User Alarms comments
' sFc=5 is for User Alarms Severity values, and the URL template in the "WriteComment" Sub will not work
' sFc=6 is for RIs
' sFc=7 is for ROs
' sFc=8 is for DIs
' sFc=9 is for DOs
' sFc=10 is for GOs
' sFc=11 is for GIs
' sFc=12 is for AIs
' sFc=13 is for AOs
' sFc=14 is for String Registers
' sFc=15 is for String Register Contents
' sFc=19 is for FlagsCould you post the packaged cell? I'll load it up and take a look.
Under tracking setup, do you have your tracking set to Rail?
