Messages

Okay, I sort of have an update here.
Everything seems to be working correctly, but I'm not sure how or why.

I've attached a working .src file program and a video of the robot and table running the program.
The program is fundamentally the same as the example posted here: http://forum.robotsinarchitecture.org/index.php/topic,822.0.html

This started working about a month ago when a software developer from Octopuz came to prove out the Octopuz software on our robot because we were thinking about buying a license. 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, when it hadn't the earlier that morning 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.

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!


P.S.  $ET1_TA1KR = (X 0.0, Y 0.0, Z 0.0, A 0.0, B 0.0, C 0.0), and $AXIS_DIR[7] = 1

Update on this issue: the two 12 volt batteries in the robot controller were not fully charged and therefore not saving mastering data like they are supposed to. We replaced the batteries with two new ones that combined to output 24 volts and the robot has not lost mastering during power down / power up since.

Hello @jamespandit:

Sorry for the delay here, didn't realize that you had commented.
I've gotten this Cross3 error a few more times since this post, and most of the time the fix is:
(1) reset BIOS settings to "KUKA Default" values (2) replace the CMOS battery in the Motherboard of the PC of the Controller

To reset the BIOS, power down the controller and then turn it back on.
- As soon as the first black screen appears, there will be a message that says "hit DEL to run set up". This is the black screen that pops up before Windows starts. Hit the "DELETE" button as instructed. This will take you to the BIOS menu.
- Once you're in the BIOS menu - and the structure of the BIOS set up varies between hard drives - go to DEFAULT > KUKA > LOAD KUKA DEFAULT VALUES? > YES.
- To exit BIOS and resume boot up hit ESC > SAVE CHANGES AND EXIT > ENTER

Hopefully this helps! Feel free to private message me with further questions so that I'm notified of your response.

@umaojha: could you explain what you mean by your comment? Step by step programming?

and thank you @singline! I've recently started an edX course in Python.

@umaojha: could you explain what you mean by this? Step by step programming?

and thank you @singline! I've recently started an edX course in Python.

Thank you for all of that information!
I will make some more decisions on my end and then move forward.

Hello!

I am looking for suggestions on a scripting language to learn that can be used with Grasshopper and possibly with KUKA|prc. I was thinking Python, but only because I'm familiar with the name from my peers in architecture school.
I've also met someone who used Visual Studio and Microsoft Excel to completely bypass the KSS and program the motions for A1-A6 individually. This seems extreme, but he was not having the problem that I'm having, which I believe is a loss in translation from the source code to the KSS.

I'm choosing to branch out of KUKA|prc because of a problem that I'm having with the A7 external kinematic: when running a program that uses A1-A7, the robot flange moves in a circular motion rather than its programmed path (http://forum.robotsinarchitecture.org/index.php/topic,824.msg2130.html#msg2130)

I'm neither an expert on KUKA|prc, Grasshopper or my KR 150 L150 robot, so I'd like to circle back to learning the fundamentals of how to write a program rather than trying to solve the problem through the very polished KUKA|prc. I feel that because I don't actually know how to program anything, and I just jumped right into KUKA|prc after my only prior experience with "scripting" was Grasshopper,  I'm just making uneducated guesses at solving this problem.

So! I just finished a beginners course on JavaScript (to get my feet wet) but I'd love some recommendations on which language would be best to move forward with.

Thank you in advance!
All recommendations welcome!

Oh wait, wouldn't it be A at 90?

Hello!

Thank you for the reply!
The $ET1_TA1KR value is : (X 0.0, Y 0.0, Z 0.0, A 0.0, B 0.0, C 0.0)

Attached are photos from the front and back. The KUKA motor we're using for our turntable was originally an A2 motor.
Because of the change, it would make sense to set C ~ 90.0 (or ~ 180.0)

Hello!

This is is a bit of an add-on to a previous topic ( http://forum.robotsinarchitecture.org/index.php/topic,817.0.html ), but I am still struggling with the issue of the robot not following it's programmed path. I've attached a video, the Rhino and .gh files, and the final .src file.

Control type: KR C2
Robot type: KR 150 L150
Software Version: KSSV4.1.6

In this video, it shows the flange almost following the LIN movements that the E1 is following, but in the opposite rotation direction. This is instead of following the robot flange path in the simulation.
I have encountered this problem before the integration of the A7 axis as well. At that time, I was trying to mill a curved surface out of a piece of foam, and I initially just gave KUKA|prc contours to vertically move between and mill. When running the program, the flange did a very similar circular movement to the one in the video, rather than its simulated motion. I solved this problem by connecting the contours of the curved surface into one closed polyline, so that the flange just simply had to trace the path (creating a toolpath essentially) and that solved the problem.

I don't really see how it would be a KUKA|prc issue - because the KUKA Core Analysis is all clear - but I'm posting just to get another check that it is not an issue of the .src file that I am inputting.
- I've gone through all of the variables in the machine.dat and made sure that it was the correct machine.dat for the robot type (ref http://forum.robotsinarchitecture.org/index.php/topic,511.0.html)
- To the best of my knowledge, A7 is configured correctly.
- The tool is XYZABC calibrated and the same XYZABC values are entered in KUKA|prc and on the robot.
- Robot is mastered with EMT and A7 is mastered with a dial.
- Root Point data for the A7 was entered numerically by positioning the TCP of the reference tool at the center of rotation and displaying $POS_ACT, and then entering in those values for the Root Point.

Any ideas are appreciated and welcome!

I've been updating our Call Center Engineer @ KUKA on this process as well, and he is saying that:

   - Our serial number indicates that we are operating a KR 125-2
   - But our $robcor.dat from the archive that I sent him shows it is configured to control: KR 150 L150  "#KR150L150_2_TJ H C2 FLR ZH01"

   and that this difference could cause some substantial differences between the motion planning and the physical path of the robot. So, we've been instructed to reinstall
   the default files for the machine.dat.

I'll keep you updated on this process - let me know if you're able to look into what could be causing a wrist singularity @ the PTP movement and maybe resetting the machine.dat is the right answer as supported by both investigations?

Also, okay good (!) - just jogged the E1 360 degrees and that worked. I think that instruction went over my head before - whoops

Aaand now looking at the analysis of the code again, I see that there is a wrist singularity right at the beginning, which would be the reason that the simulation after the singularity is inaccurate.
So! I suppose I am on to modifying the $SINGUL_POS[3] variable in the machine.dat file

[@ Johannes:]

@ Johannes: Okay, that makes more sense about the offset base: if you don't want to use the root point of the turntable as your origin, the robot will use the origin of the base that's on top of the turntable. If you do want to use the root point of the turntable as your origin, then there is not a need to calibrate an offset base.

When you say "I doubt Base 0 would work as an offset base" - do you just mean in terms of the program being set to a base called "0"? (why does it matter whether it's called Base 0 or Base 17 if the XYZABC values will all be 0 for either one?)

Thank you for your note about the amount of triangles in the table mesh. I knew that the Geo input of the turntable was meant for the mesh of the final form and just forgot to unwire it so it was a good reminder to disinclude that. I've swapped it out for a simple extrusion in Rhino of the turntable top so that I can make sure the spindle isn't colliding with it (attached for ref)

Finally, thank you so much for the example file!! That has solved almost all of my issues. I think the last thing to resolve is that A6 is spinning all the way around in the first few motion blocks, and then about 30 lines down stops the program because "software limit switch +A6 reached" or something to that effect. Just something else that needs to be resolved in the .gh script I'm assuming.

--
@ mcb: for calibration of the Root Point of the turntable, I entered in the values numerically: I moved the TCP of a previously calibrated tool to the origin of the rotary, and then displayed the TCP's position with the variable $pos_act and recorded the XYZ values. Then, I went under Setup > Measure > External Kinematic > Root Point (numeric) and entered in the XYZ values.
I believe the gear ratio is 24/1 based on the $rat_mot_ax variable (photo attached because not sure if that's it)

Hello:

The process you suggested (I think) allowed me to calibrate the Root Point correctly. Referencing an earlier response to this thread, I moved the TCP to the origin of the rotary, and then displayed the TCP's position with the variable $pos_act and recorded the XYZ values. Then, I went under Setup > Measure > External Kinematic > Root Point (numeric) and entered in the XYZ values.

I think though, that I am confused about the necessity of a base calibration when using a turntable and creating a code in KUKA|prc for it.

In KUKA|prc:
I created a toolpath from the control points along the polylines that were derived from the contours of a form that I want to mill out of a piece of foam. After entering in the Root Point Numeric values in the teach pendant, I entered the same values for XYZ for the robot under Positioner Root Frame in (the Generic Turntable component).

Because the root point is given, and the control points to mill between are given in grasshopper, why is it necessary to also enter in Base values in KUKA|prc? It's my understanding that the base in the initial "stock" of foam that will be milled - is that incorrect? In the .src file, my base is set at 0.

I've attached my .gh file and .3dm file in case that clarifies my question.

Okay! Got it - that's good-ish news I suppose.
When you say calibrate, you mean mastering, correct?
Because yes we used an EMT tool to master the robot, and we were also able to calibrate 3 tools correctly with XYZ 4 Point and only received an error measurement of around 0.5 mm with each calibration.

When mastering the external kinematic, we are not able to use an EMT tool because we built our own mechanics around the KUKA motor. So, to master it, we simply select Setup > Master > Dial > External Axis 1 > Master and that's it - we don't move the external axes at all before we master or do anything else. Does that matter?