Vacuum timeout Program

    Hey guys,

    Is there a possibility to query a signal state, as soon as it becomes HIGH, a timer of e.g. 20s should expire. After this time, the signal should be switched off.

    However, if the signal or another air output is activated again, the time should start counting from zero again.

    I have tried this in a pc.program:

    SOUT 2009 = 9 OR 10 OR 11 OR 12

    STIM 3010 = 2009, 20

    IF SIG (3010) THEN

    SIG -9,-10,-11,-12

    END

    My problem:

    the time is not reset if one of the signals mentioned is switched HIGH again in the meantime.

  • Go to Best Answer

  • Fubini November 7, 2023 at 12:38 PM

    Approved the thread.

    you can use TIMER or UTIMER function to scan the signals. For example:

    IF SIG(9) OR SIG(10) OR SIG(11) OR SIG(12) THEN

    SIGNAL 2001

    END

    IF SIG(-9) AND SIG(-10) AND SIG(-11) AND SIG(-12) THEN

    SIGNAL-2001

    END

    TIMER 7 = 0

    WHILE SIG(2001) THEN

    IF TIMER(7) > 20 THEN

    SIGNAL -9,-10,-11,-12,-2001

    END

    END

    Quote from dm.bogachev

    Hi!

    If you need to switch off the same signals, consider PULSE instruction.

    And in your case, if condition goes right after the STIM command. It checks the signal once and then program goes further. You should use SWAIT command and then switch off the signals.

    This will only work in programs, but i would like to switch my vacuums also on my IF-Panel.
    So there is no option for a "MONITOR COMMAND" in which I can execute two commands.

    This also won't work:

    STIM 3009 = 9 OR 10 OR 11 OR 12, 20
    SOUT 2009 = 3009
    ;
    IF SIG (2009) THEN
    SIG -9,-10,-11,-12
    END

    because, the timer is not reset if one of the signals is switched on again in the meantime.

    The STIM function only works with one signal although it allows "AND" and "OR" :frowning_face:

    This example also do not work because:

    Quote

    My problem:

    the time is not reset if one of the signals mentioned is switched HIGH again in the meantime.

    Quote from dodasch

    This will only work in programs, but i would like to switch my vacuums also on my IF-Panel.
    So there is no option for a "MONITOR COMMAND" in which I can execute two commands.

    Consider using an autostart background program. You can add a button on your IFP with some internal signal and process it in background task. You also can add there some logic, which can reset TIMER as you want (Thanks Alexandru for idea). You can add in this background task (or made another) with something like. It will reset timer in Alexandru's code.

    Code
    .PROGRAM autostart2.pc()
    WHILE TRUE DO
        IF (SIG(9) OR SIG(10) OR SIG(11) OR SIG(12)) AND SIG(2001) THEN
            TIMER 7  = 0
        END
    END
.END

    If you are using WHILE DO to execute a function within a PC Task (Not the WHILE TRUE DO as above).

    The rest of the PC Task will not be scanned/executed until the WHILE DO conditions are met.

    As a single function PC Task, then of course it is no problem.

    Below is an alternative example without WHILE DO for the function and includes IF panel data to display status of the outputs and toggle switches to activate/deactivate the outputs.

    It is not usually recommended to have buttons tied directly to outputs as these can be pressed during normal operation which may cause problems, so you should consider some conditions to prevent it.

    Thanks for your detailed reply, but again:

    The main problem is, that the timer gets not reseted, as soon as one of the vacuum circuits is switched on again.

    ==============================

    This does the same as the code above:

    STIM 3009 = 9 OR 10 OR 11 OR 12, 20
    SOUT 2009 = 3009
    ;
    IF SIG (2009) THEN
    SIG -9,-10,-11,-12
    END

    ==============================

    I need something to intercept a signal edge, as soon as a signal switches HIGH, a flag should be set and the timer should start.

    If the signal remains HIGH, the time should still expire and the vacuum should switch off.

    BUT: As soon as another vacuum signal switches to HIGH, the timer should be reset.

    This prevents the vacuum from being switched off during operation.

    Quote from dodasch

    BUT: As soon as another vacuum signal switches to HIGH, the timer should be reset.

    This prevents the vacuum from being switched off during operation.

    I think that if you will remove the .mi.trigger == FALSE from kwakisaki's code, the timer will be resetted every time the signals become HIGH. Now, as I can see, .mi.trigger blocks the first IF condition (IF ((SIG(9)==TRUE.....) after the first time any of signals became HIGH (because .mi.trigger became FALSE again only after .tme.dly-0.1 or if all the signals are FALSE)

    So, if you need to reset timer EVERY TIME, THEN ANY OF SIGNALS are HIGH, then just remove (.mi. trigger == FALSE) part

    IF ((SIG(9)==TRUE) OR (SIG(10)==TRUE) OR (SIG(11)==TRUE) OR (SIG(12)) AND (.mi. trigger == FALSE) THEN

    Quote from dodasch

    this will causing, that the timer won't reset. Because the Signal stays HIGH.

    Well, it will RESET timer every time, the signal stays HIGH, my fault

    But if you need some kind of rising edge, then try this. It's a bit bulky, but should work

    Edited 2 times, last by dm.bogachev (November 15, 2023 at 9:55 AM).

    • Best Answer
    Quote from dodasch

    I think there is no way around setting a flag on a rising edge to reset the timer when vacuum signals are set again.

    Incorrect.

    You can utilize the SFLP command for this purpose as well as other methods of detection.

    If you had clearly identified your intentions from the start instead of providing ambiguous information like the following:

    Quote from dodasch

    Is there a possibility to query a signal state, as soon as it becomes HIGH, a timer of e.g. 20s should expire. After this time, the signal should be switched off.

    However, if the signal or another air output is activated again, the time should start counting from zero again.

    This is what my initial example solved.

    There is no mention of whilst an output is HIGH if another output becomes HIGH.

    Your initial statement suggests AFTER completion if another output is activated again.

    The attached video displays a revised solution using SFLP command, CASE and PULSE commands.

    It's a bit intermediate to understand but this code works better than the code from dm.bogachev above!

    The code from dm.bogachev has an overlap with the timer somewhere.

    Sometimes the vacuum is simply switched off or you have problems switching it on because you have to press the interface panel button twice.

    Thank you for your reply and I apologize if I have not expressed myself correctly

    Quote from dodasch

    It's a bit intermediate to understand but this code works better than the code from dm.bogachev above!

    Nothing intermediate at all, that's AS language right there in the same language dm.bogachev is using.

    May be you are referring to structure and commands, ease of reading, ease of execution etc.

    It is just an example remember, if it was something I was going to deploy onto a system, it would be written very differently.

    That's what makes AS sooo powerful and flexible, there is no 'text book' method or document on how you program an application.

    You have a book of commands (just like a toolbox full of tools), sometimes we use an alternative tool instead of using the correct tool to accomplish the same thing.

    This is why it is better to be 100% transparent about your application when it comes to Kawasaki and using Robot Forum, many examples, many solutions exist so it is definitely worthwhile grabbing a beer, crunching the manual and if you have it (KRoset), start key bashing and just see what you can achieve.

    I'm sure you'll be pleasantly surprised.

    The code is just a bit difficult for me to read because I'm not familiar with some of the tools, such as the SFLP command.

    But it's true, AS language is powerful, precisely because it's easier to reach your goal with the individual tools than with conventional programming languages. But you have to know when to use the right tools.

    I'm also not always sure whether I've chosen the easiest way or whether the code could be written even shorter.

    The forum is perfect for that, thanks for your help!

    Quote from dodasch

    The code is just a bit difficult for me to read because I'm not familiar with some of the tools, such as the SFLP command.


    But it's true, AS language is powerful, precisely because it's easier to reach your goal with the individual tools than with conventional programming languages. But you have to know when to use the right tools.

    You know what I'm going to say already - as I stated it in my last:

    Quote from kwakisaki

    many solutions exist so it is definitely worthwhile grabbing a beer, crunching the manual and if you have it (KRoset), start key bashing and just see what you can achieve.

    Your comment below I hear ALL the time:

    Quote from dodasch

    I'm also not always sure whether I've chosen the easiest way or whether the code could be written even shorter.

    This shouldn't be a factor.

    - The right way is when your program works to the specifications required 100% of the time.

    - The wrong way is when your program doesn't work at all or only works a % of the time.

    So I'll ask two very simple questions:

    1. What do you mean when you say easiest?

    2. What would you accomplish by making code shorter?

    Ever heard of KISS.

    Adopt this direction from the start and you'll never fail.

    Try to run before you can walk will result in you falling over time and time again.

Advertising from our partners