Posts by kbekkala

  • Logic question and Tool Change subprogram

    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!

  • Logic question and Tool Change subprogram

    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.

  • Logic question and Tool Change subprogram

    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?

  • Logic question and Tool Change subprogram

    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.


  • UNKNOWN OPERATION MODE error when E-Stop are not preseed.

    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.

  • Logic question and Tool Change subprogram

    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.

  • Logic question and Tool Change subprogram

    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!

  • Remove existing I/O, clean KSS, etc

    Quote from panic mode

    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.

  • Remove existing I/O, clean KSS, etc

    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.

  • Apply robodk-measured arm kinematics to KRC2ed05

    Quote from panic mode

    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.


    Quote from SkyeFire

    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.

  • Apply robodk-measured arm kinematics to KRC2ed05

    Quote from MOM

    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.

  • Apply robodk-measured arm kinematics to KRC2ed05

    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.

  • Apply robodk-measured arm kinematics to KRC2ed05

    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.

  • Apply robodk-measured arm kinematics to KRC2ed05

    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}

  • Remove existing I/O, clean KSS, etc

    Quote from panic mode

    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.

  • Remove existing I/O, clean KSS, etc

    Quote from SkyeFire

    Odd. Any ed05 KRC2 should have the USB port working 100%.


    Protip: before making ANY changes to this robot, CLONE THE HARD DRIVE!!!!

    Our other ed05 had no problems with the KSS reinstall that way, this one really makes me scratch my chin for this and other little things. I've got two clones tucked away, so I'm good to go there.


    The plugins I'd like gone are welding ones (including the cover I/O that's stopping my programs), there are 3 pages on the left of the TP home screen with buttons like "dress tip", "measure tip"... things like that. Eventually I'll have an operator running this cell and the fewer buttons they can press, the better. With some thought maybe I'll get to only needing an ext start button, right now I need the pig functional before I can put lipstick on it!

  • Remove existing I/O, clean KSS, etc

    Thanks hermann, I had done it this way with our other robot and it worked fine so I didn't think anything of it. I'll do as you suggested instead, and see if moving the backup config file to D:\ does the trick.


    Although I'm waiting for the ps2 keyboard to arrive, my usb keyboard doesn't have any effect.

  • Remove existing I/O, clean KSS, etc

    I copied a very minimalist config.dat from the KRC1_CD folder, and replaced the R1/system dat file (renamed original to ogconfig.dat and moved to a R1/system/backupinfo folder). Cold booted, and surprise, the original config.dat was there again. I tried again in case I had copied the wrong file, same thing.

    seems like config.dat would be triggering the issues I'm having but apparently I'm still a level too deep.