Posts by ConnorAlbright

There are probably better solutions than what I'm writing below. At least this method works without any special options installed.

The robot webserver is accessible on the PC when using roboguide. 127.0.0.1 (localhost) for most setups.
When you go to this address in your browser, look for the POSREG file.
http://127.0.0.1/MD/POSREG.VA

This file shows the current values of all the position registers.

You could create a script to periodically request this page and read off the coordinates and save them to file.

I've successfully used this method for debugging before.

If I had an application where I was trying to combine multiple smaller programs into a single larger program I would do it on a computer by editing the .ls files in a text editor. But if you did that you have to have a way to compile the .ls back to a .tp file. The two common ways that I know of to do that is:
a) Use Roboguide.
b) There is an option that allows .ls files to be loaded into the robot, then the robot then complies to file to .tp. The option is named something like "ASKII-LOAD".

I have a system using line tracking (conveyor moving in the +X direction). The robot turns the cases and moves them side to side (on the Y dimension). The EOAT is a plate slightly bigger than the case, with each side extending down (roughly 1"), roughly like an upside-down cookie sheet with tall sides. The cases is never picked up, only guided along the conveyor.

How would I calculate the payload?

My thoughts: The payload weight would be only the weight of the EOAT, since that's all it's lifting.
Would the payload center be the height of the EOAT, plus half the height of the case?
The inertia I think would be something to do with the weight of the case, combined with the friction of the conveyor belt. I'm guessing the movement of the conveyor belt would factor in somehow. The inerita for Z would probably be 0 since the movement is only in the XY plane.

I have my guesses, but physics class was so long ago, I could really use some pointers. Even just the right terms to looks for so I could figure it out for myself would be useful.

This is not specific to any language, these strings just need to be sent as http requests to the robot.
Use with extreme caution:

Set numeric register 20 to the value of 999:
[robot_ip]/karel/ComSet?sValue=999&sIndx=20&sRealFlag=0&sFc=2

Set the comment of numeric register 20 to "I'm in your mind":
[robot_ip]/karel/ComSet?sComment=I%27minyourmind&sIndx=20&sFc=1

Note that Karel needs to be unlocked in HTTP setup.

Source for this information: The javascript that runs comment tool on the robot.

You should be able to ping the robot from the system you have Roboguide installed on. If you can't than you have different problems and the below will not help you (yet).

Robot Neighborhood should be installed on the same system as Roboguide. Use that to set up both your virtual robot and your physical robot.
Then once you are in Roboguide:

Tell it what files you want to send.
Project -> Export -> Edit list
Note that generally when I do this I am only exporting my .tp files. Most other files require you to be in a controlled start. Program (.tp) files open on the Teach Pendent (even in the background) will not export successfully.

Send the files:
Project -> Export -> To Robot
On the screen that comes up "Export to the target robot", on step 2, choose the robot you want to export the files to. This is populated by Robot neighborhood.
Now hit Export and let it run.

Can you tell us a bit of what you did to get it going?

To take the state of the sixth DCS zone status and assign it to DO 66:

IF ($DCSS_PSTAT.$STATUS_CPC[6]=0),DO[66]=(ON)
IF ($DCSS_PSTAT.$STATUS_CPC[6]=1),DO[66]=(OFF)

To set robot speed to 10%:
$MCR_GRP[1].$prgoverride = 10

I have a robot in roboguide, and a CompactLogix PLC sitting on my desk. Is there a way to get roboguide to communicate with the PLC so I can do some testing?

Could the position registers be different coordinate systems? Not sure if that would do it.

Also, I've run into vaguely similar problems when I had an "IF" but no "End If".

I think we are on a similar page, though I only have two zones:
1 - human enters warning area (10% speed).
2 - violation area - estop robot.
And yes, DCS is being used.

Thanks for the TP enable bit suggestion, I will use that.

Using light curtains.

What would be a safer speed? 10%? 20% was just a preliminary number.

My new solution:

In background logic:
If DI[30:Safe] == Off Then
$MCR_GRP[1].$prgoverride = 20%
Else
$MCR_GRP[1].$prgoverride = 100%.
End

It seems to work great. Are there any best practices that I am violating?

I was wrong Override Select does not quite do what I need.
It works great for when I want to slow the robot on a signal.
However, Override Select allows exactly four speeds to be set, selected by two Digital Inputs [00, 01, 10, 11].
Unfortunately, if I use this feature it seems that I can only use these four speeds. I wouldn't be able to set the custom speeds for each recipe.

So now I'm back where I started.

No, using a normal yellow Fanuc. The advice I got from the Fanuc rep was from me asking him about using a collaborative robot for the application, and he suggested just slowing the robot instead.

I just found the Override Select feature. I think that this should do what I want.
Setup -> Ovrd Select

I have an application where the robot should slow to a safe speed when the operator approaches. I was talking with a Fanuc rep a while ago about our application, and (I thought) he said I just need to drop the SFSPD signal when the robot needs to slow down. However, when I drop the SFSPD signal the robot just stops. What am I missing?

Yes,you're right, 'regular TP' files can be versioned.
I should say instead: it's finally worth it for me to place my robot code in version control.

TP+ has dealt with many of the little things, abstracting them away so I don't need to worry about them.
Some of the things I like:
- Syntax errors are almost not a thing at all, and when they are they are usually fast to debug.
- Using names for variables (registers/IO) instead of numbers.
- Comments are super, super easy. (My code now has more comments than actual code, not practical before).
- A very forgiving syntax.

Also, who wants to take the time to remove line numbers? The main reason I use version control it to make life easy for me. Removing line numbers just adds to the work.

In case anyone else ends up reading this:

I've been using TP+ very successfully for the last two months. It's nice to finally have my code under version control.

I did need to write a wrapper around the code to compile it all at once and to pull in all my registers from a central document.
From talking with Jay, I think I could do something similar (and easily and better) with make files, but I have not explored that path yet.

And yes, there are lots of little things that need to be worked on, but nothing show stopping.