Posts by macru

Quote from panic mode

I like your optimism but no... this is not what you think, it is not "hard-wired" in conventional sense.

SmartPad has own controller and safety node. safety devices like E-Stop and enabling switches are wired to the safety inputs of the safety node. this then communicates with KRC over EtherCat...

So basically what i assumed in initial post.

So to wrap up it works more or less like that:

SmartPad is a separate IPC with windows CE installed and is remoting to KRC
SmartPad beeing just a terminal does not hold any KRC configuration, variables and programs etc.
SmartPAd has it's own safety node for eStop, deadman switch and the mode selector switch, it communicates with main safety controller over ethercat FSOE with KRC safety controller

correct?

Possible issues might be lack of system admin password, lack of config files for safety devices and possible and most likely a password over safety configuration if the node have an internal controller?

Then that might be even easier then, all safety signals then are hard wired, not transfered over ethercat then? And the 6D mouse and touchscreen and buttons are just a HID windows devices?
I'll investigate further but sounds promising.

Does anyone tried if there is a chance of getting the Kuka Pad to work as a hmi / ethercat device for any other devices? Obviously without KSS software on top, but with all the hardware devices working including the 6d mouse, estop and deadman switch? I would assume you need to have ESI files for it and maybe hardware drivers for mouse. I would like it to run a clean Twincat XAR and twincat HMI on it for some other devices.
I know siemens makes simillar device but profinet based. Beckhoff does not seem to make anything that is mobile, so Kuka Smart Pad sounds like a good solution.

You need to supply power from the same source to the 24v and gnd in the estop board controller. The pulse check is not getting through. I was fighting that for at least 3 days couple of weeks ago.

Just to make sure- are you getting any encoder or battery alarms? How do you execute estop on the external axis- hardware power cut or software DCS local stop or just entire system servo off?

I'd say easiest and fastest would be to call fanuc rep.
If you have servo grippers on other robots check what are the hardware and software differences. your price will mainly be determined by the amount of motors and their sizes. Software will be same price every time.
Problem is you will pay a lot more than when ordering that with a new robot, cause you will pay "service prices" not "factory prices"

Laser sensor touch sensing, but that definitely won't be faster than vision system as you need to run the robot over the face in few directions. Plus if the bolt size is small comparing to possible dislocation it might miss the hole completely.

If you go on the robot TP to the schedule you want to export it actually states the file name where all that data is kept.

What robot + controller + welding machine combo are you using? I can help with that.
Second thing is what material thickness it is. Tast requires weaving so if the material is to thin to accept that it might not work for you and you need different method of tracking.

You'll need to go to fanuc to get you both the software option and the hardware. Give your local rep a call.

Arc Welding robots use oil for wrist joints.
If the robot was purchased second hand in unknown condition the first thing i'd do is order a service visit from fanuc to verify condition of the robot and do necessary maintenance.
Will cost you couple hundred $ but will give you a good outlook on what is going on in there.

It will, but the same if the gearbox and all hardware is sized properly it will be fine during the estop as well.

Quote from just_learning_KRL

Also, does anyone know where I could fine a TP programming reference?.

B-83284EN- R30iB Robot controller operation manual Appendix A.2 and A.3

It's very common application,
Is the table articulated using robot servo? If so DCS Local Stop is your friend, if not, you need to redesign your safety circuit using either different relay wiring or safety controller.

Hi Jesse,

See datasheet:
https://www.fanuc.eu/~/media/files/…-185l.pdf?la=en

By standard robot comes as IP54, which would assume it should withstand water dripping on it. If it will be used in environment where there is pressurised water you should order robot with the optional IP56 package.
I don't think you can retrofit the protection kit, at least without disassembling of the whole robot, which would probably double the cost of the robot itself.

Also all the connectors, wiring and tooling needs to be designed to appropriate standard.
Also a lot depends if the environment is constant temperature and the liquid is pure water or some sort of solution.

Quote from bidzej

The problem is that you can't properly evaluate/diagnose/monitor the status of each safety device, which can be done by means of any proper safety PLC (pic related). That's why safety relays should be used - to ensure all that.
And in this case, the SPIs mentioned in the examples above should come from the relays' outputs.

Safety plc and relays would be 2 different things, I would say either use one or the other.
What monitoring of devices you want to do except for checking consistency of OSSDs and EDM? Those 2 things should be doable using DCS safe I/O and interconnect.
For me it looks like a single relay to cut power of the external devices circuit should be enough though.

Quote from Nation

There is a safety PMC option that you can buy that will allow you to do safety level logic in the PMC.

Still not considered safe as standard Digital I/O is not considered safe, so overwriting it's status with safety signal won't make it safe, even if the PMC have safe functionality.

I'm going through the same thing now, and in terms of Safety Inputs I'm all convinced that relays are not needed, but what about dropping power to energised equipment, controlled over robot IO?
I was thinking to use single safety relay connected to safe output to shut off voltage for all auxiliary equipment.
I could put just a rule in pmc regarding to shut all DO off once the safety is compromised but it is not considered safe by fanuc and relative standards.

Well, Controlled Stop as estop will make it slightly less harsh as it won't engage the brakes but it will slow the system down using servos, but it still be full torque for tables. Which so instead of being hard on mechanics it'll be hard on servos.

Exactly what Robo_Eng_13 is saying then. For reason of non-emergency stops you have the hold, pause and controlled stop procedures. And it is not a delay issue but a graduate slowdown. You can use controlled stop for emergency stop (option), but that increases overall stop time and distances of the system.
Other thing is that the system needs to be engineered to withstand estop torques and forces.
What are the external axes used for? As long as sudden stop is not going to spill liquid hot metal out of foundry bucket I wound't ever consider doing a 10s long emergency stop!

I would say that it will be really hard from the standard compliance and risk assessment point of view. What safety systems you're planning to use?
Look into fanuc manuals regarding "Auxilary axis servo off (local stop) function" in operation manual and DCS manual. From a quick glimpse maximum delay is 2s.