Understanding cell.src

    Hello everyone.
    Introduction: first time implementing automatic external in a Kuka robot ( kr16-2 controller KRC4 ).

    1- I add a lot of trouble when trying to choose the program based on the "selected bit" -> PGNO_TYPE 1
    I couldn't select the program at first try. Sometimes after 3 or 4 attempts I was able to change the program. But i never could figure out how or why. It looked like the "synchronization time" was not ok everytime. I was sending pulses like it's supposed to in the integrator manual. Does anyone have a ladder example?

    2- What's the point of using cell.src, if i can run,cancel and start a regular program from sps.sub? Do i actually need the BCO check XHOME or can i remove it?

    3 - Can i simply add code to sps.sub to select programs at runtime, based on the fact that i'll have only 4 progs?
    Something like

    The robot and robot cell are already on the way to the final customer and I'm gonna install it next week. So.. any additional information can either be neutral or very usefull to me :uglyhammer2:
    Thank you

    Hello,

    There are three types of PGNO, all are well docummented.

    For few programs type 3 may be simpler (specially if using wired signals between PLC and KRC). Note that control sequence is a bit different though...

    things to watch for is signal type - Some signals are EDGE-SENSITIVE, while others are LEVEL-SENSITIVE. this is a very important distinction. edge sensitive signals in this case are rising-edge sensitive. this means that if the signal is already true (or is not low long enough) edge may not be sensed.

    for edge sensitive signals one must ensure correct timing. i would recommend 20ms as minimum duration for on and off states...

    crude but simple workaround is to simply use symmetrical and low frequency clock (10Hz for example) in PLC logic on all PLC outputs that are driving KRC edge sensitive inputs. but like anything, doing things without understanding is ... not very good.

    CELL is used as a standard, documented and flexible way to start user programs using external controller. of course one can create own logic too and modify or replace CELL completely but i would suggest being careful. in my experience it is usually those who are least qualified to make such workarounds that try hardest to make something on their own... somehow they think they can make "better" programs when in reality they are literally killing resources or causing all kind of problems - some that may not be immediately observable (then they blame problems on robot).

    they are also the ones annoyed by BCO and just "want it gone...". this can have a very bad consequences and i see it as a red flag. when i think about it, i have never heard trained programmer complain about BCO.

    BCO check in CELL is configurable and can be removed if needed (there is no BCO in EXT mode) but - there is no need to delete any code. CELL is already created to be flexible, it is enough to toggle variable CHECK_HOME. this can be done from single variable monitor.

    and to answer the last question...
    if you have ever seen annoying popup windows showing up faster than you can can close them - your pseudo code is basically doing sort of the same thing with submit interpreter. reason is that CWRITE commands are asynchronous and may take relatively long time to execute. Submit is running in "bursts" so one scenario is that same line of code may be processed many times. this means that slow async instructions like CWRITE will "stutter" or run multiple instances in parallel. i hope this illustrates how something that looked like a good idea can turn out to be something different. this can still work as long as KSS garbage collector can keep up and clean the mess without running out of resources. chances are it will work well enough to look ok (at least for the time you are there). reality is that would be just an illusion that everything is fine.


    better way is add some code and use strategy to avoid problems. that includes using one-shots, checking for instruction completion etc.

    my recommendation is to take a formal training or buddy up (get help from someone experienced when doing first project).

    hope this helps.

    1) read pinned topic: READ FIRST...

    2) if you have an issue with robot, post question in the correct forum section... do NOT contact me directly

    3) read 1 and 2

    Edited once, last by panic mode (May 19, 2018 at 12:29 AM).

    here is an example ladder code using type1 PGNO and reflection (parity check is in this case turned off).
    reason parity is off (signal set to 0) is that reflection is superior - parity check can only detect corruption of a single PGNO bit, while reflection checks all PGNO bits. as a bonus, this saves you some programming effort - no need to figure out how to calculate parity in PLC any more. this would require counting set bits somehow (using loops or series of XORs for example).

Advertising from our partners