custom sub module ignoring "IF"

    Hello everyone,
    I really can't figure out a weird behaviour I'm experiencing with a custom .sub file.§

    I created a custom .sub file to perform some activities in background, basically how to react to errors and some other events (I/O).

    Here's a piece of code to look at:

    The issue is in LINE 12, where despite having an IF $STOPMESS==TRUE THEN, the msgnotify and the SOMEPROGRAM lines are executed anyway each cycle.
    It seems that for some reasons $STOPMESS is always detected as TRUE.

    I'm not adding more info just because I believe this is purely code-related, as the robot was not in error state during the test I have done.

    Anyone has any insight on why it is ignoring the IF?

    Edited 2 times, last by ParametricGuy (August 22, 2023 at 12:30 PM).

  • Go to Best Answer

  • MOM August 22, 2023 at 1:02 PM

    Approved the thread.
    • Best Answer

    $STOPMESS is False as long as there is no condition halting the robot. What is that state of $STOPMESS when you perform this test? What is the value of CLTYPE?

    Also, I hope you're changing CLTYPE as soon as SOMEPROGRAM runs once, otherwise the SPS will keep running it, and posting the Notify message, as fast as it can loop. Doing this kind of thing in the SPS needs some sort of one-shot to avoid hammering the message window with thousands of messages in under a minute.

    I figured out the issue, basically $STOPMESS is true whenever the Motion is not enabled (so also when you are in T1 and you are not pressing the deadman).

    I repeated the tests and that's the issue, as long as I start a program in AUT, or I press deadman in T1, $STOPMESS turn False as intended.

    I solved the issue by including a IF $PRO_ACT == TRUE THEN line of code before the SWITCH, this should prevent the switch to call programs when i'm not actually running any program.

    Quote from SkyeFire

    Also, I hope you're changing CLTYPE as soon as SOMEPROGRAM runs once, otherwise the SPS will keep running it, and posting the Notify message, as fast as it can loop. Doing this kind of thing in the SPS needs some sort of one-shot to avoid hammering the message window with thousands of messages in under a minute.


    Actually I'm not because I want the subprograms to be called continuously until the error gets solved, otherwise the user might bypass the system by acting on what the subprograms are acting upon.

    The msgnotify keeps getting posted, despite not being saved in any log this can actually be a minor issue that's true, the question here is how to run the msgnotify only once (but must get posted again after the issue is solved and the program resumed) while continuously running the subrpograms. :thinking_face:

    Quote from ParametricGuy

    The msgnotify keeps getting posted, despite not being saved in any log this can actually be a minor issue that's true, the question here is how to run the msgnotify only once (but must get posted again after the issue is solved and the program resumed) while continuously running the subrpograms. :thinking_face:

    It's not a minor issue -- I've seen KRCs get locked up and forced to reboot by high-frequency "hammering" of the message window. Message functions also execute slowly, slowing down your entire SPS.

    What you need is a one-shot or edge-detect. Usually implemented using a Boolean variable, like so:

    This would keep SomeProgram running as long as $STOPMESS is True, but MsgNotify only once every time $STOPMESS changes from False to True.

    Also, using $PRO_ACT may not do what you want. Generally, $PRO_ACT and $STOPMESS are inverted relative to each other -- most events that make $STOPMESS True also turn $PRO_ACT False.

Advertising from our partners