Posts by Joe_vlc84

    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.


    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

    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.

    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



    DEVNET CODE


    Code
    [krc]
    debug=0
    baudrate=500
    
    [1]
    macid=11
    
    [2]
    macid=21

    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)


    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 SkyeFire

    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.


    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)


    Code
    xdrop_pos=xmasterdrop_pos
    xdrop_pos.x=xdrop_pos.x+(partwitdh*rowpos)
    xdrop_pos.y=xdrop_pos.y+(partlength*columnpos)

    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.