Posts by kbekkala

    I'm running a probe operation (on KRC2 ed05, KSS 5.6.5) using the above example and it works great, BUT the value I'm outputting is a REAL variable, and it's rounding off the value.

    In my $congif.dat the REAL variable has been updated to -337.707, and the msgnotify command writes out -338.

    Is it possible to display at least the first decimal, and get -337.7 displayed on the pendant messages?

    Usually concern is A1 and problem is solved by:
    a) mounting robot tilted slightly (10 deg)
    b) squaring world coordinate system by entering tilt angle into $robroot

    I'm interested in this concept, and having the same problems.. the idea must be to have A1 always be fighting uphill while milling?


    Just to confirm the idea, if my cell is set up that the robot spindle approaches from world +Y, and the table is directly in front of the robot (2000, 0, 0 or something), I could just tilt the robot base in a slight (-X) rotation?


    Such a simple solution if it's that easy! There's a fitting saying from my old mechanisms professor: "it's really hard to make a simple design."

    Here's the IOSYS line:


    [DEVNET]

    ; This is where I/O at DeviceNet is assigned.

    ;

    ;INB1=13,0,x1 ; $IN[9-16] (1 byte = 8 bits)

    ANOUT1=13,0,16,3 ; $ANALOG OUT [1-2]

    OUTB26=13,4,x1 ; $OUT[209-216]


    I was attempting to set a global variable, something like


    SIGNAL SpindleRPM $ANOUT[1]  


    and the SetTool() program would also cover the spindle speed.


    I don't think I tried setting the variable to less than 1, and that would make sense why it's always at the maximum. Thats got to be a big slice of my problem, anyway.


    Edit: Got it, it was just the X10 factor that was fooling me!

    That makes sense for the $TOOL setting, you're correct that my code is raw KRL, and we only machine the one material on this robot (nice not to have to worry about changing RPM!). I just want to build some kind of guarantee that CurrentTool will match $TOOL. Maybe another SWITCH at the very end, where each case just assigns $TOOL.

    I haven't been able to get ANOUT to set correctly yet (I think there's a factor somewhere in there), so that program's on pause right now. My VFD just takes a 0-10v signal as a percent of its max speed, and a separate RUN signal.. The problem I want to avoid there is that I have 3 tools, T1 can only spin *at maximum* ANOUT=3.0, the others spin at ANOUT=4.0.

    Got it now, I wasn't actually updating the CurrentTool value in the variable monitor.

    Thanks for the tip Skyefire, I moved the Endif to the end and it appears to be functioning correctly (with some position corrections as well).

    Is it good practice to set the ANOUT (spindle rpm) and $TOOL=TOOL_DATA[n] inside this SetTool( ) subprogram as well?

    I have a tool change that is close, but doesn't recognize a global variable how I want it to. If anybody can take a look I'd appreciate it.

    Basically, my CAM program calls SetTool(1) to fetch Tool #1.

    It checks what tool it currently has, a global INT CurrentTool.

    If CurrentTool is different than called, here it returns Tool X and fetches Tool 1.

    Lastly, CurrentTool =fetched tool.


    the problem is that the INT CurrentTool is not being updated via the subprogram. I set it to 2, ran a test program that called SetTool(1), but it skipped the Tool 2 return (the CurrentTool switch) and went straight to fetching Tool 1.

    Apologies for all the Folds, I don't know how to collapse them.


    I have this problem occasionally on our ed05. My problem is the wiring on the back of T1/T2/Auto switch is dirty or corroded and it doesn't recognize that you're in an operating mode (that's why this is a question mark in this screenshot, instead of T1 or Auto)

    Check that the wires are connected, then wiggle them, or pull them out and clean under the screws.

    I'm able to solve it just by wiggling the wires. If your mode switch is on the pendant, this won't exactly work but maybe the concept is the same.

    Great feedback, thank you guys. I'll aim for the subprogram method.


    The reason for loading/unloading tools was that I'm not sure about editing a global variable for the "current tool number". I thought the PointLoader plugin can't use/edit global variables, but looking again it states

    "No local or global subprograms may be defined in the CAD/CAM file."

    and OrangeApps support said I could call any subprogram if it's already saved in the R1 folder, so I'd expect a similar thing with global variables.


    I love this code, Skyfire: in the SPS, $OUT[whatever] = bSpindleState AND $PRO_ACT, thanks for the tip!

    I'm not the cleanest or fastest coder but I'll try to update this thread with my sub soon.

    I have a KRC2 ed05 with an ATC spindle, and I use Pointloader to run large programs.


    My end goal is to write a functional tool change so each program will have the robot get a tool, run the toolpath, then return the tool and go to home position.


    Pointloader can run a subprogram like "ChangeTool(a,b)", so I think I'll just write two subs; one to get a tool, one to return it.


    The groundwork question: Why is it common to run a subprogram to turn an I/O on or off?

    (e.g. SpindleOff to turn off a digital I/O, instead of $OUT123=FALSE)

    Is it just cleaner theory or does it work with interrupts better or something?


    I followed another thread to stop my spindle if $PRO_ACT goes false in SPS, maybe the subprogram method will let me restart the program (and spindle) if I need to stop it. At the moment, I'm forced to restart the toolpath from the beginning.


    I appreciate any insight!

    if you want to get rid of it, you would need to install XPe, KSS and other options from scratch. Preferably on a clean new HDD.

    While I was waiting for kuka support, I tried a cloned HDD from my other controller, changed the machine data and it's up and running. Kuka did get back to me and can get me the XPe install, but if this works I'll keep going with it for now.

    I'm back on this project again, I've learned it's a Daimler version with kuka.cpc installed, stopping me from installing additional software (orangeapps pointloader).


    I'm trying to get a fresh kss now, but getting this error when I hit setup.exe



    I'm holding both ctrl buttons when booting, that or both shift keys seem to stop the Krcstart program (holding just one key has no effect) but the error sure is declaring that something is still running.. I should have snapped a picture of the task manager processes too.

    some of the values you have are 2.7m which is way more than any dimension in that diagram

    sheesh, I didn't realize what I was looking at there, that's huge.


    we had a 6DOF weighted-average algorithm that took the location the robot wanted to go to, averaged out the corrections from the nearest N points in the sample set, and applied them.

    This is about what RoboDK does I believe, I was hoping to get around having to run all our CAM programs through their offline filter. It's effective, just a third step to take! I'll give the DH parameters a little more thought, but not hold it as an absolute goal.

    Thanks for the info guys.

    some of your dh parameters are completely off.

    Before overwriting the official ones you should try to solve this problem first

    You mean the ones in the photo I attached? Those were generated by RoboDK, I haven't figured out how to convert from their 4 parameters to Kuka's three DH parameters.

    On that note, I got the machine.dat manual from Kuka today, here's the relevant diagram. I'll dive into this later in the afternoon.

    Just found some corresponding values in ROBCOR:


    Code
    $DYN_DAT[13]=350.0
    $DYN_DAT[14]=1050.0

    if I update these along with the matching values in MACHINE.dat (Length A and Length B) then the error disappears.

    Same with a few numbers in the other variables of MACHINE, but I don't know yet how the DH values are accounted for.

    It's nice to be on the right path for once. I have to get some parts machining before I can finish this tonight, I'll look through the ROBCOR file has a complement for the kinematics.

    I tried with just the length_A altered and got the same errors. The fallback plan of robodk's filtering is the more common one anyway, I just didn't want a third step between CAM and running the robot. If it's a pain, maybe we'll upgrade to the spatial accuracy add-on computer (I think you had linked to it in another thread, panic mode).


    We'll see what Kuka support says.

    Working with a KRC2ed05, with a KR200-3 comp arm.


    I used roboDK's calibration program + laser tracker to create a kinematics DH table:



    How can I update the machine data to match this?


    some qualifiers:

    I have a backup HDD.

    I can use the robodk filter and avoid this, but I'd prefer to correct the kinematics at the source, if it's possible.

    The closest I've gotten is this thread: kinematic parameter stored inside robot, and acceleration and torque signal channel before and after gear reduction but I don't know exactly how the variables are mapped.

    It's easy enough to assume my value of "a'" for Joint 3 (45.091445mm) would replace the even 45mm below in my $TX3P3, both negative. Past those few obvious ones, is there a standard or diagram that shows which values are which? I understand D-H kinematics at a fifth grade level, but these two DH values are missing a theta value anyway. I'm hoping I can at least correct the lengths and take out 80% of my position error.


    FRAME $TIRORO={X 0.0,Y 0.0,Z 750.0,A 0.0,B 0.0,C 0.0}

    FRAME $TFLWP={X 0.0,Y 0.0,Z 210.0,A 0.0,B 0.0,C 0.0}

    FRAME $TX3P3={X 1000.0,Y 0.0,Z -45.0,A 0.0,B 90.0,C 0.0}

    REAL $LENGTH_A=350.0 ;GRUNDACHSLAENGE A

    REAL $LENGTH_B=1050.0 ;GRUNDACHSLAENGE B

    DECL DHART $DH_4={DHART_A 0.0,DHART_D 0.0,DHART_ALPHA 90.0}

    DECL DHART $DH_5={DHART_A 0.0,DHART_D 0.0,DHART_ALPHA -90.0}

    And please do not post images on external sites. this can really tick off users that are trying follow the topic (or trying to help you) so externally hosted files should really be considered only in emergencies.

    Here I thought I was doing it the right way with the embed thing, I'll change that in the future.

    I ended up moving the major files from R1 to a backup folder on D:\, then copying everything from the D:\KRC1_CD\INTERNAT\KRCSETUP\KRC\ROBOTER\KRC\R1 folder back to main R1 folder (in expert mode). Had a bunch of errors pop up with red X programs in other folders under the R1 folder, I deleted all those and now my program is working fine. Some startup errors about missing signals or something, but I can ack them and they disappear until I cold boot again. That's clean enough for now, until I can get KSS freshly installed.

Advertising from our partners