Vacuum timeout Program

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.

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 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.

.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.

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

.INTER_PANEL_D
1,4,1,"OFF     ON","",""," VACUUM 1",10,2,4,0,9,0
2,4,1,"OFF     ON","",""," VACUUM 2",10,2,4,0,10,0
3,4,1,"OFF     ON","",""," VACUUM 3",10,2,4,0,11,0
4,4,1,"OFF     ON","",""," VACUUM 4",10,2,4,0,12,0
15,9,1,4,9
.END
.INTER_PANEL_TITLE
"",0
"",0
"",0
"",0
"",0
"",0
"",0
"",0
.END
.INTER_PANEL_COLOR_D
182,3,224,244,28,159,252,255,251,255,0,31,2,241,52,255,
.END
.PROGRAM autostart2.pc()
  .tr1 = FALSE
  .tr2 = FALSE
  .tr3 = FALSE
  .tr4 = FALSE
  .tmr_max = 20
  TIMER 1 = 0
  WHILE TRUE DO
    IF SIG (9) OR SIG (10) OR SIG (11) OR SIG (12) THEN
      IF (SIG (9) AND .tr1 == FALSE) THEN
        .tr1 = TRUE
        TIMER 1  = 0
      END
      IF (SIG (10) AND .tr2 == FALSE) THEN
        .tr2 = TRUE
        TIMER 1  = 0
      END
      IF (SIG (11) AND .tr3 == FALSE) THEN
        .tr3 = TRUE
        TIMER 1  = 0
      END
      IF (SIG (12) AND .tr4 == FALSE) THEN
        .tr4 = TRUE
        TIMER 1  = 0
      END
    END
    IF SIG(-9) THEN
      .tr1 = FALSE
    END
    IF SIG(-10) THEN
      .tr2 = FALSE
    END
    IF SIG(-11) THEN
      .tr3 = FALSE
    END
    IF SIG(-12) THEN
      .tr4 = FALSE
    END
    IF TIMER(1) < .tmr_max AND (SIG(9) OR SIG(10) OR SIG(11) OR SIG(12)) THEN
      IFPWPRINT 1 = "Time left: " + $ENCODE(.tmr_max-TIMER(1)) + " s"
    ELSE
      SIGNAL -9, -10, -11, -12
      IFPWPRINT 1 = " "
    END
  END
.END

I'm glad that my code helped you!

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.

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.

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.