$CYCFLAG mysterious behaviour

  • Hi,


    I´ve been fiddling around with $CYCFLAG´s lately and I found it very odd that I have a hard time getting them reset.

    Originally I was hoping to set a $CYCFLAG from a *.src and later on reset it in an extended submit with $CYCFLAG[X]=FALSE as I understand is the way to reset it.

    From the KSS 8.5 system variables documentation I can see that it reads:


    "Cyclical evaluation of cyclical flags can be activated by assigning a Boolean

    expression in a robot program. Assignment of a Boolean expression

    in a submit program does not result in cyclical evaluation."


    There is nothing stated about resetting a $CYCFLAG in a submit program so I figured I´d test it.

    This did not turn work as intended and I dumbed down the code and tested some more. -> did not work

    And figured for sure atleast they can be reset through the robot interpreter. -> did not work


    The program below does not reset the $CYCFLAG, and yes I tested that it is not only the user interface that is slow. It really does not get reset or cleared.


    KSS is 8.7.3 and this is tested on officelite running on a hyper-v machine.


    Any ideas? Have I misunderstood this completely? or can anyone else reproduce this?



    The code:



    ** update: they do eventually get reset but it may take minutes?!?

  • the whole idea behind cyclical flags is that you assign expression to it - once.... after that just evaluate it (read it) and stop updating it. you are doing the opposite... you are constantly writing new expression to cyclical flag and interfering with its existing value.


    consider this robot program (not submit). note that inside loop we are not doing anything with the flag. keep moving $OV_PRO slider and look at the flag value. cyclical means that flag value is constantly (cyclically) updated while program is doing something else.


    Code
    DEF TEST()
    
    ; turn flag on if OV_PRO is 50% or higher
    $CYCFLAG[1]=$OV_PRO>=50
    
    LOOP
       WAIT SEC 1 ; simulate something else being done
    ENDLOOP
    
    END

    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

  • Submit itself is a cyclical task that gets processed continuously.

    not sure why would one need cyclical flag there...

    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 think you are getting the wrong idea.

    The submit is beside the point. I can assign a $CYCFLAG to whatever in a robot program *.src just fine and it will be assigned almost instantly. I can also change the assignment to something else and the assignment will update just fine. But I cannot set it to FALSE (stop evaluating). Or atleast the assignment will keep on hanging there for a couple of minutes before it actually gets reset.


    What I wanted to do in submit was set the given $CYCFLAG=FALSE under a specific set of circumstances.


    But when I couldn´t get that working I tested it further I do not seem to be able to even set a cycflag to false in a robotprogram.


    The code provided is dumbed down and does not serve any real world purpose anymore but illustrates my issue.


    Even if I do this I cannot get it reset within a decent time:


    Edited once, last by Hes ().

  • manual looks pretty clear on things for me. Cyclical evaluation occurs only in Robot program - as intended. in other interpreters it acts like a normal flag. Submit interpreters are not high priority tasks, they are not synchronous to robot program. why are you trying to do things backwards? use things as they are intended to. and cyclical flags are meant to be used in robot program - not submit. you can assign expression to it ... and forget about it. when program is deselected you can reset the flag in submit if that is what you need.




    note that in this example submit is not used - program is run in robot interpreter.

    also outputs are replaced with flags so they can be set while robot program is running.

    cyclical flag is assigned expression at the begin of program only and the value is still changing according to expression - until cyclical flag is turned off (IF statement).


    pasted-from-clipboard.mp4

    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

  • For who might be interested.


    What I wanted to achieve was a generic error handler. That would be as flexible as possible to use.

    I wanted to be able to catch e.g. variables out of range at specific checkpoints, inputs during motion, etc.

    After the above discussion I´ve concluded that it is not an optimal solution.


    The code below "works" but still leaves alot of gaps. e.g. there is to my knowledge no way of deactivating the cyclic monitoring for error triggering if the program was deselected or lines skipped...

    Code is in no way optimal and it is possible and even likely to end up at stalemates. And it will never be an interrupt no matter how much lipstick you put on it. Even as this was meant for errors that do not require optimal response time. As an example it was meant for errorhandling after robot drops a label and it does not really matter how quickly it stops. It was not meant for searching for labels from a stack that will make a hard stop in a few mm´s


    My initial thoughts were that using $PROG_INFO[1] with interrupts would not be useful as the program pointer would have escaped into the ISR and would provide no information of any use. I do not know this with certainty. Intention was to indicate where the pointer was when the error was triggered and not trap the user in a ISR with no knowledge or background how they ended up there. That is the reason I went with this approach. I also liked the idea of using ROB_STOP() to actually prohibit motion and jogging until the error was cleared. Which to my knowledge is only usable in a submit.


    At this point I do not see an easy way to make a flexible interrupt that would always be declared and regardless of which program was started (Interrupt declared and set to on from submit?). And a way to trigger said interrupt with either signals, ins, outs, flags, vars, etc.


    I will mark this thread as resolved but leave it here for whoever it may benefit.


    This sub does the errortrapping and handling:


    This would be declared in config.dat:


    And this is an example to test with:

    Edited once, last by Hes ().

Advertising from our partners