Posts by ClaudiuA

I think you are a bit confused.

Protective Stop is NOT a safety mode. It is a collision error. It is a forced stop. Which is why you can't normally just continue as if nothing happened.
Safeguard Stop and Reduced Mode are what you are referring to as "safety modes".

We ran the same kind of tests with a PILZ representative a while back and every stop has been a shock stop that required us to restart the robot and rerun the sequence, manually.
You can, theoretically, force a signal to enable the robot after a shock but you need a bit more knowledge of programming - scripting - than I know at the moment.

You could, however, just create a small routine that would send the robot back to its initial position. So after you get the shock, you just enable the robot, press stop and then play. In theory you should be able to get a routine running that won't need much from you except 3 button presses.

Use the READ TCP FORCE instead of de/stacking and you can build your own program that does things a bit better than that wizard - I've personally never managed to get anything done with that.
Can you please show a drawing or something of what you're trying to achieve?

Protective Stop is, as the name implies, a PROTECTIVE stop. The robot stops to protect itself and OTHERS. You are bashing the robot against an obstacle. Why would you think anyone would allow a robot to restart automatically after what is considered an accident?! "I have hit a person in the head with this sharp tool I'm carrying in my gripper. Let's hit him again and see if something else happens this time around".
I'm not being sarcastic, but what you're asking is a blatant disregard for safety. Even if the robot is collaborative, you still need to respect some basic safety rules.

Yes, it is possible to increment a variable in a MoveL but I don't really understand what you're trying to achieve there.
Why do you need to use a particular feature for the movement? It would help if you explain what you're trying to achieve.

Hello,

I don't have a robot at my disposal right at this moment, but please check the FEATURE in the move to this waypoint window. If you've got BASE selected there and not your actual feature, the robot will go to the position relative to its base.
I'll have to check with the guys back at the workshop and our own UR10s, but I think that's why you're having difficulties.

Please send me by PM a log of your robot and I may be able to tell you waht's going on.
You will find a magic file for log extraction on the UR official page.

I love tool offsets.
I had to reprogram a robot recently for welding where the welds were mostly linear and simple. Saved me a tone of time when I had to reprogram the whole thing when the client modified their welding devices.

So much time would be saved if I would be allowed to use Tool Offsets PR at the projects I'm currently on. But the client hates having robots that do any sort of thinking, at all, so I'm stuck with teaching dumb positions...

I saw this problem on a competitor's system a while back, with a Lincoln as well.
We helped the client get rid of this by adjusting the wire feeder's pressure on the wire and then adjusting the welding positions to distance the tip a bit from the part. I've also tampered with the welding parameters a bit until I ended up with a stable arc and strong weld.
It was a pain in the ass, but since then they've had no more problems with burnback.

Hello all,

Is there any system variable that I can change so the robot would record more than 100 alarm events in its logs? Or any setting in the robot where I can change this?
The operators of the line I'm working on get a bit too excited whenever an error occurs and they flood the log with resets, T1/Auto switches and all the useless things that make it impossible to actually see what the errors were. I need to increase the log size to something like 1000 errors recorded.

Two cases where I found that:
1. Memory full.
2. Forgetting to insert line and overwriting the previous line.

Never imagined something like this though. In ABB and FANUC you need to jump through a few hoops to get this result...here I got it by stupid chance.
Once that got sorted out, we mapped everything nicely this morning, tested and were on our merry way. Incredibly simple once you know what it is you're actually doing.

Thanks man. The way I understood things was a bit...off. I understood connecting the signals as making them available for the PLC. Didn't actually give much thought to HOW they went to the PLC. Assumed it was something closer to FANUC.

Anyway, with this out of the way Dobby will be freeeee tomorrow. Thanks again.

So, it should end up looking something like the image?

And, if you don't mind, do you see any other glaringly stupid errors in this?

...I think I may delete my account on this forum, just out of sheer shame. I was not aware it worked that way - first time using all of this, so eh...-
Something did seem fantastically odd to me about all of this, but it didn't say anything in the manuals I read.

Thanks man. Now it makes a lot of sense and explains the behavior.

"This makes no sense" is about half of the dialogue around the robot today....
Whatever we set on the PLC as an output towards the robot comes instantly back on the corresponding input on the PLC. On the robot I get absolutely nothing when checking the inputs. And similarly, when I set an output on the robot the PLC doesn't see it. And we're stumped.

And still we're struggling.

While the PLC cand detect the robot fine and dandy, any output from the PLC just returns to the PLC without the robot seeing it.
We've basically got a parrot talking back.

ANyone want to warrant a guess as to what's going on? We've pretty much lost any inspiration atm.

Damn GSE files.

Managed to get to the heart of it and we were using the wrong GSE file after all. Read through most of the topics on PROFIBUS problems here on the forum before I figured it out. I'm feeling a bit foolish now really...

We've compared the GSD file we had WorkVisual with the one on the PLC and they seem to be identical though...

Hello all,

I'm comissioning a KUKA KR16 robot at the moment, with a KR C4 controller to replace an old KR C2 controlled robot. The line uses a SIEMENS 315-2 DP PLC.
The client wants us to prepare the new robot to be fitted into the line when the old one fails. Bit of a hassle if you ask me, but that's the client.

The problem is that I've never configured the PROFIBUS for a KUKA before - or any KUKA - so I'm a bit lost.
I have set everything as far as the manual would cover it, downloaded the project into the controller, connected the PLC to the robot...but the PLC is not seeing the connection to this new robot. The robot is set as slave, has the correct address set in - to replace the old robot - and...that's as far as I've gotten with the thing.
We're trying not to disturb anything else on the line since the robot won't go into production now but I don't know if I'm missng something or if I've misset something.

I'm using Work Visual 4.0.
The software version on the robot is 8.3.32.
There is no fault led on the Beckhoff device in the controller as it only shows RUN.

Does anyone have an idea on how to proceed on this? Or what information I should offer to help diagnose?

I'm dealing with a very similar problem at the moment.
We changed the cable on the welding gun, we changed the batteries, we checked the connections on the battery pack inside the controller door...still we're getting the damn BLAL alarm. Hit a RES_PCA, restarted the controller, everything. The damn thing still keeps showing up. Funny thing, though, is that we're not losing motor calibration on the 7th axis when we shut off power.

Because I'm lacking manuals and I have an emergency, I need to ask this:

Does anyone know if a J2/J3 reducer from a M410iB/700 is the same as a J2/J3 reducer for a M900iA/600?

We have a dead reducer for the second robot and the spare part will take a couple fo days to come along. But we can get the first one tomorrow. Since the motors are the same, I'm asking if the reducers are as well and if my luck's that good.