Tks SkyeFire
I think I understood it
Monday when they layout the devicenet cables I will find out
Tks SkyeFire
I think I understood it
Monday when they layout the devicenet cables I will find out
Good Morning
Im trying to remember/understand what each argument does in the IOSYS file
I tried to make various examples in the following code
Please correct me if I am misinterpreting the way this works.
;******************************
;V1
;PLC 128 Inputs
;PLC, MACID 11, output starting at 1
;Robot Input Starting at 1
INW0=11,0,x1;$IN[1-16]
INW2=11,2,x1;$IN[17-32]
INW4=11,4,x1;$IN[33-48]
INW6=11,6,x1;$IN[49-64]
INW8=11,8,x1;$IN[65-80]
INW10=11,10,x1;$IN[81-96]
INW12=11,12,x1;$IN[97-112]
INW14=11,14,x1;$IN[113-128]
;V1 but using Multiplier
INW0=11,0,x8;$IN[1-128]
;******************************
;******************************
;V2
;PLC 128 Inputs
;PLC, MACID 12, output starting at 129
;Robot Input Starting at 1
INW0=12,16,x1;$IN[1-16]
INW2=12,18,x1;$IN[17-32]
INW4=12,20,x1;$IN[33-48]
INW6=12,22,x1;$IN[49-64]
INW8=12,23,x1;$IN[65-80]
INW10=12,24,x1;$IN[81-96]
INW12=12,26,x1;$IN[97-112]
INW14=12,28,x1;$IN[113-128]
;V2 but using multiplier
INW0=12,16,x8;$IN[1-128]
;******************************
;******************************
;V3
;PLC 64 Inputs
;PLC, MACID 2, output starting at 145
;Robot Input Starting at 65
INW8=2,18,x1;$IN[65-80]
INW10=2,20,x1;$IN[81-96]
INW12=2,22,x1;$IN[97-112]
INW14=2,24,x1;$IN[113-128]
;V3 but using multiplier
INW8=2,18,x4;$IN[65-128]
;******************************
Display More
Thanks
As Panic mode said, using signal makes reading the program so much cleaner and user friendly.
The way I do it, is in Config.dat.
Within the fold "User Globals" I declare all my user signals.
Simple example:
Config.dat:
;Inputs
SIGNAL Area_Occupied_1 $IN[21]
SIGNAL Job_Finished_1 $IN[31]
SIGNAL Download_Sensor $IN[41]
SIGNAL Clamps_Closed $IN[200]
;Outputs
SIGNAL Close_Clamps $OUT[200]
Program would look like this:
PTP 10
Wait for Download_Sensor == True
Area_Occupied_1=True
PTP Pick Position
Close_Clamps=True
Wait for Clamps_Closed==True
PTP 20
Wait for Download_Sensor=False
Job_Finished_1=True
Seems like I solved it.
In the menu "Configure->I/O Driver->I/ODriver"
I uninstalled the driver, and reinstalled it.
Fault went away.
HI hermann
I did try your suggestion.
However the I/O driver is not running.
If i try the menu option. Configure->I/O Driver->I/ODriver Reset
I get "Driver reset DeviceNet failed".
The red LED next to "Devicenet" is off, indicating the driver is not ok.
Im sorry im unable to upload an image, but it seems like there is something wrong with my driver rarther than my mapping.
My post with the electrical photos is awaiting moderators aproval
I am having trouble uploading images, i uploaded a gallery to IMGUR.
Basically the electricians have connected both the bk5200 module and the anybus directly in to the robots devnet port.
The BK5200 is being supplied 24V from the black omron module on the right.
IOSYS CODE
[CONFIG]
VERSION=2.00
[DRIVERS]
DEVNET=2,dnInit,dn2drv.o
[MFC]
[INTERBUS]
;-------Inputs---------
;SlaveInputs
;-------Outputs--------
;SlaveOutputs
[DEVNET]
;-------Inputs---------
;PLC Inputs via Anybus MACcID 11
INW0=11,0,x1;$IN[1-16]
INW1=11,0,x1;$IN[17-32]
INW2=11,0,x1;$IN[33-48]
INW3=11,0,x1;$IN[49-64]
INW4=11,0,x1;$IN[65-80]
INW5=11,0,x1;$IN[81-96]
INW6=11,0,x1;$IN[97-112]
INW7=11,0,x1;$IN[113-128]
;SlaveInputs
;BK5200 IO Driver MAC ID 21
INW8=21,0,x1;$IN[129-144]
;-------Outputs---------
;PLC Outputs via Anybus MACcID 11
OUTW0=11,0,x1;$IN[1-16]
OUTW1=11,0,x1;$IN[17-32]
OUTW2=11,0,x1;$IN[33-48]
OUTW3=11,0,x1;$IN[49-64]
OUTW4=11,0,x1;$IN[65-80]
OUTW5=11,0,x1;$IN[81-96]
OUTW6=11,0,x1;$IN[97-112]
OUTW7=11,0,x1;$IN[113-128]
;SlaveOutputs
;BK5200 IO Driver MAC ID 21
OUTW8=21,0,x1;$OUT[129-144]
Display More
DEVNET CODE
GoodMorning
My client as provided me with a weird setup.
I have 3 KRC2 V5.6.12 with a devnet card and each robot has an I/O module (Beckhoff BK5200)
At the moment 2 robots are working with local auto.
The 3rd robot we are trying to connect to a Omrom PLC (NJ101-1020).
Since the robots cards can only be master, my client purchased a anybus gateway module (AB7854-F) that should be able to manage the communications between robot and PLC (and plc be master).
At the moment I have in the robot:
"Configuration error I/O driver DN2DRV"
I would appreciate any help getting past this step
I am not at all confident with the electricians work (he is the nephew of my client), so the error could be there.
I am going to upload photos, iosys and devnet files in next post.
Hi MOM
Sorry, as I explained earlier that client is not willing to invest more hours, so it will stay as it is currently.
The target of the post was to help ME understand better how to avoid the S and T calculations.
Now going back to post #10
1st thank you very much for explaining FRAME I understood perfectly.
I always worked with frame, just didn't realise that was the correct TERM.
As for what I mean for across:
He means (I assume) that the pallet spans the $WORLD X axis. This would guarantee that A4, and possibly A6, would have to be in different quadrants for different parts of the pallet.
My 2nd palet is sitting across my $world x axis (axis 1, 0°), my master position is in a corner of the palet.
So when it multiplies the rows/colums some of the positions are across the $world axis and then if the points are PTP the S and T values change, and then I have workspace errors.
With LIN this doesnt happen.
Can you explain what you have done differnetly to when the problem is solved now?
Hi MoM.
I wanted to avoid using LIN movements, and use PTP movements.
Eventually I did not manage to do this, I just eventually used LIN movements which ignore the S & T values.
Its safe to say I didnt achieve my goal.
The program now, has
PTP P10 (Non recalculated)
LIN P20 (Recalculated)
LIN Pick or drop positions (Recalculated)
LIN P30 (Recalculated)
PTP P50 (Non recalculated)
Display MoreFRAME is easy to understand:
In robot programming we are dealing with coordinate systems and not points (point is just a vector with x,y and z as parameters)
A coordinate system has a vector describing the origin of the coordinate system and an orientation describing the rotation going from source to target coordinate system
A FRAME consists of X,Y and Z for the translation moving the source origin of the coordinate system to the origin of the target coordinate system
A, B and C of the orientation change from source to target coordinate system.
KUKA and others using the Tait-Bryan angles: rot.z(A)*rot.y(B)*rot.x(C)
(some guys (even on this forum) call this (extended) Euler angles (Euler angles would do a rotation rot.z(?)*rot.y(?)*rot.z(?))
There is a document on the internet which describes all possibilities of rotations
Putting translation and rotation together ends with the FRAME {X, Y, Z, A, B, C}
If you have more question on that do not hesitate to ask for
Now let us talk about my stupid(?) idea:
You have three palets and on every palet you want to do the same thing - correct?
Why not saying:
Palet 1: BASE_DATA[1]
Palet 2: BASE_DATA[2]
Palet 3: BASE_DATA[3]
Advantage:
Program on all palets is the same (only difference $BASE)
Have a safe positions on top of the palets using PTP AXIS with the required axes positions and afterwards LIN to go to the positions on your palets (because the target position will be the shortest distance to the previous position)
Tks MOM So yeah I do understand FRAME, just never used the TERM.
I do have a base_data for each palet.
I took a "MASTER" palet and painted the tool on the palet (In my MASTER POSITION).
So when they add a new palet, I just calculate the base orientation (not all are facing the same way/angle) and touchup the master position.
And the program is ready.
Its really a charm to look at it work.
this is why KUKA College suggest to use array to store all calculated positions. using loop(s) one can compute all locations and of needed adapt S&T for ones that need correction. then let program just call already calculated points. test it once in T1 and off you go.
this may not work for cases where reference position can change dynamically but for usual palletizing applications this is very simple and works nicely.
I have never programmed an array (spank me, I deserve it)
However I understand an array would be like a dictionary with all the positions saved.
And that doesnt work for my application.
The robot calculates the orientation and how many parts fit on the palet win the inputs of lenth/width/height and then just multiplies the "master position" by the column/row calculated with the current parts in pallet.
The robot will be "FED" parts with many many size variations (thousands of variations). (only 1 size per palet)
It's a real risk, but your approach should manage it. The key is that PTP motions "obey" the S&T variables, and LINs do not (or rather, LINs prioritize their linear path over the S&T if the two ever conflict). As long as all your "dangerous" moves are LINs, you should be okay.
One of the worst cases of this I ever saw not only had the palletizing pattern crossing the $WORLD X axis, but also had the robot sitting above the pallet such that a certain subset of positions forced the robot to pass through the A5 singularity, because part of the program involved moving parts between different positions on the pallet, not just picking/placing (it was a werid setup). The solution involved detecting this in advance by checking $POS_ACT_MES.Y against the Y of the next calculated point, and if the move involved a transition between $WORLD.Y + and -, the program divided the "dangerous" motion into a series of short moves, filled them into an array of FRAMEs, and then ran through them using PTP motions.
I am worried since the parts they palletize can vary in many shapes, even some larger than the palets themselves.
But I did try a dozen parts and I think with the ptp movement, and the vacuum tool being very small (400x130) even if it did do a peter pan on the way out, it would never crash.
Maybe strech a few cables
My client is over his budget in hours, so sadly im not going to dedicate much more time to providing a better solution.
What do you mean be sitting across?
I think your calculation is wrong and is causing the problem
Can you provide more information?
As SkyeFyre points out in the next posts.
Quote from SkyeFireHe means (I assume) that the pallet spans the $WORLD X axis. This would guarantee that A4, and possibly A6, would have to be in different quadrants for different parts of the pallet.
SkyeFire Tks
Hello Guys.
Thank you all for your friendly comments/help
Sorry for the delay, last week I was sent to another factory, since the client for this application was closed down.
Im gonna answer you guys one by one
In the previous post i simplified the calculations using "rowpos" to avoid confusing anyone with the rest of the maths.
So the example above is E6pos based.
And honestly I have never worked with A6pos.
But im guessing it saves in the dat file the axis positions rarther than the actual coordinate.
Also im not familiar with FRAME, have been searching, but its 2 am... so monday I will have a more detailed search.
Thank you both so much.
I believe next week I will have time to try out these different solutions.
I had put a single ptp at the start of my drop program and a single ptp at the exit.
And then all calculated positions are Lineal.
Its just a topic I would like to understand and improve on.
Im worried exiting my drop from a given position could cause the robot to do some irregular movement due to rotation of axis 4-6.
Hence why I would feel better using ptp movements.
Also I made a master palet and just copy pasted the 3 programs.
3 bases and voila...
Except the damn palet across my Axis 1...
At the moment I recalculate my pick/drop position acording to my master position and then displace this position.
Example: (havent got my laptop here forgive any syntax error)
Good morning gents.
Edit: Sorry forgot to add, this is a krc2 V5.6.12
Im working in a really fun project, at least for me after 10 years in car factories with basically grippers and welding guns.
I have my first palletizing robot, and its really pushing me (happily) out of my confort zone.
So the robot has 3 bays for standard europalets in front.
Palet 1 I programmed and works a charm.
I calculate a grid and then multiply by row or column and is working really good.
However, my second palet is sitting across my axis 1 (I can already feel you guys grinning).
So when the positions are recalculated, the point becomes unreachable due to axis 1 limit.
I can see the problem in my dat file, the S and T values are changing. (T43 changes to T42).
I do know with Lin movements I can ignore this, however I would like to know if there is a better approach, its not the first time in my career I have suffered with these orientations.
Any help much appreciated.
Edit: misspellings
either version should work.
are you sure the code is scanned continuously?
how are you checking? maybe just HMI does not display updated value.
Thanks panic mode, it was just the HMI showing a higher speed, but actually the speed was 30%.
I just couldn't really try it out when I posted.
Also thanks for helping in other posts, indirectly you have helped me many times.