Posts by SkyeFire

It looks like initialization code for a spot-welding tech package for a servo-actuated weld gun.

Powering up the robot and using a laser tracker or dial indicators to measure differences between commanded and actual motion, generally. This holds true for all brands. It pretty much has to be this way, b/c the critical factor you're trying to measure is the difference between how much the robot thinks it moved vs how much it really moved. This is complicated by the fact that the backlash isn't consistent -- a tool mounted to the wrist with an off-center CG might provide enough bias to almost eliminate backlash at certain orientation angles, but produce a massive backlash when making the transition between those angles.

Details? Define "software won't start" -- Windows won't start, or KSS won't start? Does KSS start and then 'hang' during the splash screen? Does the BIOS display on boot?

Before making ANY modifications to the hard drive, make very certain to clone it first, using CloneZilla or some equivalent tool. Re-installing KSS should be possible from the master copy on the D partition, but re-installing Windows would require getting a new install CD from KUKA, unless your robot somehow still has the original CD that came with it.

Each motor has a spline driveshaft, that inserts into a harmonic drive that serves as the "gearbox" of the axis. I doubt the spline shafts will wear over time. The harmonic drive itself... well, it's claimed that harmonic drives, due to their design, wear much more slowly than comparable planetary gear sets, but that's sales-pamphlet stuff. I haven't seen a comparison test dataset.

Frankly, I'd be inclined to believe that the bearings would wear faster than the harmonic drives, but that's just a gut feeling.

As for replacing them... well, the motors are easy to replace, but I can't speak to the actual bearings and/or harmonic drives. There's a series of videos starting here https://youtu.be/6YiPrytt_Ss that covers the process of completely tearing apart a KR-350, and all mainstream KUKAbots are pretty much the same, aside from sizing.

Quote from maxwell

the idea with the axisWorkspace Sounds good
can i influence the exact Output that has to be sent to the sps ?

Yes. This is documented in the manual. The Cartesian and Axis Workspaces can be be configured geometrically, and for which signals they are linked to, as well as whether those signals indicate Inside or Outside.

https://www.robot-forum.com/ro…a-robot-forum/read-first/

Probably not -- AFAIK, the message engine does not accept special ASCII characters, only alphanumeric.

Singularity doesn't really effect the servo motor directly. The normal side effect of approaching singularity is to make the servos go faster, and work harder, until they hit their velocity limit. Reducing the speed and acceleration as you have done will prevent that over-speed condition from happening.

That said, passing through/near singularity will make those axes work harder and fast than they would have otherwise. I don't have any information on how this might effect the overall lifetime of the axes -- I'm sure it will be detrimental, but I'm not sure it will be significant -- there are non-singularity operations that can make these axes work just as hard.

Wait, hold up -- you haven't tried plugging the serial mouse into the same port you're trying to use for communications, are you? Because if you do that, Windows Plug&Play will detect the device and "grab" that serial port, after which trying to access that port from KSS will cause a driver conflict.

When you have the Telnet window open, what do you see? Also (something I forgot), the Telnet window probably won't show anything for the serial comms unless you have TESTPRINT=1 in the SERIAL.INI file.

I'm also pretty sure that 3964R is not the protocol you can use in this situation -- it's a special Siemens PLC-to-PLC protocol for constant full-duplex operation. It's been nearly 20 years since I last had to do RS232 on a KRC1 to a PC, but I'm fairly sure that when I did, I used PROC=4 (XON/XOFF). And your PC-side application would have to be set to use the same handshake, of course.

Quote from pawankumargurav

For capturing screenshot ,

Firstly Connect Pendrive to USB slot provided at controller , then Double press Menu Key provided at bottom right of SmartPAD , current screen screenshot will be directly saved in the root folder of Pendrive.

Is this using OrangeApps' Screenshot plugin, or is this a built-in KSS function now?

...so, where is the command in the SPS that's supposed to stop your main program?

SPS and "normal" programs are parallel interpreter processes. They don't effect each other w/o specific commands. So your code, as written, will only stop the SPS with that message (which, by the way, is bad programming -- the SPS loop should never be stopped on Wait states, ideally). A Wait in one interpreter has no effect on the other interpreter.

There are ways to control the Level 1 interpreter from Level 0 (SPS), like using the CWRITE command to the $CMD channel to issue Stop, Cancel, and Select commands (basically emulating those same menu buttons you use manually in T1/T2). That's a bit crude, however. Another option would be to control the Level 1 interpreter playback speed by adjusting $OV_PRO down to 0, which will halt the robot's physical motion, but won't actually stop the program execution.

If you want to stop your program based on the air sensor, your best approach is probably to use Interrupts in the Level 1 program, as already stated. Probably the simplest way to do this would be to set up a Global Interrupt and arm it in your highest-level program.

They key question here is, what exactly do you want to happen if/when the air sensor input is lost while the robot is in motion?

Are you able to change this setting for other tools, like Tool 1, Tool 2, etc?

No, there's something wrong here. If you have your Base origin at one corner of the pallet, and then rotate A by 90deg, the pattern will be completely off the pallet, as if you had driven a stake into the floor through that corner, then rotated the entire pallet around that stake by 90deg. When you change the A value of the Base, the Base rotates around its origin, carrying all the points with it.

The fact that you're not having this happen means that your Base data changes are not being applied, for some reason.

On that image of the palletizing pattern, where is the Base origin, and what directions are the X+ and Y+ axes?

Not... really? You could get a rough idea, perhaps, if you could mount a dial indicator close to each axis center and "wiggle" the axis. But trying to separate out how much of the dial reading is caused by backlash, vs simple flex of the links, vs non-rigidity between the axis and the brakes (and then there's gravity effects on A3, and the counterbalance on A2)... you're only going to get a rough idea. And probably only detect really egregious amounts of wear.

I don't know of any spec for taking these measurements and comparing them to a baseline.

What is the result of INV_POS($POS_INT):Z1 in isolation? If any of the resulting Y,Z,A,B, or C values are not 0 (or very close to 0) they will have a skewing effect on your final calculation.

Well, there is no BAS initialization call at the top of the program -- there's only $VEL.CP settings, followed by E6POS motions. I suspect the "A1 Velocity" issue would be fixable by simply adding a stock "INI" fold at the top of the program, or by calling the module from, say, CELL.SRC.

1. What do you mean by "mirror" the Base?
2. Where is the origin point of the Base? At one corner of the pallet, or dead-center? Rotating the Base the way you are will not work unless the Base origin is dead-center (the pallet would also need to be perfectly square, not rectangular).
3. Rotating by 90deg each layer the way you are may not be a good idea. You could easily get into an unreachable condition -- is your initial "zero rotation" set up with enough buffer to allow the robot to rotate up to 270deg in one direction? Actually, looking at your pattern, it looks like you might be able to get the pattern you want by simply rotating to 0deg for the even-numbered layers, and 90deg for the odd-numbered layers.

Hm... I've never tried changing the settings for the Default load, only for Tools 1 and higher. I'm not entirely sure changing the "Tool 0" load is possible. Expert should be high enough, but you could try Administrator instead and see if that helps.

Are you pinging 192.168.250.16 from your PC?
What is your PC's IP and netmask? They must be compatible with the setting on the robot.
192.168.1.* is reserved internal robot network, so don't use any IPs in that range. Since you're using 192.168.*.* for your external network, all netmasks will need to be 255.255.255.0 in order to guarantee there are no collisions.
X67.* should be the correct place to connect. But just in case there is a wiring issue inside the cabinet, try connecting your PC directly to the KLI port at the top of the motherboard panel. You'll need to temporarily disconnect the cable that is already there.

KRC4s do almost everything over "virtual networks", which share a single physical network port -- the KLI, as Panic said.

The only caveat for using the KRC4 simultaneously as both scanner and device on ProfiNet is that you need to buy the higher-level PN option -- the "lower" PN option package for KRC4s can only act as a device, not a scanner.

RSI (without XML) works with any of the KUKA Fieldbus options -- DeviceNet, ProfiBus, ProfiNet, Ethernet/IP, InterBus, etc. Some devices made for these Fieldbusses aren't fast enough to keep up with RSI's requirements (certain cheaper analog-to-digital modules, for example), but as long as you watch the device specs when ordering, it's not a big problem. DN is probably the weakest of the busses, but I've had excellent results with RSI over DN in the past, on a small network (few modules, short overall cable length) running at DN's top baud rate.

One big caveat to RSI: it bypasses many of the robot's inherent safeties. The biggest example of this is that with RSI active, the robot can move at automatic speeds even when in T1. So the debug phase of any RSI project needs to be approached with extreme care.

As far as safety connections go: even if you're only using this for research, failing to implement proper safety is just asking to get someone hurt. On a KRC3, I think your only safety interface is the X11 connector, which is heavily documented. Briefly, there are various "relay" connections on the X11 that need to be wired to various safety devices -- for example, wiring the Operator Safety/Safety Gate inputs to your access gate in the safety fence will allow T1 operation at any time, but block AUT and EXT motions. Or you could have safety mats on the floor that kill the robot's motor power whenever anyone steps on one (standing in a dangerous spot between the robot and a wall, for example).