Robot software is in Spanish... After changing the WoV software to English I can now read the help information... 
At the end I've also found where the deploy is... it was easy to understand that... I can't do it... because when I press deploy nothing seems to happen a small dialog (DEPLOY PROJECT) appears with "Zelle" written on the left pane... when I press NEXT nothing happens...
Hello all,
I've just received a Brand new KRC4 robot and it looks really nice.
I've managed to install workvisual and I've seen that all the help is in German... 
Now I've been able to connect to the robot and to see the program tree (KRC\R1\Mada, Program, System, TP...).
I've started doublé cliking on a program I've created in the SamrtPad in order to edit it and it is really useful to edit the program there... the only issue I'm facing is that I don't know how to send the modified code to the robot...
How can this be done?
Thank you in advance!
Our customers use the external display, mouse and keyboard extensively and the VNC solution (which works well on krc2) is slow.
I've not tried it in the krc4, I'll do it and let's see what happens.
Thank you for your comments!
Sent from my BlackBerry 9300 using Tapatalk
And see the image in both displays at the same time?
I'm about to start my first KRC4 robot and till today I've used extensively the possibility to attach an external display, a keyboard and a touchpad to the robot controller.
I've been told that it won't work at the same time... is that right?
Can I get it to work somehow?
Thank you in advance!
Hello all,
I've been lent a robot to make tests and I'd like to know if I could install expert-tech into it.
The lent robot is a KRC4 and the techs I have are from KRC2...
If that can work perfect if not I'll call KUKA to ask for the new software files...
Thank you!
If your robot is not HA, then you can even have 8mm or more of error regarding the software and the hardware positions...
You can get a HA robot by a difference between 3000 or 6000 € (in Spain).
You caould recalibrate the robot by yourself but the process will be much more expensive.
The advantage of that external calibration is that you can calibrate the robot hardware, TCP, and bases and get at the end those 0,3mm...
Without that a Kuka robot is usually better adjusted tan an ABB one at the beginning, but don't expect great precisions without calibrating it.
Of course, if you need to make manual trajectories this is not a must as you are correcting the robot error automatically...
If you've got a HA accuracy robot you should have smaller than 1 mm errors in all the working range. (Not a constant error but at max 1 mm).
That will be possible if the bases and tcp's are correctly done.
You can always do the mastering, some times transportation ends with small errors that a mastering solve.
You could try to make the tcp by calculus. When your robot is precise sometimes is even better doing it that way.
If everything fails, you can always call kuka tech support (if you have the robot under warranty) or try to contact metrology companies who could recalibrate the robot for you.
Regarding this last point, the HA robot is calibrated to himself, therefore any external adjustment in the base, tcp, artificial vision, sensors... Can decrease this precision.
With a HA robot you can be sure the precision will be under 1mm.
If yoiu recalibrate it you can achieve 0.3 (which is the best I've ever seen with a robot).
Hope this helps!
Sent from my BlackBerry 9300 using Tapatalk
What 0lda says is correct. ABB robots have a battery set in their base to remember the robot arm position during shut downs. Typically this battery can last around two normal usage years.
What "kills" faster that battery is having the robot without electrical power (holidays and so).
It's really easy to change, but you will need to remaster the robot.
Good luck!
Sent from my BlackBerry 9300 using Tapatalk
Eureka answer is perfect, As always, I just wanted to add that you could use them also for testing purposes.
Sent from my BlackBerry 9300 using Tapatalk
I'm far away from the computer and I don't have any code now to check it... But I would use connect (I think it was the way to start an interruption) to check the state of one of those digital inputs. You should use that interrupt (which at the end is a function that gets executed as if it was multitask) to check the states of those inputs and activate the outputs accordingly...
Sorry not to be able to give you a better answer but from the phone and without manuals or old code to check...
Sent from my BlackBerry 9300 using Tapatalk
Probably your best options are:
1. Use interrupts to detect any input value change. Once you are inside the interrupt handler check both signals and react in consequence.
2. Use your plc (if any) to do this output logic.
Hope this helps!
Sent from my BlackBerry 9300 using Tapatalk
Can't you simply choose *.* in the file pattern and then write the .mod by yourself?
I'm using ultraedit and never used notepad++ so I can't be sure of that, but at the worst, you should be able to store it as any mime type and then rename it.
Sent from my BlackBerry 9300 using Tapatalk
I can think of two solutions:
You can use the submit program (sps.pro) to do that for you (which is not the best in terms of speed but it is the best in terms of flexibility).
You could also put an extra software layer there by using a beckhoff controller and do that inside the PLC logics.
Both options are very similars, but the first one is free.
Good luck!
Sent from my BlackBerry 9300 using Tapatalk
In theory it is not possible to decrypt those files. At least this is what ABB explains and the only reason why somebody would spend money on that encryption software.
Sent from my BlackBerry 9300 using Tapatalk
Any links or advices on how to avoid problems related to the Gimbal lock?
I've been calculating the orientations using quaternions, and given that I'm getting much better results than with Euler angles, but anyway I'm getting strange behaviours when facing a singularity (A4,5 and 6 aligned).
Any examples, manuals, interesting tips... to handle that?
Thank you in advance!
The rumors you've heard are true: robots are repetitive, but not precise.
In any Brand you can get more precise robots by paying a little bit more (high accuracy, absolute accuracy...) those “ultra-precise” robots can get typically precisions of 0.3mm (this is the best you can get and the bigger the robot is the worst precision you’ll get).
Due to the specific construction shape of the robot which all the axis are rotary, the robot can't be more precise than that.
There are external companies that calibrate robots. They are expensive and keep in mind that you won’t get better results than 0.3mm.
When you teach the points, you are "solving" the precision issue automatically as the robot don't mind if the real position versus the software position are correct/equal.
Anyway, I must tell you that with KUKA I've got very good results with normal robots. i.e. it's quite normal to program a robot in our factory and send it to our customer and need to retouch a lot of points to adjust the part program. With KUKA this has been minimized a lot.
Don't think on a constant formula to solve the error issue, the amount of error is not constant in the space as it depends completely on the robot gearboxes and arm torsions, which change depending on their position.
If you need a lot of precision teach is the best, in the other hand, you can always use a correction array in which you can allow the user to apply a correction in a specific array position and before making any movement add the user correction to the calculated point:
calcpoint [x] = calpoint[x] + userarray[x]
If userarray is 0 then no addition will be performed and so…
Anyway, test it and take measurements, probably you won't need this amount of precision.
Good luck!
I don't remember it now, but probably you will need to perform a cold start to activate the value modification.
Good luck.
Try to edit the /KRC/ROBOTER/INIT/MEMCONFIG.INI file.
Modify the variable "miniumal physical page".
Initially that variable value is 10.
I don't know why, but KUKA tech support once told me to update it in steps of 10 units.
So the next step should be 20, the next 30...
Try it and come back with the result 
You can always use a CIRC_REL, just this afternoon I've been having problems with the very same thing until I've found this:
http://webcache.googleusercontent.com/search?q=cache…3&hl=en&ct=clnk
check it, it is in the roboterforum (which is almost the same than this one but in german and only available for germans I think). That is why it is from google cache... because I've not been able to reach it...
All In all this should help you to calculate easily the circle.
Good luck!
Thank you for your answer Skyefire, I've started again to check the program.
Note: believe it or not in the KUKA tech support told me that each IF clause stops the flow and that therefore I needed to put a continue just after each one.
Apart of that I've found some logic on the problem:
The second function can be called in two different situations: with the robot in movement or with the robot stopped. This made me to design the logics in the following way:
IF ($PRO_MOVE) THEN
TRIGGER / DISTANCE...
ELSE
PULSE
ENDIFI've put a halt just after the TRIGGER/DISTANCE (to check if the program was going there or not).
The external code (the one who calls the second function) is something like:
LOOP
PTP 1
Function2
PTP 2
PTP 3
ENDLOOPMy surprise has been big when I've seen that some times the robot got stopped at the halt and that sometimes it was not getting stopped (therefore the normal PULSE was being called).
That's really strange, I've finished solving the issue putting a simple CONTINUE before the normal PULSE, but that is (at last) strange.
Pointing me to the manual has been great, I've noticed that asking for internal/system variables stops the movements, therefore I've also put the continue before the first IF clause (where the $PRO_MOVE var is being checked).
At last everything will work as expected.
Thank you all for your help and comments.
