Posts by Mate_271

So, I am using a PLC type( Turck) which can be profibus slave, which is communicate one of our robots and works perfectly fine. The problem is that we would like a 2 robot cell, and 2 master robot can’t communicate with a slave. They have solution to use proconos, that’s why i wanted to use that or i have to buy 2 plc which are communicate to each other. Sadly, deviceNet not good either.

Dear PanicMode,

Thanks for your information. My robot controller KSS version is 5.6.12, and i found the manual on kuka xpert, but i didn't find any similar name file on my KRC windows.(I mean proconos) In my country KUKA closed trading for krc2 robots(the support too), so i don't know how can i get this software. If somebody has this software can give it to me and i can use it too?

Dear Patrik,

Do you have more info about this. I mean manuals or something. I am completely new in proconos communication. What should be the first step? I mean do i have a proconos package on the robot like gripper spot tech? Or every controller can make this communication? Thanks for your help!

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:

J_Palett.xx=(M/12) * a²= (29,92/12)*0,8² = 1,5957 kg*m²

J_Palett.yy=(M/12) * b²= (29,92/12)*1,1² = 3,0169 kg*m²

J_Palett.zz=(M*(a²+b²))/12=4,6127 kg*m² -> 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:

J_Tool.xx= 1,8581 kg*m²

J_Tool.yy= 3,4674 kg*m²

J_Tool.zz= 4,5718 kg*m²

Third:

Steiner equation for "shifting": I = I_CM + M * r²

For palett inertia around $NULLFRAME (tool0) coordinate:

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

r_{x = 0,18m}

_ry = ((0,27533)² + (0,18)² )^1/2= 0,3289m

_{rz = 0,27533m}

And now steiner:

J_palettMod.XX = J_palett.XX + 29,92 * r_x² = 2,5651 kg*m²

J_palettMod.YY = J_palett.YY + 29,92 * r_y² = 6,2535 kg*m²

J_palettMod.ZZ = J_palett.ZZ + 29,92 * r_z² = 6,8808 kg*m²

Fourth:

Summarize: J_Tool.ab + J_palettMod.ab

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

J_TOTAL.XX = J_Tool.XX + J_palettMod.XX = 1,8581 + 2,5651 = 4,4232 kg*m²

J_TOTAL.YY = J_Tool.YY + J_palettMod.YY = 3,4674 + 6,2535 = 9,7209 kg*m²

J_TOTAL.ZZ = J_Tool.ZZ + J_palettMod.ZZ = 4,5718 +6,8808 = 11,4526 kg*m²

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!:)

Quote from hermann

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

Ohh ok, sorry.

Quote from hermann

Size doesn't matter that much .

You didn't say any word about the weight .

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!

Well.. i don't know why i didn't think about this.

Thanks for your help and sorry for overthinking it a bit!

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?

Somebody please?

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?!

Thread

KRC2 Collision Detection

Hello,

I am using a KRC2 2005 Edition with KSS V5.4.14. I have a KR180 Manipulator.

How can check whether collision detect is enabled or disabled? How can I enable it if it shut off?? Is it enabled in all modes (T2,T2,AUTO,EXT) ?

Cheers

SEAN-DUDE

September 6, 2015 at 12:16 PM

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?

Quote from SkyeFire

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?

Quote from hermann

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?

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

After this the first bit should $IN[1009].

Sadly, what I wrote upper, my first bit in the robot was $IN[505], which is almost the half of it.

(In the picture $IN[585] is the 0.bit of 10.byte)

Maybe some function can do this?

I attach some photos, which can help.

Quote from SkyeFire

$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)

Quote from SkyeFire

$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😊