Posts by DannyDJ

Quote from szkyrp

do you have any codenprogram hownton to do. I'm a beginner and I really don't know how.

Did you read the post that Skyfire posted? In that post you have also example of code how interrupts work.

There is a Virtual Pendant software for jogging the real robot from the computer and operation mode change.

Office Light software is usually used together with KUKA Sim Pro as a part of simulation software.

Quote from Plc_User

In the application, in the sps the software limits of axis E1 are now written in the submit program :
f.i. $SOFTP_END[7]=180.0, $SOFTN_END[7]=180.0.
The writing is always done (no if statement).
We got reply of custommer that sps is sometimes stopped since we did last changes to the robot.
The changes were not just the software limits but also other code.
We did not get the ability yet to inspect the logs of the robot for diagnosis.
Does anyone know if writing the software limits of an axis constantly in the sps is no problem for the controller, or if it could be the cause for the sps stopping?
Until we get access to the controller it would be good to know if this is allowed.

Display More

Hello, if in the sps is used $POS_ACT, $TOOL or $BASE they in some cases can stop sps from executing. For example when robot is turned on, those variables at boot have undefined values(you can see that by ? mark in tool and base window). Software limit switch you can also write at the start of the robot program, if you don't need to constantly overwriting the same value over and over again.

Or maybe by using C3 bridge Interface or KUKA Var Proxy and send the data directly from his C# program.

If you have KRC4 you can also use files to read data into KRL program, for example also point data(check CREAD,CWRITE manual).

There is a folder C:\KRC\ROBOTER\UserFiles but i think it is limited to 10MB.

But one can use also "krl_mount" function to access network drive and read data from there.

For example one can make E3POS MyPoint[20] point array in KRL and read all points data from 10MB file by using only 20 points for example.

Usually value of inline points in .dat is stored with X prefix. So if you want to use values from inline form point P9, one should write XP9 in program.

LIN XP9:ofset

Hello, you can open the file $machine.dat in STEU\Mada\ folder in Workvisual and edit the signals directly in the file and transfer it to controller.

Quote from branislav1991

Konekotor is good. As i told, I have instal another PC, and PC is working fine.

DC 24V supply is ok, a have measure its output.

Your answers are really confusing, you said the other PC works on other controller, but not on broken controller(at least what i have understood), and there is no picture on pendant on the screen.

For PC power is supplied from KPS600 on X7(pins 7,8) connector over fuse F15 that is why i asked according your problem description how did you confirmed DC supply is OK for PC.

So if PC works on broken take also pendant from working controller. But how did you then confirmed that PC works if you still don't have picture on pendant . I'm out and hope you fix what ever problem you have.

Quote from branislav1991

I will check connector. Yes, I swap PC. PC is definitly working on other robot. I have cheked fuses, they are OK. DC supplay is OK. I have asked before, could be problem with supply for drives?

So have you measured the voltage on X961 connector when you say DC supply is OK? If there is voltage on X961 the other PC from working controller should start also here unless when you plug the X961 in the PC you somehow detach the pin out of connector or is oxided like Panic said. This controller was working OK before this problem?

Quote from panic mode

maybe KPC PSU is not on. if it is on, there will be 5V or red wires and about 12V on yellow wires on hdd/cd power connectors.

I also was thinking that, and he said he tried other PC(hopefully tested), KPC PSU is inside the same housing, so if other PC is working on other controller, it should boot also here if there is 27V on X961 connector.

Quote from panic mode

i thought abut the same but discarded it. if CMOS settings were lost, there would still be some initial info on the screen along with errors. also TS stated that he swapped entire KPC. so i would suspect issue is elsewhere. probably power to KCP or KPC is not on (blown fuse, poor connection...) or KCP background light is gone.

Yes i agree,i missed the part that PC was exchanged(hopefully with one which has been checked on working controller),but i had also many times issues where just PC wasn't turning on, even if there were power on the PC power supply connector. If BIOS setting are cleared, sometimes motherboard still wants to be turned on (there is no screen on pendant) with shorting PWR_ON jumper just like a regular PC with power ON/OFF button. If everything else is checked and turns ok, i would still try this. Of course if this other PC is working on other controller OK, then issue somewhere else... checking power supply for voltage etc...

Hello, did you tried and short POWER_ON jumper on the motherboard? Sometimes BIOS on the motherboard is cleared and KUKA PC doesn't start by itself then. After that KUKA settings needs to be applied in the BIOS.

1st,2nd. You should post the whole code from the sps. What doesn't work? The $OUT[2] doesn't get false when robot is not in home position?

Or the sps is too slow overriding the signal?

In my case usually workers are trained to work with GripperTech only for gripper actions. In that way the output is never set to TRUE directly. From the IO display they cannot set the ouputs to TRUE when they are logged by default as the operators and they can only work in that user group.

For example if you don't have GripperTech you could use the variable overview windows or Variable single window, define new bool variable for locking and let the workers trigger the variable from that window instead of letting them directly switching the outputs on and off.

Don't let them trigger the outputs directly, they can also trigger some other outputs which they shouldn't.

Also keep in mind that $IN_HOME(1-5)signal has +-2 degrees tolerance range for each axis, this tolerance can also be adjusted if needed.

Hello, one way to safeguard from accidentally releasing the gripper from falling down anywhere in the cell is to connect robot's unlock gripper position to the unlock signal.

For example you can make some $IN_HOME(1-5) signal, and when the robot is not in that specific unlock gripper HOME position, you override the unlock signal, when the robot is in $T1 or $T2.

Also with option above one can also rewrite a bit GripperTech code in the sps, so that operator gets Dialog message to choose from("Do you REAAALLY want to unlock the gripper?Yes/No") before actually triggering the unlock signal.

And also if robot is connected to the PLC and all the signals are going through the PLC, there can be also a safeguard code made by using $IN_HOME(1-5) or any other position locked signal along with $T1 or $T2 mode.

This would be handy tool to have . Yes the one from KUKA is quite big.

Quote from SkyeFire

So, I had the collision problem again. This time, during an automatic run, because the part the robot was trying to pick had a damaged upper surface and the robot "hit" it maybe 2-3mm above the programmed position. And again, jogging the robot clear was impossible, and we had to loosen the mounting bolts, then re-teach everything. There has got to be a better alternative to this. The Agilus seems really hypersensitive to this kind of situation, compare to most KUKAbots I've worked with over the years.

A few observations on the KRC5Micro and KSS 8.7.3:

1. Going into EXT mode, the drives came on automatically, without $DRIVES_ON being pulsed. The only thing that seemed to break this behavior was if the robot suffered a safety fault (E-Stop or Operator Safety) while in EXT -- after that, I had to pulse $DRIVES_ON to get the motors on again, or go back to T1, get the motors on using the deadman, then switch back to EXT, after which the drives would be on automatically. AUT seemed to behave the same way, from what limited experimentation I had time to do.

2. Tool and Base data don't seem to be the sole province of $CONFIG.DAT anymore. I had a problem where my WoV Project got corrupted, and was hand-loading files from a backup into the robot (couldn't use Restore for various reasons), and ran into an issue when I loaded $CONFIG.DAT -- the robot threw a fault that I failed to write down ("consistency error"?), and the values shown in the Tool/Base configuration menu did not match what was in the restored $CONFIG.DAT. I had a serious time crunch, so instead of digging into the issue, I just hand-typed the values from the good $CONFIG.DAT into the Base/Tool menu, and that fixed things. But I'm wondering what's changed in the way "custody" of TOOL_DATA, BASE_DATA, and LOAD_DATA are handled.

I will say, though, the new Tool/Base config menu is nice, and offers several bells&whistles that I've been wishing for (and ABB and Fanuc have), like moving to the recorded points that set up the Base originally.

3. The default SLIN/SPTP motions in the ILFs are a bit... odd. Most of the time, they worked perfectly well, but I ran into some strange hiccups once or twice, especially with CONT motions. One particular example, I had a SLIN leaving a Pick position, followed by an SPTP to move clear of the station. And if I set the SLIN to CONT, the robot would "bobble" at the corner -- basically, move to the end of the SLIN, sort of "jiggle" a bit (as if the CONT path was being calculated as a small ~10mm "knot" at the transition), then continue into the SPTP. A few other CONT motions would act like non-CONT motions (no ARP-breaking logic in between the motions), or would have strange "pauses" mid-path. I didn't have any time to dig into it, so I just made the motions that were behaving oddly into non-CONT and kept going (no cycle time concerns on this robot).

I also had some programs that mixed ILF S-motions with hand-coded S-motions, and it seemed like I got some odd blending behaviors sometimes using C_PTP or C_DIS to blend into an ILF S-motion. Probably something I was doing wrong, as I really don't have much hands-on experience with the S-motions, but as I said, I didn't have time to really dig into it.

Display More

In my case we have centering pins in the grippers and in the base of the robots, so no reteaching of points was needed afterwards.

As i can remember, even watching the increments and position values on the axes on actual display didn't show any robot movement, while trying to jog out of this position. But i agree with you, there should be some nicer way to fix this problem, rather then dismounting grippers and robots(maybe opening the motor brakes manually), just can't imagine dismounting and mouting the bigger and heavier robot. but there at least at the end you can use release device on motors on bigger robots, but even that i think it is not possible on a new robot like IONTEC.

Quote from SkyeFire

Okay, stupid question: I managed to jog my Agilus into a collision that I can't get clear of. Spending 10 minutes just jogging in the opposite direction produced no motion -- the torque fault trips before I can even get 0.01mm of motion to relieve the pressure.

I've never had this problem with the Big Iron -- they would always jog clear... eventually. But this little bot is completely stuck. Any special tricks for resolving this on a Agilus?

Hi, I had the same problem once with Agilus robot, somehow due to tight and small space in the cell i managed to jog the sharp corner of my gripper into robot's arm. At the end i had to detach the gripper in order to jog out of this position

Or try RDP like in this post:

Thread

Remote Desktop on KSS 8.6

Hello

Is there any differences between remote desktop connection procedure on KSS 8.6 and KSS 8.5?

I'm trying to connect the PC via RDP to Kuka controller with KSS 8.6.7, wich has the default IP 172.31.1.147 through the KLI interface.
So I can access the shared folder on Kuka from my PC, I can ping it, I can connect it with WorkVisual, but the RDP is not working. Maybe there are some additional settings (except IP setting of course) on Kuka wich has been added in 8.6?

I also have the robot with KSS…

RainerFord

Sep 16th 2021

or open port 5900 and use VNC

Keep in mind that jogging the robot like with Virtual Pendant is not possible with above options.

Go to the Visual Componets webpage and visit their Academy, there you have many tutorials which are very handy in how to do pyhton scripts for your components in simulations.

https://academy.visualcomponents.com/

DECL INT pieceCounterz

pieceCounter = pieceCounterz

You cannot assign value to inputs...

You should write "pieceCounterz = pieceCounter", writing the value of the inputs to the variable pieceCounterz

and "pieceCounterz=pieceCounter*6"