Goodmorning guys! 
I'm pretty new to Kawasaki and starting to learn a lot!
So...now I have this challenge:
I'm using a kawasaki FS06L with D71 Controller europe spec, to unload a pallet of coolers, and place these into multiple stations for coining, measuring and then placing it onto a leaktester line.
The unload of the pallet (including trays) is working with vision!
Now the goal I want to reach is that the robot checks on loosing the vacuum after it got vacuum, so after it picks up a cooler (vacuum sensor kicks in)
Now if it looses the vacuum before I shut down the gripper (it moves through multiples subroutines), I want it to hold, and initialize it's home program, so the operator can put it home position manually and remove the cooler, then continue.
Somehow it just doesn't accept an interrupt in my 4th PC program... how should I solve this? 
Also I am a beginner and could use some help with debugging my programs, because it's a little unstable with multiple variables counting up and down for requesting different vision models etc.
And I'm a little worried with my 32 inputs and 32 outputs being used already, and on top of that I need so include multiple "Handshakes" with a PLC.
Sorry for my bad english, still learning everyday!
Thanks a lot in advance guys! The forum helped me out multiple times already! 
Checking vacuum while moving through multiple subroutines (PC TASK?)
- brordautomation
- Thread is marked as Resolved.
-
There are several elements to your question......
But to address your initial question.If you are using the ON/ONI instruction, this is classed as a motion command and cannot be used in a PC Program.
QuoteSomehow it just doesn't accept an interrupt in my 4th PC program... how should I solve this?
- Is this the way you are intending to monitor for the vacuum?
- I ask, as it is more common to use the ON/ONI command specifically for this, in which case you have to place it in your main routine.
- ON/ONI starts monitoring and IGNORE stops monitoring.
- Take care using the CALL instruction with this, unless managed, the robot WILL return to the next instruction after the CALL.....and may result in unexpected motion.
- I usually use this with a GOTO instead to prevent that.From the sounds of it though, you want to just hold the process.....until the operator interacts and carry on.
But it depends on just when in the process it can lose the vacuum.....you would be carrying on with no part.
- Or are you intending the operator to check the gripper is working, place the cooler back in the gripper and then carry on?If the operator is a necessity for a stoppage....then simplest way is to just hold the process and let the operator decide the best course of action.
- Get them to check/reload the gripper and just carry on.
- I would be tempted to just use a ONI and CALL vac_fail routine, set an immediate flag and have it 'conditionally paused' inside an IF/END or DO/UNTIL in that subroutine until a. gripper outputs on, b.part detected, c. vac sensor ok d. confirmation by the operator has been received and reset the flag and RETURN and carry on.
- That way if someone just kept pressing cycle start, it would sit in the stoppage routine conditionally until all conditions metMany different ways to manage it, my opinion is always keep it simple as possible.......
-
Dear Kwakisaki! THANK YOU SO MUCH!
I just thought a pc program would be easy for monitoring in the background so I didn't have to make a mess with interrupts through my entire program but I guess it can't be any other way.
I'm currently busy with putting the ONI instructions into the subprograms where it picks up an object, and putting the ignores after my gripper is disabled (Thus: a ignore function at every drop point).
I want the operator to manually move robot (with check-go) into home-pos doing the following: The interrupt will call "lost_object" wherein it will "BRAKE" Then a message will be prompted to my first IFdisplay to inform the operator it lost the object, then set a variable to 1, call go_home, then let the operator remove the lost object from the robot cell, then I want to continue somewhere else in my main program after he pressed cycle start; and in my go_home program it will check that same variable which makes sure that it does the following:
lostobject = 0
MC HOLD
MC PRIME HOOFD,,44
Otherwise it wil continue from where it went into interrupts and go to the next drop point without any object which can result in unnecessary waste of time.
I'm understanding this is a possibility even when all my interrupts are located in different subroutines?
My main program contains a lot of CALL functions so I think this way it is the most "stable possibility"?
By the way, 2 things:
What exactly do you mean with the setting the flag? (want to learn haha
)
And as soon as there is a chance that an object falls on the floor, it must be checked by other staff for deviations because of our high quality guarantee. So it's not the intention to let the operator place anything back in the gripper.
Anyway, Thank you a lot for replying! You inspire me with the knowledge!
Maybe if you're okay with it, we can keep contact using something more real-time than the forum?
Thanks in advance!
-
PC Programs are natively for monitoring, background comms and non motion instructions and have low priority as they sit at the very end of the CPU clock cycle.
Main priority is given to motion planning which is where all your motion instructions are executed and therefore the Main program area or 'foreground task' is for this purpose to maximise efficiently.
Therefore the most efficient way of programming is to minimise non motion instructions by putting them in a PC Program.Unfortunately, when it comes to interrupting the motion planner, then this has to be given priority, so therefore ON/ONI is classed as a motion instruction and prevented from being used in a PC Program.........
When I said 'flag' sorry old habits.......internal signals or true and false markers which get set.
- So if you have individual programs for each part of the process....set a flag at the beginning and clear it at the end and maybe monitor for it to determine what the operator must do to restart after the interruption.
- but you seem to be doing this already with lostobject = 0.......not the only way to do it, you could use TRUE or FALSE, or even 0 and -1......If the operator is not to put anything back in the gripper, then that part of process has not been completed, so therefore I would assume, that needs repeating....so just prime that part of the process from the start of the routine again.
- By having your lost object routine to look for the 'lost object' flag in conjunction with a CASE statement to select the correct program based on process markers and MC PRIME xxxxx that way......excluding the step no......PRIME/MC PRIME will always prime from step 1 as a default without needing to enter a step no.
- In the process routine always check at the beginning if a 'lost object' marker is set and then lock in a conditional statement and IF Panel message to force the operator to go into Teach Mode, manually move the robot clear, then Check/Go which would include motion to home, when it gets home, look for the dedicated signal for home and THEN reset any lost object/process markers.
- So if the operator was to press cycle start.....nothing would happen...until recovered to home and home dedicated signal is set and flags reset.
- Therefore you will always be in the correct program, correct location to restart that part of the process.Using PRIME and a step no. in automatic is not something I would recommend unless the step no. is part of the process that does some conditional checking first, otherwise you could move the robot to ANY location, and the PRIME,,step no may drive the robot through something.
- However, I am not saying it's wrong, just something to consider perhaps......I prefer to share any knowledge I have via the forum as it may benefit others, but feel free to PM me, but I would recommend utilizing the forum as much as possible, as there are a lot of users who frequent it and many ideas and comments from several people aid to the learning experience, plus as you get more experience, you'll assist others too...
-
Can you tell us what kind of gripper are you using?
-
Hello all, I'm using a vacuum gripper, how to explain this? A sucker which moves down until it gets a vacuum!
I understand kwakisaki and I will use the forum as much as possible!
However, I have a really large program so I don't know if it's appropriate to post it...
I want to keep it simple but the disadvantage is: If I let the robot just continue after its motion stopped due to the interrupt when losing it's vacuum. It will proceed with the movement, thinking it's placing a cooler in the coining station, which requires PLC clearance etc. all and all it takes too much time because it's gonna be placed in 24/7 automotive production!
What if I let it jump into a lost_object subroutine with my interrupt an just make it hold, without the homing etc. then the operator removes the lost object from robot cell. then when it presses cycle start (EXT.Cycle start via PLC) it start all the way on top of my main program.
Would my lost_object program look like:
.PROGRAM lost_object()
BRAKE
aantalgepakt = aantalgepakt+1 ;this is to tell my vision system it skips the current cooler handling so it's starts looking for the next one)
currmodel = currmodel+1 ;ditto
IFPDISP 1
IFPWPRINT 1="LOST COOLER, GO TO HOME-POSITION, CHECK ROBOT CELL AND RESUME WITH CYCLE START"
lostobject = 1
TWAIT 5 (for displaying the message above, because in my home program it will immediately print something else!)
CALL go_home
.END
The cycle through my home program, which is okay, then cycle start.
Then on the end of my home program i made this:
if Lostobject= true call hoofd (which is dutch for main)
on the start of my main program i made:
IF lostobject = true then goto afterlost (So it moves to the label afterlost, which is located where I want to let the robot continue!
I hope this is gonna work! -
Hi guys!
It worked out!
But now i'm just curious what you guys think of my program... :$
If anyone is interested then I'm willing to share via PM!Cheers guys!
-
Excellent, I was just reading through, but difficult to visualize complete operation without 'hands on'.
- I am very specific, so I would also 'destruct' test it also to see if any bugs present.
- If any are found, you at least know that the 'core' programs are working.......and then resolve them etc.
- If it operates in the way you intended, then WELL DONE.....always nice to see the results of hard work.You can post your filesave, it is allowed, but takes long time to scroll through............full file save is not too large.....but takes long time to scroll through it.
- If I post code, I try and limit it to the main areas - maybe just program data.
- Check out variation of SAVE command switches (/p, /l, /r etc) in AS Manual - Section 5.3 I think.........
-
.....'destruct test'.......sorry old habits again..............
- Not in the literal sense obviously, but when I make mods/create new I always test it out for holes/bugs....that's what I meant.
- If I can introduce issues conventionally from a 'day to day' operation, then I consider it potentially weak...
- In my experience, operators (not intentionally) highlight these during use, especially if there is an element of interaction on their part.
- The worse part of applying a change is being half way up the road and receiving a phone call.
- Returning and discovering an oversight......I call it 'belt and braces'.
- Purely dependent on just how complex the mod/change has been of course........Which SWAIT commands are you referring to - there are many?
- Never use SWAIT with signals within parenthesis (brackets), the command is 'evaluated' instead.
- The result is NOT the signal no. you are waiting for, so therefore it doesn't wait.
- I would check this......but definately remove the parentheses from all commands like:
- SWAIT (i_wt_aanwezig), SWAIT (i_palletinpos), SWAIT (-i_metenbezet) etc etc...
- I think this maybe where your problem is. -
Ah thanks bro!
I did the parentheses because the guys that worked on the robot before, used that same method! But thanks a lot!
How do the parentheses affect the structure controls like IF SIG (2002) THEN.. etc.?
Thanks! -
They are required in that context....'if it is THEN' Do something......if not, GOTO or ELSE or END.
- So very basic OR gate if required.SWAIT, this an actual condition command it is dedicated for exact SIGNALS status match and prevents forward planning until the signal condition matches the command.
- It also produces a 'pause' icon on the teach pendant - teach screen too.You can also use a WAIT command, but WAIT is not specific to signals, it can have multiple conditional checks such as signals, variables and timer values - but does not produce a 'pause' icon.
You could write it like:
WAIT (SIG(1001) AND SIG(1) AND NOT SIG(2001)); is exactly the same.Usually it is purely the programmers preference that you get variations of 'waiting', and so don't be surprised if you come across WAIT for signals instead of SWAIT.
- I believe SWAIT was introduced in the AS language later on as a command.
Advertising from our partners
