it also could be worse, you could also have been banging your head against it for a day with a frustrated boss behind who needs the robot for production, Then finally admitting your defeat and calling kuka service. Who then shows up plugs a connector in and out and is done in 5 min. That was a good day .
Posts by Leon
-
-
Variables are set in the main program after the program that is assigned to that table is finished. It is not that i want to manipulate anything during boot, that is what is happening now (or it happens during shutdown but that is hard to tell). after boot and initialization my flags are low, when the should still be high. The input never went low.
If i can detect a reboot, then my problem is solved. because then i can set flags high for the inputs that are still high.
-
So first i have to apologize because i know that what i am asking has been talked about before some years ago, but i cant seem to be able to find that topic again.
Robot: KR150L180
Control: VKRC2 running standard krc software kss4.97So simply put i need to set 6 boolean variables in the sps after a reboot (but not a cold boot, although it probably could not hurt).
The variables are declared in the config.dat file:
CodeBOOL Tafel_1_blok BOOL Tafel_2_blok BOOL Tafel_3_blok BOOL Tafel_4_blok BOOL Tafel_5_blok BOOL tafel_6_blok
And in the sps i reset them based on a input.
CodeIF NOT Tafel_1 THEN ;Tafel_1 is an input also declared in the config.dat Tafel_1_blok = FALSE ENDIF ;the rest of the variables 2 throug 6 are the same so to keep it short i will leave them out.
The reason why i have to set them is that during a reboot the inputs are seen as low when they are not, and so my variables get reset when they are not supposed to.
For some more background information:
These variables i use to block a table (i have 6 tables with different product around the robot) from being used. The input is connected to a limit switch on the table and detects if a product is present. So in my main program i can set the block variable to high after the robot is done milling this product, and when the product is removed the table becomes available again when a new product is put in.
So what happens is that in the morning after a reboot if there where still product inside they get milled twice and that doesn't always go well. I have to mention that the simple solution would be to not leave any product is the robot in the evening or take everything out in the morning, but people can be idiots and a robot always does what he is told. So i would put my money on the robot .
The inputs are connected through a device net module from Phoenix contact (ILB DN 24 DI16 DO16). i suspect my problems might have something to do with when the device net connection is made, but i am not sure.
-
Before you are going to cut holes in your roof it could not hurt to ask Kuka for a quote for a replacement balancing spring.
I admit it might be more of a challenge (or a lot more fun as you like to put it) to hang the robot on the roof, but i always want to have a plan B.
When you do decide to ceiling mount the robot, take in mind that a robot of this size needs a serious structure to be mounted to. Not just for its own weight but also the dynamic forces that it can create when accelerating en decelerating. If i am not mistaken in the robot specifications (you can download those from the kuka website) it should list the forces your mounting place should be able to withstand.
-
I am not really familiar with this type off controller. It is obviously not a standard controller. But maybe i can help point in the right direction.
- First to make things easier to diagnose write down the complete errors with numbers. the more information the better. some pictures could not hurt either
- Second i can see from the picture you have 7 drives in your cabinet which means this machine had an extra axis in the past. You would have to change the configuration and turn off the extra axis (maybe even take the drive out, not really sure about that one but there are topics on this forum about adding and removing an extra axis).
- Your first goal should be jogging the robot manually, i is not mentioned but i presume you cannot move the robot just yet.
-
Read the "Read first" topic and try again.
The only answer i can give now is turn your machine (whatever it is) on.
-
Well how are you sending the files to the robot?
I assume you are just dropping it on the hard drive through a network connection. I can tell you that that is never going to work. When a KRC2 boots all files are basically loaded in to the RAM memory. so changing anything on the hard drive wont work.
Look up the Kuka directory loader, that is what you need to get it working.
-
Watchdog errors can have several causes:
- Bad connection (from kcp to KRC, but also on the inside where that cable is looped through the esc card, and finally on the pc)
- Bad connection (from robot to KRC)
- Bad/damaged cable on the kcp
- Bad/damaged cable to the RDW
- Noise from other (badly or not shielded) cables.
I normally start with swapping out the kcp, but if that is not an option the only thing you can do is check all the connections and check if there are no other cables next to KCP cable that can give noise. Like a motor cable that is connected to a frequency drive.
-
Yes, in both software and hardware
-
Can you post your program? then it would be easier to see where it goes wrong.
-
I am sorry i don't. Whenever i get stuck somewhere i use this forum or go to kuka belgium myself. That can be a bit expensive but in my case it cost more money to have a not working robot.
But if your robot is functional there is no need to get kuka involved (yet). Although i will always recommend proper kuka training i can understand that if you want to use this robot as a hobby more than a actual job that training might be a bit expensive.
The basics you need to learn/do:
- Some sort of safety system connected (emergency button and safety gates).
- Robot mastered and correct mada selected (if your controller and robot havent been mixed then you should be fine.)
- A spindle mounted (with or whithout a toolchanger)
- To be able to teach a base and tool.
- make a simple program using the kuka inline forms
When you can do or have done the steps above you can start thinking about programming krl directly -
your almost there, you mention KR4 which isn't a thing so you would mean the KRC4 controller with possible a KR... robot running which software version? this all cleary in the "read first" topic that all this information is necessary. especially with specific questions like this.
-
Please read "read first" your missing information in your post.
Also that is not going to be that easy. so far as my knowledge goes there is no data saved to the drives. It all stays in the RAM memory.
There are options for writing files but i have no experience with that.
-
Well this will definitely keep you of the streets, because the most important thing you need is time.
My advice is start simple cut a square or round hole or something like that. and build up from there. the sample program i gave is for cutting a square box down to the right size, so this can give you a head start.
By the way, what do you want to mill? and for what purpose?
-
O that is close, i am from dongen (originally geertruidenberg )
I am willing to help, but i dont have the time to get onsite and do programming
-
It also helps to be specific on what it stopping you from writing KRL. In the expert programming manual there are a lot of examples of how a basic program is structured. So start there.
But i am in a good mood so i added one of my basic milling programs.
Code
Display MoreDECL FRAME box $APO.CPTP = 15 $APO.CVEL = 50 $APO.CDIS = 15 ;Tool 3 pakken zaag 60x1.5mm toolwissel(3,15) frees(12000) ;FOLD Overgang PTP{a2 -90,a3 0} C_PTP PTP{a1 -45} C_PTP PTP{a1 -55, a2 -120, a3 120, a4 90, a5 -45, a6 -60} ;ENDFOLD ;FOLD Snede 2 zagen doos box = {x 997.5,y 1126.5,z 1383.3,a 1,b -0.35,c -0.2} $TOOL=TOOL_DATA[3] $BASE= box PTP{x -350,y 0,z -20,a 0,b 60,c -90} $apo.cdis = 85 $vel.cp = 0.2 LIN{x -330} C_VEL LIN{y -330} C_DIS LIN{x 330} C_DIS LIN{y 330} C_DIS LIN{x -330} C_DIS LIN{y 0} C_VEL $vel.cp = 0.3 LIN{z 50} C_VEL LIN{x 100} C_VEL LIN{x -350} C_VEL $vel.cp = 0.2 LIN{z -31} C_VEL LIN{x -330} C_VEL LIN{y -330} C_DIS LIN{x 330} C_DIS LIN{y 330} C_DIS LIN{x -330} C_DIS LIN{y 0} C_VEL $vel.CP = 0.3 ;ENDFOLD LIN{z 50} C_VEL LIN{x 150} C_VEL LIN{x -350} C_VEL LIN{z -24} C_VEL $apo.cdis = 65 $vel.cp = 0.2 LIN{x -305} C_VEL LIN{y -305} C_DIS LIN{x 305} C_DIS LIN{y 305} C_DIS LIN{x -305} C_DIS LIN{y 0} C_VEL $vel.cp = 0.5 frees(0) LIN{x -350} C_VEL ;FOLD overgang PTP{a1 -65,a2 -120,a3 120,a4 0,a5 0,a6 30} C_PTP PTP{a2 -90,a3 0,a4 0,a5 0,a6 30} C_PTP PTP{a1 0} C_PTP ;ENDFOLD toolwissel(15,3) END
-
Please be specific, "says something about joystick error" is meaningless. i you want any help then post the full message with error code, and if there are more post all off them!
also buying a used machine without schematics is not the smartest thing to do, especially when it as old as this one.
-
well this is an interesting one. Fortunately we can rule somethings out.
In your case after remastering you could remove your offsets so a problem with the mount of the robot seams unlikely. And based on your mastering check data your mastering seems to be really drifting.
I can only guess at what the cause of this is, but in the only way i know that mastering can drift is when the robot is moved with the kabinet powered down or not communicating. The only time a have heard about something like this was with a robot with a heavy AOT and the brakes on A2 slipping when the robot was left overnight. But in this case it was only 1 axis and the drift was between 1 or 2 degrees so it was pretty obvious.
-
In general i only master my robots once a year during maintenance, but they also get remastered after big collisions or other malfunctions. Basically whenever i have someone from kuka over to fix anything i always ask if they can check the mastering. (i dont have a mastering tool myself).
The drift you describe seems not normal to me. How much drift do you have in your points? Can see a significant difference between mastering positions of for example a2 en a3?
are you sure that it is the mastering that drifts? not the mounting of the robot?
-
Guessing that you don't have any I/O installed? and no other communication cards in the PC, then basically your only option is Devicenet. so you need a devicenet I/O module. Look this up on the forum. You are not the first to ask this question.