Okay, next issue. Can anyone tell me which pins on the CC1 connector to run light curtains to? I finally got the manual for this but the one schematic is for X11.
KRC1 Light Curtain Connection
-
Jon_G -
June 16, 2015 at 4:07 PM -
Thread is marked as Resolved.
-
-
Depends on how you want them to work. Most of the time, people would use the Safety Gate contact. Actually, the light screens and safety gates would be wired in series, and into the CC1 inputs, often using some combinational safety-relay logic.
Also depends on how you want to go about resetting your lightscreens. If, for example, you have a walk-in opening in the fence guarded by lightscreens, how do you ensure someone doesn't walk in and then get the screens reset behind them?
-
I have a test bench with 2 sets of light screens with simulated situations like this that I want to use in conjunction with the controller but the devicenet setup is not coming along easily without a good manual for it. I do not want to use the MFC/master, I want to keep my ControlLogix PLC as the master so once I figure that out I can work with it. For now the question is which pins on the CC1 are for that circuit so I can tie them in series. (This is a guarded area in a warehouse with a staff of 10 people roughly, myself and my boss are the only technicians and only ones in/around the robot so incorporating other safety features will come with time but are not vital right now). The manuals I have are vague (no pinouts at all) and I'm waiting on delivery of a disk with "everything" I should need for this model according to the seller.
-
eh..!?
can you please elaborate?
it all started nicely with CC1 connector and light curtain, then it suddenly jumped to DeviceNet, PLC, MFC/master, 10 staff, boss and what not...
Standard is that safeguards around robot (cell doors, light curtains etc.) are wired to a robot safety circuit to prevent operation in Auto or AutoExternal mode when security perimeter is breached. On X11 this is called "Operator Safety". In other words, those safeguards are ignored in T1/T2 mode (which may or many not fit your requirements!).
To disable robot when some safeguard such as LC is tripped (and only if robot is in Auto or Ext mode), you can probably use 17-18 and 19-20.
now your light curtain will likely have pair of PNP outputs (OSSD1 and OSSD2) which also means you will need to use "safety relay" (controller) or pair of safety relays (relays). those need to be monitored (verify NC contacts are closed when OSSDs are low). the NO contacts can be used to interface to X11 or CC1 connectors.
That was safety related... now back to standard (non-safe) signals such as DeviceNet and MFC...
this was discussed many times, also bottom of file IOSYS.INI has details on mapping.
DeviceNet is just another bus with same type of things one usually see on a bus (terminators at ends of bus etc.).
Wiring for devicenet is usual culprit - people tend to overlook this and hope for "clear and descriptive message" of what should be fixed when bus does not work. the fact is you get not so clear messages and to troubleshoot, you need some very specific knowledge. if you ask me, verify wiring first - make 400% sure it is correct, check configuration and mapping... and only then try powering it up... -
To disable robot when some safeguard such as LC is tripped (and only if robot is in Auto or Ext mode), you can probably use 17-18 and 19-20.
now your light curtain will likely have pair of PNP outputs (OSSD1 and OSSD2) which also means you will need to use "safety relay" (controller) or pair of safety relays (relays). those need to be monitored (verify NC contacts are closed when OSSDs are low). the NO contacts can be used to interface to X11 or CC1 connectors.
That's what I needed to know, thank you very much.
My issue with devicenet currently is getting an EDS file for the LPDN. I have seen statements that it is on the CD from KUKA which I do not have. A contact at the company we purchased the robot from is sending me a disk but he's not sure if that info is on there.
That's really all I need at this point. I've been working with devicenet on a multitude of equipment for +6 months and yes you are correct, proper wiring is number one. But I'm confident once I get that file I can get things going the way I want to quickly.
-
Normally, with DeviceNet, you can query slaves on the network and get back the vital elements of their EDS data, then add them to your network as a generic device.
-
Already tried that SkyeFire. The info populates but once I create the generic file I get an error stating the Major/Minor revision is incorrect (even though whats in the file and what the LPDN shows do match). I've had this problem once before with a nutrunner computer and the only way to get it going was to get the original eds file. RSLinx/RSNetWorx won't allow modifications to the revision and changing it in the file itself still showed the same error. I'm at a loss from there.