Posts by Tarnarmour

I never figured out what was causing this issue, and at some point after about a week of work, it just stopped happening. I'll tell you what I do know about it, but I never got to a really satifactory solution.

First, the cause of the issue is almost definitely that Roboguide and some background Rockwell process (the OPC Runtime Service) are fighting over the same port on the computer. Rockwell's software is flexible and if that port is taken, it'll grab another one. But Roboguide won't, it needs one specific port to be available. This is why using the task manager to kill the OPC Runtime Service works; it temporarily frees up the port and allows Roboguide to grab it.

When you configure the Ethernet/IP settings on the Teach Pendant, you choose how many 16 bit words you want to use. This gives you a total number of bits that you'll be using. When you set up the generic ethernet module in Studio 5000, you need to make sure that you are matching that number of bits. However, you DON'T need to use 16 bit words. It's fine to use the default DINT data type, which is 32 bits, as long as the total number of bits is the same. So for me, I had 4 16 bit words on the Fanuc side and 2 DINT words on the PLC side.

It's important to get the digital IO and UOP configuration right. If you are not using UOP signals, then you should have 64 input and 64 output registers configured to use rack 89 slot 1, and they should start at 1. IF you are using the UOP signals (like if you want the PLC is start or stop the robot remotely), then you need to adjust the digital IO setup to take into account how much of your message is taken up by the UOP stuff. So for me, I had 64 bits, but 20 of the output bits were used by the output UOP signals. I had the UOP outputs set to use range 1-20, rack 89 slot 1, starting at 1. Then I had the digital outputs using range 1-44 (since I have 64 total bits are 20 are used by the UOP), rack 89, slot 1, starting at 21 (since UOP is taking 1-20). Likewise for the inputs, except there are only 18 input UOP signals.

Finally, in case it helps, this is the procedure I used for setting everything up:

1. Create the cell, including the Ethernet/IP Adapter package.

2. In the cell browser select your controller and in the Network settings tab check the box allowing external connections (this will trigger a restart).

3. Configure the Ethernet/IP stuff (number of words, etc.).

4. Check the HostComm setup, make sure the ethernet address is correct (should use the same address as the computer you are on). Add the PLC address to the list of hosts, etc.

5. Configure the digital and UOP IO stuff. If you're using UOP signals there are some settings in the system > config menu to set, I don't recall off hand what they are but you can probably search for that. Probably try to get things working without UOP first.

6. At this point, you should see a warning saying the Ethernet/IP module is idle. This is what you will see when the port is being hogged by the Rockwell FactoryTalk OPC Runtime Service software.

7. Set up your PLC; create a generic ethernet module, set it's target IP address to your Roboguide computer's IP address, set up the data type and number of input / output words to match the total number of bits configured on the robot. I think the instance numbers for the Fanuc stuff are 101 for input, 151 for output, and 100 for config, but check their Ethernet/IP manual to be sure.

8. Download to the PLC. You should now see an error on the generic ethernet module saying you have an invalid segment type. This is the port issue I was talking about.

9. Now, open the task manager and search for OPC Runtime Service. Kill that process (it will come back within a few seconds on its own). This might give some temporary glitches in other Rockwell software, and you should HOPEFULLY see the ethernet/IP stuff connect. Fault will clear on the PLC, and if you reset errors in Roboguide the Ethernet/IP idle error should go away.

As I said, this didn't work for like a week and then has worked since. No clue why, if you have an issue respond or DM me, and maybe just try rebooting things a bunch.

Okay wait I might just be dumb. I've tested some stuff and it seems like even though that red triad is moving, it's not actually affecting anything, the points I record are still relative to the nominal tracking frame, false alarm.

I am still very confused about the detect distance though.

Now, here's what happens when I use the conveyor jog tool to click "Detect". The part moves to the detect point (which by the way was set by just measuring the distance from the origin of the conveyor to the boundary, which ended up being -1086 mm. No idea why that's negative, or why it's measuring from the conveyor origin, or what frame it's in, etc., but this is what it looks like when I set detect distance to -1086 mm), and the red tracking frame moves downstream, along with my taught points.

Quote

It is measured from the origin of your tracking frame. Adjusting it shifts the path up or down stream. If possible, I like to keep the tracking frame origin on the trigger sensor, but if you can't reach the sensor, that is what this is for.

That doesn't seem to be true, unless I've really messed things up? When I set the detect distance to 0 and then use the conveyor jog tool to move the part to the detect spot, it does NOT go right to the tracking frame, it goes to the origin on the line / conveyor.

"Conveyor jog toolbar does this."

When I jog the conveyor, the tracking frame also moves. That's the problem I'm having. If I have the pick action selected, I can see the taught points I've made so far, and a red triad showing (I think) the tracking frame. If I move the part so that I can reach it with the robot to teach a pick location, the red triad and the previously taught points also move, the tracking frame moves, so I can't get my pick relative to the nominal tracking frame. Note, this is not an issue when I actually run things, then the tracking frame doesn't move until a part arrives, like I'd expect. It's just making it almost impossible to teach points.

Here's some pictures, maybe you'll be able to see what I'm doing wrong:

Here is my tracking frame, located on the conveyor exactly in front of the robot, turned so that the conveyor moves things to the left.

Here I've opened the pick program, you can see the red triad which is the tracking frame, and the (poorly set) taught points to the right. You can see, this is with the part located at the origin of the conveyor.

I am trying to teach myself how to do line tracking, so far just in simulation in Roboguide, and I have some questions / confusion about how the different frames work. I'm also confused about how some of the steps for setting things up in Roboguide translate to the actual physical robot cell.

1. My current understanding:

• To use line tracking, you first set up "line" object (a conveyor) with a "link" attached to it. The link could be something like a pallet, or it could be an invisible representation of a moving location on the conveyor. You define the link location relative to the line, and the line relative to the cell world coordinates.
• You set up a Tracking Schedule on the robot. This tracking schedule includes:
  • A nominal tracking frame, with its X axis pointing in the direction of conveyor motion. When you write TP code to pick things up / interact with moving objects, all the movements will be defined relative to this tracking frame, which will move down the conveyor according to the encoder signal (or just at a constant rate in Roboguide).
  • A set of boundary planes, which define the region where the parts can be interacted with by the robot. I THINK but am not sure that this means that any poses defined in a line tracking program that are outside of those boundary planes will cause an error; in other words I think that it's not the part that's bounded per se, but the poses (which are relative to the nominal tracking frame) that the robot moves to that are bounded.
  • A part detection distance, which tells the robot where the physical part detection switch is located. THIS IS A HUGE MYSTERY TO ME. What is this distance measured from? I get what I'm measuring TO, but what frame is it relative to? As far as I can tell, it's relative to the link pose, which is relative to the conveyor object. But I've never told the robot where the conveyor is, I've never put that into the teach pendant, and since the link object moves around all the time, it's not obvious what the significance of the default link pose even is.
• Write the programs that actually do the task.
  • A MAIN program that activates the specific Tracking Schedule that you're using, waits for the part detection switch (which is hooked up to a specified DI), then gets the current encoder value. I think that you set the current encoder value using the SETTRIG command. Then, MAIN calls the actual line tracking action.
  • In my program, a PICK action picks the moving part. Set the line tracking fields in the details section for this action to use the specific Tracking Schedule you're using, and then all the poses moved to in this program will be relative to the moving nominal tracking frame. To program this, you need to teach points relative to the moving frame, which is my other big question. HOW CAN I GET THE NOMINAL TRACKING FRAME TO GO TO THE CORRECT SPOT WHEN TEACHING POINTS? The problem I'm having right now is that even though I've configured the tracking frame to be right in front of the robot and at the height of the conveyor, when I go to teach or retouch points in the program, it's setting all the points relative to the shifted tracking frame, like the tracking frame has been moved down the conveyor to the out-bound boundary plane, so all my points end up inaccurate. Is this because it's not resetting in between test runs? Do I need to manually reset the line tracking encoder value or something? If I use the conveyor tool menu to reset the part to the "detect point", it moves the part to the right location but does NOT move the tracking frame back to it's default position.

Sorry, tons of text here, but to briefly recap my questions:

1. What is the part detection distance measuring from? If it's really just measuring from the conveyor object in Roboguide, how would this work on a real robot without Roboguide?
2. It seems like the tracking frame is moved down away from its nominal position when I try to teach points, making it really hard to actually get any points taught accurately.

Are there better resources to figure this out? Any help or documentation would be appreciated, I'm just reading the Fanuc manual right now (which is not super helpful) and other than that I've just got one 30 minute long youtube video with no narration or explanation of what's happening haha.

Thank you, that's exactly what I was looking for!

I recently rehosted Roboguide to a new computer and I think some setting has gotten messed up in the process, but now when I run programs using the teach pendant (as in pressing the SHIFT FWD buttons) the robot cell is rendering extremely choppily, like 1 or 2 frames a second. My first thought was that the new computer I'm using isn't fast enough, but if I run stuff using the simulation tools in Roboguide (like the big PLAY button on the top bar) I can get it running butter smooth 60 FPS without even really taxing the GPU at all.

Is there a setting that I accidentally changed or that has a weird default value that makes the cell render slowly when editing or something?

I've been just banging my head against a wall for the last few days trying to fix this, any random advice would be amazing.

So I've got a weird setup where I have a PC in our office with Fanuc's Roboguide software installed on it, and I need to get a virtual robot cell to talk with a PLC (a 5069-L310ER) using Ethernet/IP. I've pieced together from random forum posts and some actual Fanuc docs how to do all the setup, and as far as I can tell everything should be good on the Fanuc side. On the Allen Bradley side, when I set up a generic ethernet module to connect to Roboguide, I always get a faulted state, with the module saying it has an invalid segment type. Double and triple checked the data types, word sizes, IP addresses, and if there's an issue I haven't found it yet. The robot shows an enabled Ethernet/IP configuration but status is offline, Studio 5000 shows the generic ethernet module faulted, no comms are working.

Now, this setup is a bit niche because 1) I'm connecting to an emulated robot cell in Roboguide (but that should be possible, I've set some specific system variables to enable that in Roboguide) and 2) both Studio 5000 and Roboguide are on the same PC. But this doesn't seem to be working even when I just run it on the PLC as a stand-alone thing. I've done some (i.e. way more than I ever wanted to) reading and heard that there's a background process called FactoryTalk Linx OPC Runtime Service that can apparently interfere with Ethernet/IP, so I tried manually end-tasking it. Weirdly, when I do this, the status on the Fanuc Ethernet/IP connection changes to ONLINE, but I can't confirm that anything is actually working because no data is sent (as far as I can tell). I also don't know for sure if this OPC Runtime Service thing is even the issue, because if I close Studio 5000 the PLC on its own doesn't seem to be connecting to the Fanuc robot.

I know this is a long shot, but if anyone has any advice for this super specific issue it would be a lifesaver.

Okay, thanks for the answer. This feels like a really weird design choice, since you still include the definition of the position variable in the header but it just isn't used most of the time. I guess they really just expect you to teach all the points? Pretty cumbersome for what I'm doing but I guess that's just how it is.

I working on a tool to automatically create INFORM jobs from scratch, and I'm confused about how the position variable definitions work. I can see that the header for each .JBI file lists out what types and how many of each position variable are going to be used in the program, and then also defines the position variables, like so:

///POSTYPE PULSE
///PULSE
P00002=18618,15170,-34133,0,-36409,0

This part of the header defines the user position variable P00002 by giving the exact pulse values. What I find confusing here is that I could then change P00002 in this inform file, or I could change it in some other file, while running the script. Long term, I am going to need to be able to set, modify, and move to position variables across multiple INFORM files. I might define an XYZ position variable in Job 1 and then shift it up by 100 mm in Job 2 before moving to it in Job 3.

Here's my question: if I don't know what the final value is going to be, what do I put in the header in Job 3? Do these headers even matter, or will the value just change as things run? If the first Job I run is Job 1, and Job 1's header says that P00001 is at [1000, 0, 0, 0, 0, 0], will that be true every time I run Job 1, even if Job 2 sets P00001 to [1000, 1000, 0, 0, 0, 0, 0]? Or would I need to put a bunch of SETE commands in Job 1 to manually reset P00001 to the correct initial value each time it runs?

I'm generally quite confused by how these variables are used. It really seems like they might only be intended to be used by manually teaching every position. If so, is there another better way to do what I'm trying to do here?

Quote

For joint motions I only see % and sec.

So you can't even set the <msec> option? I can set it in the teach pendant, I just can't build an LS file that has it set. Very weird, but good to know that <sec> will probably work.

I've been automatically generating and compiling LS files into TP code for a while now with no issues, but I've just found a weird problem with timed joints moves. For context, I'm running the old 5.30 controller software version (compatibility for a customer with an old robot). Here's the LS file I'm trying to translate:

/PROG  COL_PLC1
/ATTR
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;
/MN
	1:	J PR[1] 750msec CNT100 ACC100;
/POS

/END

and here's the error I get when building:

Quote

----------------------------------------------------------------------
Translating E:\plc_test\col_plc1.ls

Error occurred during load
E:\plc_test\col_plc1.ls(13)
on line 13, column 38
Undefined instruction
E:\plc_test\col_plc1.ls(13)
on line 13, column 31
Undefined instruction
Build Failed: Error translating program: Code: 0x160002: [SPRUNCMDF] status = 38000F; "ERSRCH 0X160002 " :
----------------------------------------------------------------------

Display More

If I change to a linear move, this works fine. If I change the velocity type to percentage, like 1: J PR[1] 100% CNT100 ACC100;, it's fine. What's really weird is that if I open the teach pendant and change the program, I can make it a timed move, and I can even print out an LS file. But that same LS file then will not re-build.

Again this is with the old 5.30 software version, but does anyone have any idea about this?

Okay it was not very fun but I'm doing it manually now and it works. Here's the relevant code in case any poor soul ends up in the same boat in the future.

   1:  ! R_TO_ZYX(source) converts a matrix rep in PR[source] into a XYZWPR rep ;
   2:  R[16] = PR[AR[1], 2];
   3:  R[17] = PR[AR[1], 1];
   3:  IF R[16] < 1e-5 AND R[16] > -1e-5 AND R[17] < 1e-5 AND R[17] > -1e-5, JMP LBL[1];
   4:  CALL ATAN2(R[16], R[17], 19);
   5:  R[16] = (-1) * PR[AR[1], 3];
   6:  R[18] = R[16] * R[16];
   7:  R[17] = 1 - R[18];
   8:  CALL SQRT(R[17], 17);
   9:  CALL ATAN2(R[16], R[17], 20);
  10:  R[16] = PR[AR[1], 6];
  11:  R[17] = PR[AR[1], 9];
  12:  CALL ATAN2(R[16], R[17], 21);
  13:  PR[82, 1] = PR[AR[1], 10];
  13:  PR[82, 2] = PR[AR[1], 11];
  13:  PR[82, 3] = PR[AR[1], 12];
  13:  PR[82, 4] = R[21];
  13:  PR[82, 5] = R[20];
  13:  PR[82, 6] = R[19];
  14:  PR[AR[1]] = PR[82];
  15:  JMP LBL[99];
  16:  LBL[1];
  17:  R[16] = PR[AR[1], 3];
  17:  R[20] = -90;
  18:  IF R[16] > 0, JMP LBL[2];
  19:  R[20] = 90;
  20:  LBL[2];
  21:  R[16] = PR[AR[1], 8];
  22:  R[17] = PR[AR[1], 7];
  23:  CALL ATAN2(R[16], R[17], 19);
  13:  PR[82, 1] = PR[AR[1], 10];
  13:  PR[82, 2] = PR[AR[1], 11];
  13:  PR[82, 3] = PR[AR[1], 12];
  13:  PR[82, 4] = 0;
  13:  PR[82, 5] = R[20];
  13:  PR[82, 6] = R[19];
  14:  PR[AR[1]] = PR[82];
  15:  LBL[99];

TLDR; I can convert XYZWPR to Matrix on old controllers, but I can't go back from Matrix to XYZWPR.

I've developed a software package that is used to translate a custom robot scripting language into Fanuc TP code automatically. Part of the setup is a collection of utility TP programs to do things like convert between different pose representations, do specific transforms on poses, etc, and many of these TP programs rely on being able to convert XYZWPR poses into their homogeneous transform / matrix representation, and back again, like so:


I'm now trying to make a version of this project that will work on older versions of the Fanuc TP language. I'm currently developing on version 5.30 (the oldest version available in Roboguide) which runs on an R-J3 controller. From this (Fanuc Robot Forum) post, it seems like the $PR_CARTREP system variable wasn't introduced until a later version, but you can still get the matrix representation by using the UFRAME trick. However, I can't convert any of the poses back. The Matrix representation seems "infectious" in the sense that if you have a pose in Matrix form, copying it into other poses also makes them Matrix-ey and the only way I've discovered so far to change them back is to manually change the representation in the "Data" screen on the pendant.

Any ideas would be very appreciated, Merry Christmas!

I am trying to do some simultaneous motion of the robot and an external axis (a rail that the robot is mounted on) using the GP Simultaneous command, but I always get the CPMO-199 error, saying I can't use Constant Path and simultaneous movement at the same time.

The problem is, I can't set up my cell without including the Constant Path option. Something about having the external axis or the HandlingPro setup seems to require the CP option. I've tried disabling the Constant Path option as well using the system variables, but it didn't make any different.

Can anyone help with this?

Thank you!

I don't have matched payload and armload data because I'm not comparing motion to a real robot, I'm measuring how long it takes the virtual robot to do a timed move. In other words, I'm not telling it to move at 50% and comparing its speed with a real robot, I'm telling it to do an 8 second move and it's doing a 6 second move.

*You know that you must use the "Test Run" menu? When running program from virtual Teach pendant the cycle time doesn't match.*

Okay that's the "Test Run" menu in Roboguide, right? I think this might be exactly what I was looking for. It has an option called "Synchronize Time" that I already had checked on, is that only applied if I click "Run" from the Run Panel?

I've noticed that Roboguide's simulation runs significantly faster than real time, and I'm not sure where to change this setting. I've tested this by doing joint moves with the travel time speed type:
J P[2] 8.0sec FINE

The actual travel time is a little tricky to time exactly, but it's about 5 seconds. This pattern is pretty consistent; all timed moves seem to take about 75% as long as they nominally should.

Does anyone know if there's a setting like simulation speed anywhere that I'm just missing?

Unfortunately I can't really give all the details here but it's a result of the structure of the language that I'm translating from. I'm trying to make a one-to-one match of behavior where possible and the source language involves these kind of situations.

If this is impossible, I might just need to change how the source works to avoid this situation.

Is it possible to check if a TP program exists without getting stuck in an error state? Ideally, I'd love something like this:

R[1] = CHECK('PROGRAM1')
IF (R[1]<>0) THEN
CALL 'PROGRAM1'
ELSE
CALL 'PROGRAM2'
ENDIF

Failing that, is there a way to automatically recover from an error state (maybe using a background program?) so that I could just try to call the program, get an error, recover from the error, and then try another function call?