That's very helpful information. Thankyou
Sounds like the controller is operating within acceptable parameters. Phew..
That's very helpful information. Thankyou
Sounds like the controller is operating within acceptable parameters. Phew..
Hi there,
I’d like to know if my KRC2ed05 fans and temp sensor are working within the correct parameters.
I’ve run a few milling toolpaths recently on my KRC2ED05. The files are around 2.5mb and the KR150 arm is running fairly swiftly at 9000mm/min for about 30-45 minutes. At random intervals, for around 5 minutes each time the big fans have come on during these cycles. I've noticed in particular if the 7th rotary axis is also involved that the fans are triggered more often.
My question is. Is this normal? If not what should i be looking out for or monitoring?
Many thanks
OK, I get it. So the main risk for me is not being able to control it properly due to the specific SW version etc. That's scary enough for me, so before I buy anything I try to arrange some time with the sellers to stay at their place and play around with the machine to see if I'm able to control it in the intended way.
Thank you all here, I'll keep updating later for anyone who is going to find themselves in a similar situation.
Running a test program at the sellers sounds like an excellent idea. That way you can check to see if any error messages appear and what they might be.
In the end I sourced an old KR125 and a KRC2ED05 controller which came with KSS 5.4 here in the UK. I bought it principally because I knew exactly where it had come from and had a good indication what it had been used for. Crucially the price was low enough that the risk was worth it. I feel like I got away with that one though. It could easily have turned out to be a total pain.
As it happened the sticker on the controller states it as a (v)KRC2ED05 from 2010 but for whatever reason I have not had the issues commonly found by others working with the VW variant. I suspect it had been modified or a later model. I did check also before purchase that it was not the safety version, which from my understanding is more complex to setup. The advice given in this thread is however the correct advice. Where possible don't buy a VKRC2.
In terms of CAD/CAM simulation software I went with SprutCAM principally to give me a solid all in one platform to learn on. I also intent in the future to run toolpaths directly from Grasshopper/KUKA|prc. For working with grasshopper I would check in with the Robots in Architecture Forum just to confirm with them the options your are looking at.
Its taken me more than a year to set my machine up to mill using all 7 axis. If I was doing this again I would first source a good kuka robot engineer who can advise on the setup or help with commissioning of your machine. I had setbacks most likely as I built the 7th axis from scratch, inc all the cabling and wiring. So far i've used feeback from here, the assistance of a regular mechanical engineer, assistance from SprutCAM UK and laterally and most vitally assistance from a robotics engineer specialising in Kuka robots. I appreciate however if your not an insider its not easy to find a robot engineer, where are you based?
Very useful advice thanks.
Just focusing on the rotation direction specifically. In order to change the rotation direction in MADA where should I specifically look.?
I see you have mentioned negating
$RAT_MOT_AX for that axis in another post. In my case is [7]
Will adding a minus to RAT_MOT_AX[7] work?
$RAT_MOT_AX[7]={N -23636,D 100}
--
$RAT_MOT_AX[1]={N -184,D 1}
$RAT_MOT_AX[2]={N -184,D 1}
$RAT_MOT_AX[3]={N -185,D 1}
$RAT_MOT_AX[4]={N 1284,D 11}
$RAT_MOT_AX[5]={N 108,D 1}
$RAT_MOT_AX[6]={N -1575,D 22}
$RAT_MOT_AX[7]={N 23636,D 100}
for that you need external axis to be synchronous and mathematically coupled. you may want to set tool and base. on older KSS base would need to be 17, tool can be any...
The rotary E1 has been set up to be synchronous and I did 4-point EXT root point calibration yesterday.
I ran a small rotary contour milling program and the arm and turntable working together earlier today. What I can see however is that the rotation direction of the E1 is the opposite of its onscreen simulation. This is why I should check the mathematical coupling by running a simple program to fault find.
Bear with me. This as you have guessed us my first time programming.
Ran program. E1 rotated but tcp did not follow?
DEF rt_test3()
DECL INT N
BAS (#INITMOV , 0)
BAS (#VEL_PTP, 20)
BAS (#ACC_PTP, 20)
PTP $AXIS_ACT
FOR N=1 TO 12 STEP 1
PTP_REL {E1 180.00}
HALT
ENDFOR
FOR N=1 TO 12 STEP 1
PTP_REL {E1 -180.00}
HALT
ENDFOR
END
at the top of the program declare own counter variable such as
DECL INT N
then replace I[1] with N in your code
Thankyou i'll try that out
Instead of I[1] try a simple Integer variable like CNT
My v-basic programming skills haven't extended to variables such as CNT yet alas. Obviously they will get better in a fairly steep arc from now on but for today I was hoping to get a quick result with a ctrl-v program...
Is this useful?
13 9 2054 “=“ expected
16 1 2110 Incorrect end of control structure
18 8 2054 “=“ expected
21 1 2110 Incorrect end of control structure
Hello,
I should test the ratio of rotating table using a TCP and reference on my custom E1 rotary turntable. I’ve done the 4-point EXT root calibration, I have an X marked on the flange and TCP ref tool in the spindle. I just need to run a small program to test if if TCP and E1 sync when rotated.
Loaded this test program below but Kuka found errors. My programming knowledge clearly sub par. I just wonder if anyone could provide alterations or an alternative. Test program.
Many thanks
————
KR125
KCR2ED05
KSS 5.5.12
—————
DEF rt_test()
GLOBAL INTERRUPT DECL 3 WHEN $STOPMESS==TRUE DO IR_STOPM ( )
INTERRUPT ON 3
BAS (#INITMOV , 0)
BAS (#VEL_PTP, 20)
BAS (#ACC_PTP, 20)
PTP $AXIS_ACT
FOR I[1]=1 TO 12 STEP 1
PTP_REL {E1 180.00}
HALT
ENDFOR
FOR I[1]=1 TO 12 STEP 1
PTP_REL {E1 -180.00}
HALT
ENDFOR
END
Thank you both for your insite and input. I'm going to take all of that away and systematically go through your checklists.
We found that A2 had the most positive dial gauge feedback. We could quite clearly see on the dial the topography of the v-groove so we will take that as a reference.
Obviously all of this would be much easier with an EMT/EMD but we dont have easy access....Unless anyone here wants to loan one to me
Yes we will avoid removing the gauge cartridges.
Our dial gauge definately doesnt seem to be engaging properly ona couple of the axis. It feels as if the depth of it is set incorrectly I'll revert to the pin and pen tip method for one or two of the axis and see how we get on with that.
Hi there,
When re-mastering today with a dial indicator we noticed that a few of the axis have indistinct feedback as to the exact notch centres. We know this because two of the axis are much more positive in their reading so we feel these are correct. Either our dial indicator is not penetrating deep enough to give us a correct reading or I think the notch or pins on individual axis are out of alignment, worn or anything in between. Unfotunately borrowing, renting or buying an EMT has proved fruitless so we need to carry on with the dial and pen tip route. As far as we can tell the dial indicator itself is working fine.
My question is how can we check the pins and notches on the robot axis. Is it ok to extract the pins and inspect the notches?
Many thanks
KR125, KCR2EDO5, KSS5.5
congrats... i am glad that you got it working but - it only got fixed now?
checking brake circuit polarity was mentioned months ago:
We had already reversed the polarity but an incorrect $BRK_MODE setting meant it was never going to work. Fixed the setting some time ago, reversed the cable just by chance. Sometimes Logic needs a bit of luck. Thanks for your help though
Display Moreif the brake is holding when motor is trying to move you will see exactly what you describe.
solution is to make sure that hardware and configuration are correct.
many things could be the problem...
bad motor
bad motor cable
bad wiring inside cabinet
wrong pmchannel value
blown fuse
bad KPS600
etc.
you will just need to check things systematically
Well i'll be darned. At the end of long day trying to get various parts of the Kuka working I thought I'll just try one more thing before going home. I'll switch the polarity of that brake cable, which I knew we had done before, right. Well that worked!! Brake releases, motor spins both ways, happy days..
Ok good to know. I'll have a look at this tomorrow in the workshop.
I just remembered I took screenshots of the tool and base setting as they are currently the other day. Needless to say neither are what I need, see my data above. No wonder my SprutCAM file wouldnt run as planned.
I will refer to the pages you suggested in the manual in the order Kuka suggest.
Thanks. I have consulted KSS_55_SI_en.pdf I just wanted to double check.
In my case as far as I understand it...
> calibration > TOOL > (this will be my spindle TCP numerical data)
> calibration > BASE > (will be my rotary table flange centre)
I can always run some non contact test programs at slow speed to evaluate
Thanks for your input. You provide us an invaluable knowledge base which we all really appreciate.
Depends on your KSS
Its KSS 5.5.12 as far as I remember
I just ran a simple .src file but couldn’t work out why the kuka was posed at a weird angle. It appears I/we have not set the tcp or base in the KSS. Dhoh!
I can see the XYZABC numeric data for the spindle TCP and the Kuka base in SprutCAM. As a default in SprutCAM I have the rotary table top set as base.
I thought before I have a go at this I thought I should ask the question. Q: which of the several calibration screens in KSS Setup menu would I input my TCP spindle numeric data and base numeric data? (Base being in my Sprutcam E1 turntable setup top centre)
Thanks
Spindle-4k
Tool overhang 0
X 243.1
Y 0
Z 68.44
A 0
B 90
C 0
-----
Spindle 3d model
Tool overhang 0
Translation X 68.44
Translation Y 0
Translation Z -243.11
Translation A 0
Translation B -90
Translation C 0
-----
E1 turntable
X 1800
Y 0
Z 640.36
A 0
B 0
C 0