$ADVANCE being set to 0

    KSS 8.7.6

    KR C5 Micro

    KR 1100-2

    I am having an issue where $Advance is being set to 0 constantly, almost like its being set to 0 in an infinite loop. Nowhere in any of my code is $Advance being set to 0, and Kuka confirmed this after looking at my KrcDiag file. Has anyone ever experienced anything like this before?


    P.S. - I know that advance is being set to zero constantly because I put code in my submit to send me a message whenever it is at zero, after the message I manually set it back to 3. The messages come at a rate of at least 5 per second.

    Wow, that's odd. My first thought would have been that there's an SPS loop setting $ADVANCE to 0 somewhere, but if there's nothing in the code... Also, a free-running SPS loop would probably do it faster than 5/sec. Of course, that depends on how the SPS loop was constructed.

    What's the full option set in this robot? Any softPLC, mxAutomation, C3Bridge, EKI, etc? Barring a core KSS bug, there has to be something that's altering $ADVANCE. Maybe try disconnecting anything/everything the robot is connected to, and see if that changes anything?
    (heck, for something this odd, I might connect a monitor and disconnect the SmartPad, just to see what happens).

    Has KUKA tech support had anything else to say on this issue? This might be a case where it would be a good idea to try upgrading or downgrading KSS to 8.7.X, just in case your specific 8.7.6 might have some obscure bug. KUKA is usually willing to provide .Z revisions (X.Y.Z) for free. In this case, they might even offer you a .Y revision, at least for testing purposes.

    You might also ask KUKA to provide you, or help you create, a baseline Project file that should contain nothing but core elements, and see if that still has this problem. Unless someone at KUKA has a flash of inspiration, this feels like something that could be a long exercise in careful process of elimination.

    try this:


    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

    Only code that I can find is this line in bas, DEF_ADVANCE is set to 3. This is how it was setup by default. Nowhere else in any of the files is advance being modified or even being used.

    DEF_ADVANCE = 3

    $ADVANCE=DEF_ADVANCE

    What is weird is that advance seems to be continuously be reset to zero, but while testing in T1 and Auto, before I put the line of code in the submit to constantly set it to 3, I would set $ADVANCE to 0 and the program I was running would approximate the positions as intended. As soon as the program ended and I attempted to run again $ADVANCE would be zero again and I would lose my Approximated Positioning.

    Below is the code given to me by Kuka to test how often $Advance was being reset, which is how I know it is constant.


    IF $ADVANCE ==0 THEN

    $ADVANCE =3

    MSGNOTIFY("Advance run set to 0")

    ENDIF

    Quote from SkyeFire

    Wow, that's odd. My first thought would have been that there's an SPS loop setting $ADVANCE to 0 somewhere, but if there's nothing in the code... Also, a free-running SPS loop would probably do it faster than 5/sec. Of course, that depends on how the SPS loop was constructed.

    What's the full option set in this robot? Any softPLC, mxAutomation, C3Bridge, EKI, etc? Barring a core KSS bug, there has to be something that's altering $ADVANCE. Maybe try disconnecting anything/everything the robot is connected to, and see if that changes anything?
    (heck, for something this odd, I might connect a monitor and disconnect the SmartPad, just to see what happens).

    Has KUKA tech support had anything else to say on this issue? This might be a case where it would be a good idea to try upgrading or downgrading KSS to 8.7.X, just in case your specific 8.7.6 might have some obscure bug. KUKA is usually willing to provide .Z revisions (X.Y.Z) for free. In this case, they might even offer you a .Y revision, at least for testing purposes.

    You might also ask KUKA to provide you, or help you create, a baseline Project file that should contain nothing but core elements, and see if that still has this problem. Unless someone at KUKA has a flash of inspiration, this feels like something that could be a long exercise in careful process of elimination.

    The option set is SafeOp 3.6, HMI Easy 1.0, and Kuka Profinet MS 6.0.

    Kuka so far has asked for Diags and thats pretty much it. They also tried to tell me that $Advance has nothing to do with approximated positioning, which completely contradicts what they have in their manuals, as well as common sense. Usually I get more out of this forum than I do through company support, hence my being here:winking_face:

    Quote from chris.rhoades

    Only code that I can find is this line in bas, DEF_ADVANCE is set to 3. This is how it was setup by default. Nowhere else in any of the files is advance being modified or even being used.

    pretty sure you are doing something wrong. like not even using it and expecting to magically have non-zero value. if you want some variable to have certain value, you need to program code that puts the value there.

    so do not show just one or 2 lines of code. show complete program like i did. then we can try to replicate the reported issue.

    boil down your code to something small that still demonstrates the problem. show how you are monitoring the value... are you using variable overview? if you are using single variable monitor, are you sure that value is refreshed?

    and why are you putting anything motion related into submit? can you please post your submit file (in its entirety)?

    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

    Quote from panic mode

    pretty sure you are doing something wrong. like not even using it and expecting to magically have non-zero value. if you want some variable to have certain value, you need to program code that puts the value there.

    so do not show just one or 2 lines of code. show complete program like i did. then we can try to replicate the reported issue.

    boil down your code to something small that still demonstrates the problem. show how you are monitoring the value... are you using variable overview? if you are using single variable monitor, are you sure that value is refreshed?

    and why are you putting anything motion related into submit? can you please post your submit file (in its entirety)?

    Apologies, not the best at explaining things in detail.

    I am setting it to 3 in bas, which should be all that I need to do as I understand. When monitoring the value I am using either the section of code that gives a message when the value is 0, or watching in the variable overview.

    And I am not putting anything motion related in the submit aside from setting $advance to 3. I only do this so I can have continuous motion. Attached are my submit interpreters and bas

    I would assume if you do a "find references" on $advance you would find something fishy. But if you have done that...

    On a side note I once in my life tried using $ sign in front of own variables but i remember that it produced some really odd buggy behaviour that i didnt track down. But i've never done it since.

    You dont happen to have any odd settings like $stop_no_approx or any other submits running? Check the caller stack what actually is there that could be modifying it.

    Try stopping submits and see if that does anything. And i assume you have done the norwegian reset (power off power on)? Try restarting with reload all files. Do you have an initial or an older backup where this does not occur. I've also used 8.7.6 but have not seen this behaviour.

    Is running mode set to continous and not motion or step?

    I did not see any actual robot program with any motions attached, can you attach an example that reproduces this behaviour?

    I will attach a copy of one of my motion programs, I have tried cycling power, reloading files and backups, as well as not running submits. The only programs in the call stack is the motion program and submits. This issue happens in T1, T2, Auto, and Auto Ext. The only thing I can think of, which I have not been able to find in the manual, is that maybe since the mastering ref switch is not installed (I have a jumper plug in XG58) $Advance is being set to 0 due to issues with masref. Again, I cannot find anything in the manuals to corroborate this.

    you should not be modifying BAS.SRC. this file should be as is (as supplied by KUKA).

    you should not declare own variables with prefix $. that is meant for system variables only.

    you still did not show your ROBOT program. this is where robot motions are done, this is where $ADVANCE is supposed to be initialized, where BCO is performed, robot moves to home, does something, then goes back home.

    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

    ok, we were posting at the same time, i see the "pick" now.

    just put HALT command in there, perhaps before

    Wait FOR $Ok_To_Enter_Zone1

    and run it... when HALT is reached check the $ADVANCE value. you stated before that it is zero and it should not be.

    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

    I will try that thank you. I only modified bas after I was getting this problem to try and fix it. Only thing I modified was setting $advance to 3 instead of Def_Advance, which is set to 3 anyway but I was just spit balling so to speak.

    About the $ variables, for some reason I was under the impression that signals should be declared with an $ in front, not sure why I thought that but still. Unless theres any real danger to doing it this way I may leave it. It helps the other guys identify what is a variable and what is a signal tied to an IN or OUT

    After Kuka involved the developers in Germany, it turns out the problem came from a section of code they provided me for the purpose of resetting the active program after a fault.

    Code
    IF ($PRO_MOVE==False) and ($Program_Reset) THEN
    Code
          CWRITE($CMD,STAT,MODE,"STOP 1")
    Code
          CWRITE($CMD,STAT,MODE,"CANCEL 1")
    Code
          CWRITE($CMD,STAT,MODE,"RUN/R1/Main()") 

       ENDIF

    All of this except for the conditions at the top was copied straight from an email from Kuka so I am unsure at the moment what the exact issue is. For the moment I guess I will have to keep forcing $advance to 3, can't really just get rid of this code.

    Quote from chris.rhoades

    After Kuka involved the developers in Germany, it turns out the problem came from a section of code they provided me for the purpose of resetting the active program after a fault.

    Is that code running in the SPS? That should have no effect on $ADVANCE. Even if the STOP/CANCEL/RUN sequence sequence executes, at worst $ADVANCE should be set back to $DEF_ADVANCE, not 0. Not to mention, if that code executes, the robot is coming to a complete halt anyway -- there's no way to run the S/C/R sequence without breaking the ARP. And if the IF statement doesn't fire, then there should be no affect on $ADVANCE at all.

    The simplest test would be to comment out that block of code in the SPS and see if the issue stops. IF so, then you know the root cause and can start working on methods to resolve it.

    I'm a bit surprised someone at KUKA sent you that code snippet. It doesn't seem like their usual style. For one thing, they usually state-machine out the S/C/R sequence using $PRO_ACT1 similar to what you can see here: RE: Reset Cell KRC4

    That helps avoid any potential issue with the CWRITE commands stepping on each other. Due to the asynchronous execution of the Robot and SPS interpreters, it helps to take care with their interactions.

    I'm guessing $PROGRAM_RESET is your variable, not a system variable?

    I probably wouldn't use $PRO_MOVE in this case, probably $PRO_ACT1. But I doubt that's part of your issue.

    SkyeFire I did test it by commenting that section out, advance did not get reset. using $Pro_Move will not be final, just to get us by until I can work out something more permanent. This section of code is running in the SPS, which I guess would explain why $advance was being reset constantly. I'll look into the thread you referenced and see if I can use some of that instead. I will update here if I hear more from Kuka, might be useful to others who may have been given the same code.

    Quote from chris.rhoades

    This section of code is running in the SPS, which I guess would explain why $advance was being reset constantly.

    That's... VERY odd. I've used code similar to that on hundreds of KUKAbots over the years without ever seeing the effect you're describing. I'm going to suggest renaming $PROGRAM_RESET to something without the $, or just temporarily try it with the raw $IN[address] instead of your own variable. That's the only odd thing I see in the part of that IF statement that would run constantly (obviously, the interior of the IF should only run on rare occasions).

    If that doesn't work, definitely try something other than $PRO_MOVE. Whatever is going on, it has to be in the IF line -- nothing else makes sense. Try it with:

    1. Just $PRO_MOVE
    2. Just $PROGRAM_RESET
    3. Just the $IN[] of $PROGRAM_RESET

    One of those should fail, the other two should work. Once you've determined that, it should be possible to proceed.

    I will try these suggestions, see if maybe that fixes the problem. Another cause that I just thought of, is that when I was first debugging the programs, the condition for program reset was $PRO_ACT = False and $Program_Reset. I guess it could be possible that the guy controlling the PLC lied to me when I asked him if he was leaving program reset on, but I still dont understand how it would get past the $PRO_ACT condition. Just strange all around, Kuka also didn't really offer any explanation on why it was happening, mostly just complaining about me using $ for my signals :grinning_squinting_face:

Advertising from our partners