If you are only using the DCS zones for a home return routine, you may consider checking if Space Check is an available option. Same concept as Cartesian DCS zones, but not safety-rated and therefore does not have some of the limitations you may be dealing with.
Posts by cking8177
-
-
- Plug your USB stick into either the USB port on the controller (UD1) or the one on the pendant (UT1).
- Menu>File>File, and navigate to the directory of the USB media you just inserted.
- Menu>Setup>Unit Load, then press NEXT, then press F2 <LOAD>.
- The message that pops up will confirm the active directory, in this case either UD1 or UT1 depending on your choices in steps 1 and 2. Press F2 <DONE>.
- Navigate to the file in question and press F2 <LOAD>.
- Follow additional prompts as needed.
Hope this helps.
-
The oil is 4 years old. It hasn't been changed in all that time. Today I opened the cap, drained a couple of drops, it looks to be in good condition. I think 7000 hours is not the limit for oil.
The maintenance manual for that robot specifies that the oil be changed "every 3 years or 11520 hours, whichever comes first." So yes, technically, the oil in that robot would be overdue for replacement just based on time. Whether the oil is degraded enough to cause your issue is of course a different question, but I would definitely look at exchanging the grease and oil on the unit soon to eliminate that as a potential cause.
-
You mentioned that the total runtime on the robot was 7000 hours. How many hours since the last PM? How old is the oil in that reducer?
-
How do you implement the condition handling program to be able to call a program which uses a motion group?
I must apologize. I remembered using a structure similar to what I'd described some time back, but after looking over my notes and backups from that project it seems I had run into the same issues you did. The solution ended up involving using skip instructions extensively to interrupt motion and call the necessary home return program.
-
Safe I/O can be mapped to non-safe DI's in the IO config. All safety I/O is assigned to Rack 36. The slot number will depend on how you are getting these signals. If you are using hardwired safe inputs wired to the robot's E-Stop board, such as from an area scanner, then you can use Slot 1: SPI (Safe Peripheral Input). The Fanuc DCS Manual has a more detailed explanation of how these signals are mapped.
As far as how to monitor these signals, a condition handling program may be the way to go. You can write a CH program, let's call it ZONE_MONITOR that says:
WHEN DI[100: Safe Zone 1] = OFF, CALL MOVE_PERCH
Then use a MONITOR instruction in your main program to call the CH program:
MONITOR ZONE_MONITOR
Hope this helps.
-
Is there a method to determine which input gets triggered when the TP emergency stop is activated?
These circuits are not normal inputs/outputs, but rather hardwired circuits directly to/from the E-Stop board. By default, no digital inputs/outputs are actuated when an E-Stop is pressed. You cannot use a typical input or output for a safety application, as those signals are not redundant and cannot reliably indicate a hazardous condition.
If you want to use the status of the teach pendant or controller E-Stop in your programming (which does NOT count as an E-Stop, but simply a status indicator), you can set up digital outputs to be triggered under Menu->I/O->Interconnect->Press F3 [SELECT] -> "ES->DO." This lets you assign specific digital outputs to be triggered when any one of many safety faults occur.
-
I'm developing a TP code to run the robot, and there will be an HMI to oversee the process moving forward. It will have an emergency stop, and that's where I'll apply this strategy.
I’m unable to identify the input number that activates the E-Stop within the code.
Ah, this would be considered an "external" E-Stop, as it's part of a control system that is external to the robot's own wiring. There are two circuits on the robot's E-Stop board designed to be run through a set of relay contacts on an external safety relay. The location of these circuits on the E-Stop board does vary, so you'll want to find the electrical maintenance manual for whichever controller you are using.
-
A Fanuc robot will (should) always stop when the E-Stop is activated, as this circuit is hard-wired. No programming is necessary to achieve this. Do you have a robot that, for some reason, does not do this? Or are you trying to use external E-Stops to halt the robot? What model robot/controller do you have?
-
Yes you can put a argument to R if you want. That not the issue here. In my case I would rather have kind of command that will "ignore" the R between the 2 movement.
My understanding is that you would like to either A, see no major difference in J6 rotation between your initial and intermediate positions, or B, when there is a rotation difference between the initial and final points, the intermediate position should cause rotation that would occur anyway so that extra wrist motion does not occur.
In the case of A, you could simply pass the R-value of the initial position to the PR of the intermediate position.
Example:
L PR[1: Initial position]
PR[2,6]=PR[1,6]
J PR[2: Intermediate position]
In the case of B, you could subtract the R-value of the initial position from the R-value of the final position to find a good R-value along that path to use for the intermediate position.
Example:
L PR[1: Initial position]
PR[2,6]=PR[3,6]-PR[1,6]
J PR[2: Intermediate position]
L PR[3: Final position]
Obviously this is oversimplified. You would need to tailor the code to suit the needs of your application.
Hopefully this helps.
-
Which PLC are you using?
Is the robot communicating with the PLC via hardwired IO, EthernetIP, CC-Link, etc?
Do you want all active alarms, or only the most recent alarm? (The one you would see on the message banner on the TP)
If you are communicating with the PLC via EthernetIP, the PLC can read the most recent active alarm using explicit messaging. This would get you the fault code and fault description in a string variable.
-
Every time we have connected a robot to a safety PLC, we have used relays to handle the actual connections, i.e. the robot E-Stop outputs drive relays which then drive inputs to the safety PLC, and vice versa.
The R30iB Plus (or whichever controller you are using) maintenance manual, available through Fanuc, should have the connection diagrams that you need.
-
Hello all,
I am working on a custom gripper configuration to handle a few unit loads with pick quantities of 4 to 10, as well as one unit load where I am picking two rows of product at once (hence the custom gripper). I was able to work up some custom code to define the UTOOLs for each case, but the issue is that the math involved uses the length of the gripper and R[9: Cur TotUnitsPick]. This gets the job done as far as picking, but because I am using the total pick quantity for that pick cycle, rather than the maximum pick quantity for any cycle, UTOOL 1 is in a different location on the tool depending on whether I am picking 4 cases, 7 cases, etc. This means that the sensor configuration on the tool being used for case[x] present would have to change based on pick quantity, which would be an absolute nightmare to manage.
My goal is that, for a given unit load, the UTOOL values are defined based on the maximum pick quantity for that unit load, so that UTOOL 1 is in the same place on the tool whether I am picking 1 case, 3 cases, 10 cases, etc.
Is there a variable in the unit load configuration that stores the max pick quantity for any cycle? I was looking in the unit load KAREL file (PMULxxx) and found the array of registers that stores the pick quantities per cycle. I was hoping that I could find the max value in this array without having to index through the entire array in a TP program, or hard-coding that max quantity for each unit load. Any help would be appreciated.
Thanks in advance.
-
Hello,
In this case the robot moves to PR[R[20]] with the new offset values. So, if R[20] = 5, then the robot will move to PR[5] with an offset of PR[43].
Hope this helps.
-
Maybe check Menu\Next\System\Config\Return to Top of Program? On my controllers it's usually option 16 or so, just below the WAIT and RECEIVE timeout settings. Maybe this is set to false? I've never had a robot where this was set to false, so I'm not sure how that impacts the startup, but might be worth testing.
Hope this helps.
-
Ah, I see. I can definitely sympathize with the precision concerns. In our application we were able to tighten up mechanical tolerances enough to make our process work, but it took a lot of trial and error.
We were not able to place an encoder directly on the moving carriage as we had to queue pulse counts for multiple carts, so we had to have a common reference for all of them. Is this the case for you as well? Or will you only be required to track one cart/carriage at a time? I.e. carriage #1 is completely done with the tracking portion of the cycle before carriage #2 is entering the tracking area/system.
If, let's say, you are only tracking one carriage, and the amount of time that the encoder would be contacting the carriage is more than the robot's cycle time (with a respectable safety factor), then theoretically you could measure directly off the carriage with no real issue. A nuance with this scenario, going back to some of SkyeFire's concerns, is that you would have to ensure that the encoder make contact and begins counting before the part present sensor detects the carriage, and then maintains physical contact with that cart for the entire duration of any tracking. This would have to take into account variances in process speed, robot cycle time, etc.
As far as a line tracking trigger coming in from a "stopped" conveyor, I don't believe that would cause much issue. There is a field in the encoder setup menu for "Stop Threshold," which tells the robot how low the pulse rate must be before the conveyor is considered to be stopped. This may need adjusted in this case.
As far as the mechanical mount, if you pursue this option I would highly recommend some form of spring-loaded encoder mount to maintain positive contact without placing undue strain on the internals of the encoder. Something like this: https://www.ifm.com/us/en/product/…NgaArG-EALw_wcB
-
I checked and it was set to 0. Is there anyway T2 speed can be adjusted? I just ran (SHIFT+FWD) on a different robot in T1 and T2 to verify and it was significantly faster in T2. Both programs were just simple left to right and up and down 25% CNT100 moves from a resting "HOME" position.
This may be your answer: Fanuc Robot T2 Speed
ETA: You may also want to look through the DCS on the robot, if it is installed, to verify that there isn't some sort of safety logic limiting your speed.
-
We've actually done a similar setup here recently, where a chain conveyor had control of several carts that the robot had to engage with. What we did, which from my research I think is typical, is mount our line tracking encoder to the conveyor itself, so the encoder moved when the conveyor moved. We then set up a photo eye that detected the leading edge of the cart once it was engaged with the chain, and the rising edge of that signal was used by the robot to record the encoder pulse count used to track that specific cart.
I found the Fanuc line tracking manual to be quite useful, but you have to read through it a couple of times to get the overall picture if you've never done line tracking before. There are also some decent YouTube videos out there on the subject.
Hope this helps.
-
I am not aware of any sort of compare utility offered natively through Fanuc. I have used Notepad++ with their "Compare" plugin to compare two text files before, and it works pretty well.
If you are operating on a computer that has internet access and/or cannot run Notepad++, there are quite a few decent web-based compare tools available for free. Diffchecker.com and textcompare.org are the first two that come to mind. A quick google search will yield additional options.
Granted, all these options require the robot programs to be in a text file (.LS) format. These files can be retrieved from the robot by copying the contents of MD to a removable media instead of performing a normal backup.
Hope this helps.
-
pdl thank you for the input. I was able to tweak the UTOOL values and get everything placed properly, though as you predicted the simulation still doesn't look quite right. Thanks again!
Advertising from our partners
