Hi TMK_M
i am having the same problem - did you end up solving your issue?
Posts by jschmidt
-
-
SkyeFire thanks for chiming in!
If you look at both screen images from the first post you can get the whole list of errors but I've just reattached them to this message.
Maybe I'll just take the plunge and try a new motor cable for the E1.. Yesterday I had to swap out the KCP because I suddenly got a WATCHDOG error so it's definitely possible. -
Martin84 : attached are the axisconfigurator pictures. Thanks for the help
panic mode : thanks for the input!
I'm skeptical that that problem is with X2 motor connections because I re-purposed that connector from the old KSD that was already in there and working, and 3-phase motor wires don't change in configuration between 2 motors, right?
I've switched around the x1 connections (between + and - to test that the direct current is moving in the right direction) to no avail.
Any other ideas? or any corrections to my logic? -
-
-
-
Hi Martin:
Thanks for the reply.
Yes we are using a 7th axis. Single-axis positioner (synchronous) with a KUKA MGU. KSD-32The controller that we're using originally came with 2 external axes, both with SBM2, KSD-8.
I thought I had removed all of the hardware that went with those, but I'm just learning that there's a breaker that i missed in the southwest corner of the cabinet.
maybe that could be a reason for the quality input error? -
(KRC2ed05 Controller)
(KR150-2 robot)
(KSS V5.6.8)
CI3 Tech BoardHello,
having trouble with the ESC safety circuit (error message: 310 safety circuit for drives not ready)
Attached is a picture of my x11 and the bridging diagram I used. I'm wondering specifically about the Safeguard that's connecting Pin 7 and Pin 25. Does anyone know how that translates into hardware?
This is a KUKA stock controller.thank you in advance for your help!
-
gotcha, okay thanks
-
(KRC2ed05 Controller)
(KR150-2 robot)
(KSS V5.6.8)Hello the leg ,
sorry to pirate the thread but I am having a similar issue (quality input error on KCP, KPS and ESCC nodes in ESC diagnosis).
Would you mind translating your bridge-connector x11 corrections?
I only know the bridge diagrams as Pin1, Pin2 etcperhaps youre referencing it like a grid system of rows and columns..?
-
SkyeFire @panicmode
Okay, I sort of have an update here.
Everything seems to be working correctly, but I'm not sure how.
I didn't add a mastering gauge to the table or change the process of how we are mastering it.I've attached an image of the robot milling the (also attached) .src program with the external kinematic system.
Offline programming: Rhino3D (CAD) and KUKA|prc, the plugin for grasshopper (CAM)This started working about a month ago when a software developer from Octopuz came to prove out the Octopuz CAM software on our robot. Long story short, Octopuz got their software to run a program accurately on our robot/table set up, and then they left, and I ran the attached program (octopuz.src) on the robot without changing anything in it, and it suddenly worked. It hadn't worked before Octopuz came.
The Octopuz employee said it was a matter of changing from "dynamic frames", and that the problem was that the Root Point frame on the table and the $TOOL frame on the robot flange were following the same angle, and he changed it so that they were following separate angles.
So far, I've found this post (https://www.robot-forum.com/robotforum/kuk…nal-axis-types/) to be sort of helpful, but I still dont understand exactly how to separate the frame of the robot flange and the frame of the table flange, or really what that means.
I've procrastinated posting an update on here because I don't really understand why the problem is solved.
So, any insight as to what this fix entails is greatly appreciated! Thank you! -
SkyeFire : thank you for this explanation! I just tested out the $RAT_MOT_AX through your process and the table only turned about 15 degrees.
Looks like I'll need to iteratively adjust the variable like you said. Unfortunately I'll be out of office for the next 5 days, but when I get back and correctly adjust it, I'll report back.
Thank you again for your help! -
SkyeFire : ah, hold on. I'll check $RAT_MOT_AX again and get back to you. That variable setting was the work of another employee.
-
SkyeFire : so even if I unmaster and remaster all axes (robot and E1) and not just E1, that difference between new and previous masterings for E1 will feed into the position error? If that's what you're saying, that is fantastic news.
And yes, I am 99.9% confident that kinematic integration has been carried out successfully (per the KUKA manuals, this forum, KUKA tech service, and the robotsinarchitecture.org forum)panic mode: okay good, last night I left a message with KUKA asking for a quote on a replacement mastering gauge cartridge and notch. I've seen in past forums that it's not too expensive. Tried to mine the mastering notch out of one of our stock robots to no avail..
-
Hello:
I have a question about mastering a homemade external axis with a KUKA motor.
Robot type: KR150 L150
Software Version: KR C V4.1.6 SP 3
Control cabinet: KR C2Our goal is to mathematically couple the external axis and the robot. We've built a 1-axis positioner external axis. We took a motor for an A2 axis off of a KR150 L 150 and are using it for the motor of the external and then built our own mechanics around it (photo attached). For mastering, we have not installed any mechanical zero or consistent home position: we simply go under Setup > Master > Dial > External Axis 1 > *move the external axis a little in the negative direction* > softkey "Master". So, every time that we master the external axis, it has a different home position then it had the last time it was mastered.
I think it's because of this process that we're getting a huge error (around 700 mm) every time we try to do a Root Point calibration. To bypass this, we've just been calibrating with "Root Point (numeric)" by placing the TCP of a calibrated reference tool at the Root Frame of the external axis and displaying TCP position with the $POS_ACT variable, but I've read that that's not very accurate. Our programs are not running per the simulation supplied by offline programming (Rhino and KUKA|prc), and I think it's because we're not mastering the external correctly.
So, I'm wondering what to do next on creating a home position for the external. Since it's an A2 motor, does that mean the home position can't just be anywhere (i.e., does it have to be the same as the home position of the robot A2 axis relative to the motor)? Since, it's a KUKA motor, is it better to remove a mastering gauge cartridge from a stock robot and then install that onto our external axis, so that it can be mastered with an EMT tool?
Please let me know thoughts, thank you.
-
last 2 pages of Setup-> Service-> Config External Axis
(forum seems to not be able to post whole zip file. Let me know if you want to see the other pages of the config menu)
-
attachments (forum wouldn't post reply with them)
-
Hello:
I'm using Rhino 3D and KUKA|prc (the plugin for Grasshopper) to generate the code.
The code knows the root point of the external kinematic and the code supplies it with frames for the linear movement. I can attach images of the script if that would help?
I've attached the .src file created by the KUKA|prc code. I've also attached an image of a general setting you can use in KUKA|prc to give the program the flange position, but in my experience it hasn't had an effect."What is the robot's kinematic configuration with E1?"
I've attached a zip file of pictures of the configuration on the controller completed under Setup-> Service-> Config External Axis.
The only changes we made were to the last 2 pages of the menu:
$EX_KIN: ET 1 set to EASYS
$ET1_AX: TR_A1 set to E1 , name of transformation was given the name: turntable
$ET1_TPINFL: has the x value set to the distance from the centre of the turntable to our reference mark (the edge) on the turntable -
Hello!
Control type: KR C2
Robot type: KR 150 L150
Software Version: V4.1.6 SP3I have not been able to solve why my KR150 will not follow it's programmed path. I have incorporated an external kinematic (turntable) and when running a program for it, the end effector (1/2" flat mill for milling) seems to be following the path of the E1 axis (linear movements that circulate) rather than its programmed path that shows up in the simulation (basically staying in one spot and moving vertically with every contour step).
At first, I thought this was because there's a wrist singularity at the beginning of the code, but then I fixed that and still the same problem.
This also happened without the use of the E1 while running a program months ago (the end effector ran in a circle instead of following it's path), but I simply changed the code by drawing one connected path for it to follow continuously, rather than relying on the robot to know how to move through a list of contours. That fixed the problem.
To me, it seems like there's a disconnect between the robot's position and it's programmed position. It's not able to follow a program unless the program simply asks it to trace a line, which doesn't really require the robot to know much about it's actual position in space, right? I feel like this means that it doesn't actually know where it is and where it's end effector is in space. I just don't know what would cause that.
Also, the robot is mastered with an EMT and external kinematic is mastered with a dial and the root point of the turntable has been calibrated. The reference tool (1/2" flat mill) has also been calibrated with XYZ 4 Point.
((side note: I've received the *attached* Cross3 error twice and had to solve it before I could open KSS at the time. The first time I solved it by replacing the RAM, and the second time I solved it by replacing the Motherboard. Today, I am receiving a Windows error with the same syntax, and it goes away after rebooting a few times, and I'm also able to still use KSS behind the error message. Could the Cross3 and this current "<unknown>" error be linked? Is it possible I have to reinstall Windows? And in turn, could that be causing problems with the robot position?))
-
Hello:
The external axis has already been checked by a coworker through writing a test program in KRL manually, so I think we're good there!
I have mostly resolved the issue and you're correct, it was largely problems with the Grasshopper script.
Now, I am able to get through about the first 30 motion blocks of the program before receiving the error message "software limit +A6 out of range" or something like that, and it is because A6 is spinning around in full circles during those 30 motion blocks when it should only be pivoting between -20 range and 0. Again though, I believe this error is something that needs to be resolved in grasshopper as well.