Posts by Mate_271

    i am going deeper and deeper. :(

    I can't decide if I calculated correctly then :/


    First:

    I calculated the robot inertia around palett center of gravity.

    It doesn't matter there i am using the "Taken at the center of mass and aligned with the output coordinate system" OR just "Taken at the output coordinate system", if my coordinate system located in the palett center of gravity.(calculate here the 3 inertia for xx,yy,zz)

    The palett length(b) 1,1m, width(a) 0,8 m, Mass(M): 29,92kg

    These values are:

    JPalett.xx=(M/12) * a2= (29,92/12)*0,82 = 1,5957 kg*m2

    JPalett.yy=(M/12) * b2= (29,92/12)*1,12 = 3,0169 kg*m2

    JPalett.zz=(M*(a2+b2))/12=4,6127 kg*m2 -> Same as in SW, other axis little difference, but it's OK


    Second:

    For the empty gripper if i use "Taken at the output coordinate system."!!:

    Coordinate system located at $NULLFRAME (tool0) coordinate.

    values:

    JTool.xx= 1,8581 kg*m2

    JTool.yy= 3,4674 kg*m2

    JTool.zz= 4,5718 kg*m2


    Third:

    Steiner equation for "shifting": I = ICM + M * r2

    For palett inertia around $NULLFRAME (tool0) coordinate:


    For this we need distances from palett center of gravity coordinates to $nullframe coordinates:

    rx = 0,18m

    ry = ((0,27533)2 + (0,18)2 )1/2= 0,3289m

    rz = 0,27533m


    And now steiner:

    JpalettMod.XX = Jpalett.XX + 29,92 * rx2 = 2,5651 kg*m2

    JpalettMod.YY = Jpalett.YY + 29,92 * ry2 = 6,2535 kg*m2

    JpalettMod.ZZ = Jpalett.ZZ + 29,92 * rz2 = 6,8808 kg*m2


    Fourth:


    Summarize: JTool.ab + JpalettMod.ab

    TAKEN AT THE OUTPUT COORDINATE SYSTEM! ( $NULLFRAME) matches robotflange:

    JTOTAL.XX = JTool.XX + JpalettMod.XX = 1,8581 + 2,5651 = 4,4232 kg*m2

    JTOTAL.YY = JTool.YY + JpalettMod.YY = 3,4674 + 6,2535 = 9,7209 kg*m2

    JTOTAL.ZZ = JTool.ZZ + JpalettMod.ZZ = 4,5718 +6,8808 = 11,4526 kg*m2


    As we see we got back(with a small difference) what solidworks offers us in terms of "Taken at the output coordinate system."


    So since solidworks backs up the calculation for us it should be good right?


    so this is the most user-friendly and realistic solution. I also thought that I would have to use the robot to calculate each mass, center of gravity, inertia, but I was wondering how you would solve it. Thanks for the help guys, I'm on it!:)

    Have a nice day!

    The manufacturer deals with the production of pallets of special sizes. The picture you sent is a good starting point. Due to the narrowness of the space, the size of the pallet, and the dimensions of the robot (KRC2 KR180), we cannot always grasp the center of the pallet. Sometimes the robot grabs the top of the pallet about a third of the way or even lower, towards the end of the pallet.

    The gripper works with vacuum. The positions are ready and tested. The only problem is the load data.

    Due to the reasons described above (small space, size of the pallet, reach of the robot's arm), the robot had to pick up the top of the pallet from such positions that it would fit. Because of this, sometimes the center of gravity really shifts, especially in the case of the largest size, which can weigh 30-40 kg.


    The picture I sent shows the two parallel vacuum grippers and the TCP. The red part I circled is the top of the pallet. This is what the robot packs. Essentially, a pallet has 3 legs and a top. The robot always picks up the stacked pallet tops from one point, so it is conceivable that the load data will always change if the width, length, height and thus the weight of the pallet tops increases. These pallet top stacks arrive at the robot on a conveyor belt. The robot finds it and places it on the positioning table, where it is positioned. So it already has a 0 point (one of its corners) from which we can calculate. Here, the robot finds the center of X and, if necessary, even moves a bit in Y. It depended on how I fit in the area. If it fit, then you only had to move in x and grab it at the bottom, if it didn't fit because the top of the pallet is big, then we also move a bit in y. I hope I wrote clearly. Thanks!

    Thanks for your answer too Panic mode!:)


    I simply wrote wood because we are talking about pallets (more precisely, the top of the pallet). Of course, there is a distance between the boards and it also matters how many boards are in the pallet and how thick the "top" of the pallet itself is. I would simply like to see the whole thing as a rectangle. They are mostly made of pine and poplar. It can be wet or dry, as I wrote before.

    Of course, before positioning, they can be in the robot's hands completely randomly (shifted by 20-30-40 cm or maybe turned a little), but here too I would use the after positioning load data, because actually positioning is only necessary for precise insertion.

    The problem, as you wrote, is that compared to the TCP of the robot Tool0, for example, the pallet is 2300mm away in world +x, so the center of mass changes quite a bit. It is possible that this 2500mm long pallet roof is 1 meter wide or 1.5m or a maximum of 2 meters wide.


    As I took it from your words and 10-20-30 centimeter does not have such a big influencing factor, would it be good if I created the 60-70 pieces of load data in CAD and assigned it? Does this seem like the most reasonable and simple solution? Or create a robot program where can it be calculated?

    Thanks for your answer hermann!:)

    In my opinion, not really. You should have opened a new one. ;)

    Ohh ok, sorry. ^^

    Size doesn't matter that much ;) .

    You didn't say any word about the weight :hmmm: .

    It's a big difference between handling a cardboard or steel.

    May be you can calculate the weight from the dimensions and at least a rough calculation of the center of gravity to correct the load data.

    The material of the missing part is wood, which can be wet or dry, but I really don't know how to filter this, so that the operator always sets it exactly. I wrote down the inclusive dimensions only because it means different weights, and not only the weight will be different, but also the center of mass will change as a result :/

    I thought that I should create some kind of robot program, where I add the following to the load data of the already existing empty tool: inertia, center of mass, mass. Also, I don't know if this is possible or workable.

    Hello guys,


    I think this is the thread where i should ask my question.


    I pick a part from a random place with my robot, then i place it into a reposition fixture. After the re-positioning i place the part into the station. There are some calculation again and placing it. The problem is that I had to define many types of positioning in the robot, because the length of the part can be from 800 to 2500 mm and its width can also vary from 800 to 2000 mm. the thickness of the part also changes. If they want to produce a new type of product (which is included in the size range), the robot will calculate it and insert it into the machine exactly. My problem is that I don't know what load data to define when there are so many different types of packaging. I know I can enter zero values, but I don't want to overload the robot.

    I have already calculated the tool (the empty gripper) in CAD and fed it to the robot, so there is no problem with this, but what should I do with this many types? I was thinking of a Switch-Case branch, but if one part is already 2 cm bigger than the other, then another load definition would be necessary.


    Thanks for your help in advance!

    Thanks for your answers!

    That’s what i sent above. If i do this the robot will monitor the torque for the full program. If something change in load, the robot will stop immediately.(and of course the load won’t be similar every single type :( )

    So it looks like there is no collision detection in krc2 (which is investigate “1 point” like in krc4).

    Am i right?

    Hello guys,


    Is it possible to use TORQMON for a point like in krc4?(change the motion and add collision 1 example)

    I used it earlier collision detection in krc4, but never in krc2.

    I saw what panic mode wrote in other post, but if i apply torqmon, will it use it for the full program?!


    I would like to use torqmon for searching with empty hand at 1 point, because i packing different products(different weight too), so if the load is not 100% correct, the robot will stop with collision detection what i applied, like you guys said upper.


    Is there any solution for this problem? I was looking for a lot of manuals, but i didn't find this.


    Thanks for your help in advance!

    Thanks to your help guys, it looks like things are slowly working out.

    The picture show, if i comment out: INB128=7, 3 every single byte can be used.(expect that obviously)

    The log says 31 input and 32 output is useable.


    BUT:

    if I leave it in, the picture show what's wront. At this time the iosys.log says only 3 inputs and 0 output is useable. I tried to search what can be the problem, but i find nothing.

    Why doesn't the system allow me to map to that zone?

    Okay, let's back up a bit here. Try just using a single byte mapping first, and see what happens. Like INB63=7,0. Just that, nothing else.

    If that works, try adding INB64=7,1 and so on. Using INWs and x-multipliers is convenient but not necessary (and in fact, IIRC there were some versions of KSS where using Ws and x-multipliers could cause problems).

    Thank you very much for your help guys!( hermann, SkyeFire ) I will try it as fast as i can!:)

    I can attach only 2 pictures. I didn't want to spam the post, therefore i made a zip. Sorry!:/

    In this picture show one of my variable bits. This variable(INT) first bit is my 0.bit of 10.byte.($IN[585]) Which means my first bit of 0.byte is $IN[505]. Which is the intermediate value of 0 and 1009. If mapping values didn't match(i mean in robot side and plc side), maybe the system "puts" the ios in an intermediate position. Is it possible?

    Nope, it's kind of inconsistent what kuka does here.

    The number direct behind INB / OUTB / INW / OUTW / INDW / OUTDW always are counted as bytes.

    The reason would be, that if it was depending on kind of IN / OUT you can't map it bytewise.

    In kuka i changed the mapping what you see upper, but in my turck hmi the 0.bit of 0.byte start from 0.
    I think i have to change the mapping in PLC. Should start from 127.byte. The 0.bit 0.byte should be 1009(Which should be the 0.bit of 127.byte).

    The robot will take an intermediate value between 0 and 1009. I think that could happen here.

    Is it possible?

    $MOVE_ENABLE does not change addresses when you switch between EXT and T1. Therefore, whatever device you have sending the KRC $MOVE_ENABLE needs to be adjusted to send $MOVE_ENABLE when the KRC is in T1.

    I thought i made a mistake, cause changing a sys io is not allowed.(if move enable is sys io😅)

    When i wrote back the move enable input value to 1015 and press ack, the robot start moving. Thats why i would like to change the mapping: wrote back every sys variable to factory value and cover those IOs with my 256bit.(which i have)

    $IN[585] should be in the middle of INB73, or INW36, if my math is correct.

    Yes..:( Thats what i calculated too. Thats why i dont understand what is happening and why is it happening (with INW63…)😓


    Thanks for your spreadsheet. I will try to figure out what can be the problem😊

    Firstly, appreciate your quick answer!:)


    Check the system variable $SET_IO_SIZE.

    Code
    INT $SET_IO_SIZE=1 ;SETZEN EA-BEREICH (1=1024, 2=2048, 4=4096)

    I Found it, i will change it to 4096. Thanks!:)


    i would like to clarify why i ask it.

    First integration mapping in iosys.ini was:

    INW0=7,0,x16 ; $IN[1]-$IN[256]

    OUTW0=7,0,x16 ; $IN[1]-$IN[256]


    After that every thing worked like it had to(almost).

    I changed a SYS IO (i think it is sys io), which name is $MOVE_ENABLE. From $IN[1015]( Im not sure right now) to $IN[255], because my mapping area was that, what i wrote upper.

    In EXT everything worked correctly, the PLC sand move enable etc... but when i changed mode to T1, then i could not move the robot, because robot wait for move enable.
    What can you recommend for me?

    How should do it normally(the communication and mapping))?

    Quote
    $IN[1008] is the end of INW 62, not the start of INW63. $IN and $OUT "blocks" always start with an odd number, and end with an even number which is also a multiple of 8.

    Ohh your right! Then can you tell me please what should be the range of this?

    I had a bit which was the 0.bit of 10.byte and when i changed the mapping to this(what i wrote earlier):

    Code
    INW63=7, 0, x16
    OUTW63=7, 0, x16

    Then the 585. bit turned to TRUE

    If we make a quick calculation, then the 0.bit of 0.byte is $IN[505]?

    How is it possible? :O



    Appreciate your help! Thank you in advance!

    Hello guys!


    If i would like to start my inputs from $IN[1008] is this the correct form?


    INW63=7, 0, x16

    OUTW63=7, 0, x16


    I have 32 bytes IN and 32 bytes OUT with profibus communication.(i would like to reserve inputs and outputs from 1008 to 1264)


    And i would like to ask one more thing. If i know rigth i have 4096 digital in and outputs in the robot. If i go view-> digital inputs, i see only 1026 inputs. Why?


    Thanks in advance!