Posts by jay

I just pushed a beta release of fexcel v2.0 to github[1].

fexcel v1 pretty much only allowed you to quickly set all your robot comments based on your spreadsheet. v2.0 is much more powerful. You can still set comments, but you can also quickly create a spreadsheet based on a physical robot or backup or view the differences between a robot/backup and a spreadsheet.

I think the compiler is the best new feature though. It basically lets you use variables (defined in your spreadsheet) instead of indices in your LS source files. (e.g. R{counter} instead of R[5:counter] or PR{home} instead of PR[1:home]).

This is a beta release, so there are probably some issues. I'll try and keep up with this thread, but please use the Github issue tracker[2] if you find any.

Enjoy

[1]: https://github.com/onerobotics…leases/tag/v2.0.0-beta.10

[2]: https://github.com/onerobotics/fexcel/issues

Hi KUKA_Robot_Lovers,

Sounds like either you mistyped the program name or your command prompt doesn't know where the exe is.

1. Make sure your cmd prompt is in the same directory as fexcel (e.g. C:\Users\KUKA_Robot_Lovers\Downloads) or place fexcel somewhere on your system's PATH

2. If you're in the same directory as the exe, you should be able to type "fexcel" then TAB to complete the rest of the filename

3. Use "fexcel help" for more information on the various command line flags

Hope this helps.

I just pushed a beta release of fexcel v2, and I would appreciate your feedback. You can download it here.

From the release page:

New features

* Create a spreadsheet based on the comments of a remote robot or backup directory with `fexcel create`

* Compare the comments in your spreadsheet to any number of targets (remote robots or backup directories) with `fexcel diff`

* Create a configuration file so you don't have to pass the location flags to fexcel every time with the `--save` flag

* See what fexcel sees in your spreadsheet and provided configuration (args or config file) with a bare `fexcel` command

* Get help on any command via `fexcel help` or `fexcel help [cmd]` or `fexcel [cmd] --help`

Improvements

Too many to name, but it's worth mentioning that the comment setting/updating command (`fexcel set`) works intelligently. v1 just hammered each robot with potentially hundreds of requests, but v2 only updates comments that are different from the spreadsheet.

Usage

Use `fexcel help` or see the README on the dev branch.

As far as I know there is no way to pass TPE arguments from KAREL. Maybe there is a secret builtin for that.

You could write a simple wrapper that uses registers e.g.

MHPRMPTY_WRAPPER.TP:

CALL MHPRMPTY(R[x],R[y]) ;

Then just set R[x] and R[y] from KAREL before using CALL_PROG.

Joint moves are not supported while tracking.

Quote

In the process of tweaking the user frame multiple times, the R data (J6) in the position commands P[X] in the TP programs have shifted.

Shifted by how much?

Quote

Does re-teaching the user frame translate data in the position commands?

Your positions are relative to your user frame, but re-teaching or modifying the user frame does not modify the position data itself. (I would be very surprised to see this... going to check actually... EDIT: verified that touching up a user frame does not affect position values. Hey, I've seen weirder things happen!)

If your new frame's rotation does not match your old frame's rotation, your positions will appear off in X, Y and R.

If it's just R that seems off, perhaps J6 was not mastered correctly (or it was incorrect to begin with). If this is the case, then the J6 rotation on ALL of your positions will be different.

It would probably be better to adjust your tool frame's rotation than modify all your positions.

Yep, thanks dha ! No reason for this routine to lock motion, etc... I'll update and publish a new build. Thanks again!

When two identical robots are running the same program and one is visibly slower, it's usually a payload issue e.g. one robot is accidentally using the default max payload while the other has the payload set to something lower.

Barring that, maybe one robot is using Cycle Time Priority and the other is using Path Priority? (Controlled start, Menu > Maintenance > Manual)

Are your UTOOLs correct now, or were they correct before?

In other words, can you use a scale to measure from the robot faceplate to that pin? I'd be curious to see if it's ~129mm, ~108mm or something else.

To be fair, both FANUC's TP and KAREL programming languages have been extremely stable for decades, especially in a forward-compatible direction (i.e. code written in 1999 will probably work on an R-30iB+ controller).

It is a bit baffling that IF-THEN-ELSE controller structures weren't supported until R-30iB, but I'm glad we finally have them. It's too bad you happened to be on v8.20 and not v8.30

I often just delete the whole VR file, but you can also use KCL:

KCL> DELETE VARIABLE [prog_name]var_name

Check your other screens... maybe it's being edited in another panel.

SHIFT+DISP > Triple then SELECT on each pane. You should see the name of the program being edited (if any) in the Comment column next to -BCKEDIT*-.

If it's being edited, you can hit ENTER to bring up the editor and then EDCMD > End_edit to exit.

If it's actually not being edited in any of those screens, I don't know why the controller would report that.

Keep in mind that the Wjnt motion option only affects the wrist ("wrist joint," axes 4-5-6).

Linear + Wjnt should work for a config change between NUT/FUT and vice-versa since you are only changing the wrist configuration, but I would expect to see a fault if you change the elbow/arm config.

Edit: Also keep in mind that the other robot axes will have to compensate for the joint interpolation of the wrist to maintain a linear path when using Wjnt. In general, if you don't need the TCP to move in a straight line, it's probably better to just use a joint move.

I wrote an open-source command-line tool called fexcel a while ago that reads an Excel spreadsheet and then populates the comments/labels for things like registers, position registers, string registers, user alarms, I/O, etc.

You basically tell fexcel where your data is located, how the columns are laid out and a list of robot IP addresses, and it will go and do everything for you... probably in less than a second. (Probably overkill, but it works concurrently. i.e. it takes about the same time to label one robot as it does to label 20 robots)

Usage:

Make sure KAREL is unlocked under Setup > Host Comm > HTTP.

fexcel [options] filename host(s)...

> ./fexcel -sheet Data -numregs A2 -posregs D2 -dins IO:A2 spreadsheet.xlsx 127.0.0.101 127.0.0.102

You can read more about it here or at the project's GitHub repository. Download the latest release here.

There is an ACC motion option that will decrease your acceleration/deceleration time, but there are many things you should check before increasing ACC above 100:

1. Is your payload set correctly?

2. Is your motion optimized? (i.e. is it traveling along the shortest possible path)

3. Is your motion smooth? (use CNT100 wherever possible and avoid FINE if possible)

4. Is the robot waiting unnecessarily?

5. Are your motion segment speeds set appropriately?

FANUC actually added the ACC option to allow customers to slow things down (sub-100 ACC-values) and eventually set the default maximum ACC to 100 because of frequent abuse.

There is nothing that would change the definition of the WORLD user frame. It's always in the center of J1 and the height of J2.

If your points are all off in the WORLD Z coordinate only regardless of TCP orientation, it's likely a frame or positioning issue:

1. Is it possible that you were accidentally using a UFRAME[X] that was close to WORLD (e.g. 0,0,20,0,0,0)

2. Did the workpiece move?

3. Did the robot move?

PR's can be tricky in that the interpreter does not validate the current UFRAME and UTOOL at runtime. In other words, it's possible to record with UFRAME[a] and UTOOL[b] and run with UFRAME[c] and UTOOL[d] with no complaint from the robot.

If points are off with respect to TOOL Z then maybe the tool itself has moved and/or your TCP is incorrect.

I know this is not helpful right now, but you may find it easier to debug these sorts of issues in the future if you use a UFRAME that is closer to your workpiece. It's much easier to say "I know the position should have a Z-value of 100 since the point I'm trying to reach is exactly 100mm away from the frame origin" than trying to work with WORLD positions.

I know this post is a couple weeks old, but I've run into this problem a number of times over the years. I wrote a little KAREL program that you can use to get the status of a task by name and also wrote up a longer article about TPE's RUN statement.

I haven't used it in production (yet), but I plan to next time I have to spawn off a concurrent task.

example usage:

CALL TASK_STATUS('TASK_TWO', 1) ;

IF R[1:TASK STATUS]<>2,JMP LBL[500] ;

! task is aborted ;

! ok to run ;

RUN TASK_TWO ;

END ;

;

LBL[500] ;

! if R[1:TASK STATUS]=0, task is running ;

! if R[1:TASK STATUS]=1, task is paused ;

! there are other statuses detailed in the article.

There is an overlap tolerance setting that recognizes and removes duplicates. e.g. if the software detects a part within Xmm (overlap tolerance) of a part that is already in the queue, it is discarded.

Hard to say without knowing the details of your setup. (boundaries, tracking frame, ref pos vs. your operation PRs, etc.)

Check the work area status screen (status > type > work area) part queue (may have to hit next).

Also I'm not sure, but you may have issues trying to use Wjnt in a tracking program.

rf103 is correct. TP+ is just a language that compiles to TP. Feel free to try it out here: http://tp-plus.herokuapp.com/

The goal of TP+ was to provide a more programmer-friendly environment... maybe a more elegant syntax. I think I managed to improve some things (identifiers, constants, syntax-checking), but it has many issues as well (bad scoping, hacky R-30iA IF-ELSE support, missing features, etc.).

While it is "production ready" in the sense that I used it on a rather complex system that is in production now, it needs work. The most annoying issue was keeping programs and positions consistent between the real robot (TP source) and my PC (TP+ source), though I struggle with this with standard TP as well...

Someday I'd like to try again and fix the entire toolchain problem (auto-detect changes, separation of code from data/positions, testing, etc.). Until then I'm happy to accept pull requests!