Posts by Jleon89

can anyone give me more info about the difference between $SCR $JOGLIM and $SCR $JOGOVLIM

I'm trying to compile a list of useful variables for personal use as we set up new robot cells from scratch regularly. There are several that are useful but 100's that are of little to no use for anyone not involved with direct development of the robot's systems. If anyone has any useful variables that they use regularly please share them. (I know there are several other threads touching on this but I didn't see any this focused)

I titled the thread $SCR because this is where I've found most of the variables that I find useful but I still don't know what a majority of them do.

I've found a few useful basic variables but any variable that has been useful to you in the past, id like to hear about it and what it does/how it was useful. Below is a short list of some that I have recorded already but I would like to expand much more on this (especially in the $SCR variable)

Any input is appreciated.

• $DMAURST – Deadman switch automatic reset function
  • Change this variable to switch between manual fault reset and automatic fault reset in Teach mode. Meaning when this variable is set to ‘1’ and the TP is enabled any faults will be automatically reset when the deadman switch is depressed. When set to ‘0’ the reset button must be pushed after the deadman switch is depressed.
  • Max: 1; Min: 0; Default: 0 
  • Takes effect immediately after change
• $MASTER_ENB – Mastering enable
  • Specifies whether or not the System Master/Cal screen is available in the menu.
  • Max: 1; Min: 0; Default: 0
  • Takes effect immediately after change
• $GENOV_ENB – General Override Enable
  • Enables (1) or disables (0) the %UP and %DOWN keys.
  • Max: 1; Min: 0; Default: 1
  • Takes effect immediately after change
• $MAXUALRMNUM – Maximum number of User-defined alarm messages
  • Determines the number of User-defined alarms that can be used.
  • Max: 1000; Min: 1; Default: 10
  • Requires a controlled start to change, cold start after changes
• $REFPOSMAXNO – Maximum number of reference positions
  • Set the maximum number of reference positions available to program per group.
  • Max: 64; Min: 1; Default: 30
  • Requires a cold start after changes

Quote from Erik Olsen

HawkME explains it well in this thread: LPOS

Thank you this is exactly what I was looking for. I was just approaching it wrong. An analog sensor could work too and may even be more accurate but would require additional hardware.

ok cob webs gone, thanks guys.

Its been a few months since we had a robot to program so Im shakin off the cob webs a little still. I had an idea for this one but I cant seem to figure out how to get it to work. Im hoping dome crowd sourcing will help.

The cell we're building is pretty simple, the robot is mounted inverted on the front of an existing machine and will simply pick sheets of plastic to be formed and load them then unload the finished part and put it on a conveyor. As the robot repeats this process the stack of material will get lower and lower. In the past we have had customers install vision systems to detect how close the tool is to the part (sadly, they had a different company do this so I didn't get a chance to be involved with that setup) but this isn't in the budget for this project. I have also set up a "reverse palletizing" system in the past that would adjust a PR in the -Z direction the thickness of the material so as the stack got lower the robot would reach lower. This requires the PR to be "reset" after loading a new stack however and I would like to avoid this issue this time around.

My thinking is to somehow use the part present sensors on the tool to determine the position the robot needs to come down to. I set up a condition monitoring program to record the current position of the robot and populate a PR. But I cant have a motion group in the program called and I cant set PR(10)=LPOS without a motion group. Does anyone have a better way to do this or is what Im trying to do not possible?

We were able to recreate the same issue on a "mirror clone" of the first machine which has the exact same program structure as the first one. From what I can tell it's almost like it's running 2 steps at the same time. It is supposed to rotate to a parallel (to the floor) position and THEN travel into the work position over the table. Instead it tries to move to work position AND rotate to parallel position simultaneously.
The program that moves it to work position looks to see if it's in a parallel position, if it's not it calls the program to rotate it to the correct position then returns to the original program to move the table to work, if it is in a parallel position it skips the call step and jumps right to the "move to work" step. Instead it's both rotating AND traveling at the same time and as far as I know its not supposed to be able to do that.

We had one of our robot cells that we are installing crash just before thanksgiving. The basic concept of the machine is 2 robots lay the glue path on a headliner and then a 2 sided table (also controlled by one of the robots) rotates to a parallel position and then travels over top of the headliner and extends cylinders to place the plastic parts on the glue paths. We were already on the road when the customer called but from what I could gather the table attempted to travel before it went to parallel.
The only thing preventing it from doing this right now is the way I have written the programs that carry out this action. (The program looks for an input from a reference position that the table is at one of the 2 parallel positions before it moves over the table) But clearly something went wrong and I'm not confident this method is gonna be 100% reliable.
I'm wondering if there is a way to restrict group 2 (travel) to only be able to move if group 3 (rotation) is at either 0° or 180°. Kinda like an Lstop that only restricts group 2.
Any input is appreciated, Thank you.

UI is set up the same in both robots (rack 89 slot 1 start 1)

We have checked the io comm several times throughout this project but we checked them again and everything seems to line up.

I added by programs to track UI4 to see if it came on as well as others to track UI1, UI3 and UI8 to see if they ever turn off. We have ran it 3 times now all 3 resulting in the aborted condition but none of my counters have gone up.

We are in the process of combing through his plc program bit by bit.

Ok I'm having a weird issue with one of my robots. We are building a cell for a customer that is laying glue paths and then gluing parts onto a headliner. Two robots laying the glue (M-20iA robots with R-30iB plus controllers communicating with a L30ER compact logic Allen Bradley PLC) with one controlling a table on 2 aux axis (1 for rotation and one for travel).

When the robots finish their glue paths they return home to get out of the way and the table moves in to glue the parts down. But as soon as the cylinders on the table receive the signal to extend it aborts robot 2's program. It's not supposed to yet. The only reason we need the program to continue running is because there is a signal sent from both robots individually after the glue path is complete so the plc knows the headliner is ready. We need this output to stay on through the whole sequence but to be off to start the next sequence. At the end of both robot programs they run a DO OFF program to turn off any unnecessary outputs but we need them to both wait until the table has returned to its home position before running this program.

Now someone else is programming the plc side of it because I don't know much about plc programming yet. But he is saying that his program is not telling it to abort. In fact the code for both robots both at this point in the program and under the conditions for UI(4) cycle stop are exactly the same so if it aborts one program it should abort both.

My questions are has anyone had this or a similar situation happen before? And is there another way we could be unintentionally aborting the program in robot 2 without sending the cycle stop signal or dropping UI (1), UI(3) or UI(8)?

I'm trying to find a quick easy way to simply change the value of a register from the HMI. We have a timer in a glue line purge program that will dictate how long glue will flow during purge but the customer wants to be able to adjust the time from the HMI. Quick fix would be to have the plc track the timer and just send the robots an input when purge is done but I'd like to be able to set it up either way. Mainly for future reference for myself.

I had all but abandon this idea because it didn't seem like a safe choice but in testing we've discovered a new problem. If an e-stop is hit while the table is traveling it slams to a stop, hard enough to throw the calibration for that group off. I had to jog it to zero and recalibrate from scratch. How do I set that group up as a controlled stop? I can try it that way and see how it works. And/or does anyone have another solution to this problem?

That's usually what I've been doing as well. It just makes it easier coordinating with the plc programmer. For some reason it won't let me configure it the way I want to this time. That's why I was hoping someone on here had a similar issue and/or knew what the issue could be.

Sorry it took so long to reply. The robots are communicating via Ethernet through a hub with an Allen-Bradley PLC L30ER with 2 digital input, 2 digital output and 1 analog 4 channel output physical cards as well as 3 Allen-Bradley point io remote racks and an Allen-Bradley panelview plus 7 HMI.

Just playing around with it trying to figure out what it would let me do this is what I found: If I set my DI (it seems to work the same with DO) to rack 89 slot 1 start 1, I'm able to set a range from 1-46 but if I bump it up to 47 it says invalid. If I skip 47 and add another range starting at 48 I can go 48-64 but same thing, if I bump it up to 65 it says invalid. If I start my first range at 2 I can go 2-64 but not to 65. However after figuring this out I realized my UOP is set up starting at start 1. So I bumped my DI start to 19 (the next available after UOP inputs 1-18) and range 2-64 switched to invalid. It will let me set it to 1-46 or 2-47 or 3-48 but I can't increase the range at all and it won't let me add any other ranges after it.

I thought about this after all this testing but the plc has had no logic dumped into it yet. Could it be that 64 total bits is the default max for internal logic? I don't know a whole lot about plc programming so I'm not sure how that works.

We are seeing up a new machine for a customer but I'm having trouble setting up the IO.
We're using M-20iA robots with R-30iB controllers. It's all brand new equipment so it shouldn't have anything in it that fanuc doesn't set by default. And we just had a tech from fanuc here yesterday to help set up basic dcs settings and 2 external axis. But today I was trying to configure our IO and it wants to make me skip a few bits every now and then but it doesn't seem to be consistent. It's like it has secret conditions that only allows me to configure a certain range of IO's. any help would be appreciated

I'm working on seting up a sonic welding cell with 2 robots (M-16iB) with a controller each (R-30iA) w/ R-J3iC TP's.

The robots are enclosed in the back of the machine with a two-sided table (nest) in front of them. Order of operations is a base part is loaded on one side, the table rotates and the robots start their first weld program and while they are welding the operator is loading a base part on the other side. However, there are light curtains in front of the table (tied into robot fence) so the table can't rotate with someone in front of it. The problem is when this light curtain is broken the robots stop as well. My question is, is it necessary for the robots to react to the light curtain being broke if they are on the other side of the table completely caged in other than about 6 inches on both sides of the table and well above the nest.

I don't want to violate any saftey requirements.

I'm trying to get a sonic welding machine with 2 M-16iB robots with R-30iA controllers communicating via profibus and profinet. The telesonics talk to the plc through profinet and the rest of the components including the robots talk via profibus. We were able to get the robots to talk to the plc (btw still unsure if I configured the profibus in the TP properly I'm new to all of this. If someone has a step-by-step for basic profibus setup I could double check I have it set up correctly) but for some reason something is forcing the first 10 digital outputs. DO6, DO7 and DO8 are forced on and the rest are forced off. Seems to go on about a 10 second cycle. No programs are running and as far as I can tell nothing in the controller is forcing these. I'm at a loss right now though.

I didn't get a whole lot of info but from what I'm being told I think they are just trying to come to a slow stop rather then an abrupt stop on e-stop for axis 7 and 8. They are worried about damaging the gear assembly. Is there a way to safely add a slow down timer to those 2 axis when e-stop is pressed without applying the delay to the whole robot?

I'm new to this type of work (programming robots and programming in general) so if my questions seem obvious I'm sorry.

We are going to be programming a new robot cell we're building for a customer. We are using M-20iA robots with R-30iB controllers. We are still kinda in the planning phase so I can't really test anything yet but the customer threw a bit of a curveball at us already. On top of the 6 axis for the robot itself one of the two robots will also be controlling a load table on axis 7 and 8. But they want us to set it up so if an e-stop is pressed, the robot stops immediately but the table continues moving for 5-10 seconds after the e-stop. Is this possible and if so how do I do it?

Any advise is appreciated. Thank you.