Posts by HawkME

I recommend making a sharp pointer that you can attach (repeatably) to your tool. Teach a tool frame for that first.

Then with that newly taught tool frame active you can teach your user frame. It isn't possible to teach an accurate user frame without the tool first because you are using the TCP to teach the user frame.

The robot only knows itself, or rather an internal model if itself. When you teach a tool frame then it now will know where that pointer is relative to itself. Then when using the pointer to teach the user frame it will now know where the conveyor is relative to itself. It all builds together.

The best place to put your origin (and x+ and y+ points) is where you can repeatably do it again in the future and it lines up straight with your conveyor. I prefer to attach or punch a physical point into the object such as a side wall of the conveyor.

3 point Tool and 3 point user frame is the standard and is perfect for most applications.

That translation logic doesn't look right to me. The problem with any direct modification of a user frame is that you are modifying relative to world. So if your world is not planar with the user frame then you will be rotating on a tilted axis.

You have 3 options:

1. I think there may be a program utility to shift/rotate/mirror programs you could try.

2. Just teach 2 separate programs.

3. Use Matrix math to correctly rotate the frame relative to the current UF position.

UF[1] = your original user frame.

PR[1] = your adjustment values

PR[1,6] = 180 (degrees) which will rotate about your UF origin.

PR[1,1] likely needs to have a value to translate back due rotation about your origin

PR[1,2] likely needs to have a value to translate back due rotation about your origin

UF[2] = UF[1] X PR[1]

(the X above denotes matrix multiplication).

The problem with #1 and #3 is that it probably cause your tool to rotate 180 degrees as well. I'm guessing you don't actually want that. So solution #2 is probably the simplest and easiest. It appears you only have 6 points per part. Sometimes simple is good.

Most robots don't have the SkipJump function but instead have the more standard Skip function.

Skip and SkipJump are really the same thing, just reverse logic of eachother. So there is no real need to have SKipJump.

You can add a Skip command onto every motion and if the condition comes true then it will stop motion then skip to the next line of code. If the condition never comes true then it will finish the motion then jump to the label.

If you prefer the system monitor then keep reading:

There is a workaround to triggering motion with a system level condition monitor. Your action program must abort the current program then turn on a signal that starts a macro. You must use flags and UOP signals to make it work. In the example below F[1] is mapped to UI-Cstopi and F[2] is the trigger for the macro with your motion in it.

Set these system variables:

$TTP_MON.$LOCAL_MT = 2
$TTP_MON.$GLOBAL_MT = 2

Code

:  WHEN DI[1]=ON, CALL ACTION_PROG ;

ACTION_PROG.tp (Group Mask = *,*,*,*,*):

Code

:  F[1]=(ON) ;
:  WAIT 2.00(sec) ;
:  F[1]=(OFF) ;
:  Wait 1.00(sec) ;
:  F[2]=(ON) ;
:  Wait 1.00(sec) ;
:  F[2]=(OFF) ;
:  Wait DI[1]=OFF ;
:  Monitor SYSTEM_MONITOR ;

Create a tool frame and user frame.

Tool frame defines your tool center point.

User frame defines a coordinate system based on your conveyor.

Then with those frames active teach your program points. Then all jogging and program will be relative to your conveyor.

GO's are integers, so not much use for sending a string.

You must use a string resister SR.

If you know the system variable then you could try to set an SR = to that variable in BG Logic. Then use an explicit message to read that string resister. On AB PLCs it is the MSG instruction.

You can multithread your VB code to do multiple robots at once with FTP. You have to use the dotnet FTP methods not the the ftp.exe script.

It won't be any faster though. Even if multi-threaded, the FTP connection will only service 1 robot at a time, it will just bounce between the different connections. So for example if you have 3 robots to backup and they normally take 1 minute each. If you do 3 at a time asynchronously then they will all happen at the same time but still take 3 minutes to complete.

I'm not sure if there is a way to prevent that systematically.

Even if you prevent fwd/bwd they can still press the up down arrows to put the cursor on a different line.

I say either lock the TP in a box, or monitor TP enabled in BG Logic or your PLC.

How are you starting the robot? If you are using UOP, then simply don't provide the operators with a resume button. If they turn the teach pendant on and off then you can force them to start the program over from the beginning.

You configure the UI/UO the same way that you configure DI/DO. There is not difference in the setup only what they are used for.

Rack 35 is a special built-in always on rack.

You are on the right track

Do everything you stated, then:

Set Production start method = UOP

Use UI 18 to start the main program.

Setup a UI for cstopi and set abort all by cstopi to true in the system config menu.

Setup a UI for reset.

The previous replies were because it was posted on the general robotics forum, not the Fanuc forum and had no mention of what brand of robot was being used. A mod moved the post to the correct forum.

This looks like a homework assignment.

There is an option you can purchase for expanded storage. R798 DRAM file storage. I believe that would give you plenty of storage.

Another option would be to setup an FTP server and interface to send files. That option would be much more complicated.

You didn't mention your controller model.

Usually when people run out of memory they are either using generated code from a CAM software or are not using correct programming techniques. I have done very complex and elaborate programs that were under 200kb.

Quote from EMSSTC

To anyone with the same problem,

The input and outputs go through message blocks in the PLC.

EMSSTC

This is the case in your situation. That doesn't mean it's the same for everyone else. This communication could be done many different ways.

1. PLC message

2. PLC Ethernet digital IO

3. PLC hardwire

4. Robot to robot comm

5. Robot to robot hardwire

6. PC comm

There are probably others I didn't mention. It is a custom program so others with the same problem must understand their system setup first.

The mechanical manual has the max force and moments that the robot can apply to the base.

In general I would be thinking 3/8" steel plate welded to a framework of square steel tubing that is anchored to the concrete.

It may have write protection on. You can change that in the program details menu. Also make sure that all programs are aborted and that it is not the currently selected program. Select a different one to be sure.

It means you lost communication with your UOP signals. Find the source and fix it.

It's called Target model collision in the DCS Cartesian check menu. I think it is only available on v9 (r30ib plus).

You jog the axis as close to zero ( or wherever the quick master ref was set) as you can. You just have to eyeball it. Then try to quick master and see if it works.