A Quick clarification is needed as understanding what the manual describes at times is difficult. If at the beginning of the program we set speed/accuracy to "x" ALWAYS then it will remain at that until it is reassigned by another speed/accuracy command, lets say "Y". The speed/accuracy will be set to "Y" for one point/pose then it will revert back to the "X" ALWAYS value or do you have to reset/re-command it to "X" ALWAYS again? Also how is the speed/ accuracy effected when you CALL another program and in the new program doesn't modify the speed/accuracy.
Accuracy, Speed and the Always commands
-
ericwiz7923 -
April 21, 2020 at 7:01 PM -
Thread is Unresolved
-
-
It is exactly as it states...………..it remains valid until another SPEED value is set but it is missing something else too.
So my explanation for it is:
It remains valid until another value is set that does not include the ALWAYS, then that value will be applied to the next motion instruction, then revert back to the ALWAYS value as specified even if you are using subroutines.
You could also refer to it as you setting a 'default' value to use and ALWAYS return to.
The ALWAYS can be applied to SPEED, ACCURACY, ACCEL and DECEL (to name a few).
If you were using BLOCK or some other OEM's, then you need to specify a speed and accuracy for each motion.
So this method offers an alternative solution, in some cases I like it, in others I don't as it can introduce 'lazy' forgetful programming without attention to detail resulting in 'non optimized' applications.
So to put into context if I had a simple program with:
SPEED 1000 mm/s ALWAYS
ACCURACY 10 ALWAYS
JAPPRO pickup, 100
LMOVE pickup,1
LDEPART 100
;
JAPPRO drop,100
LMOVE drop,1
LDEPART 100
Every Motion would have a max TCP speed of 1000 mm/s
Each location would have a 10mm accuracy radius around it.
However, I need to be more accurate so that I achieve the pickup location and also the drop location.
I also need to synchronize my gripper, so that I am not gripping too early/snatching at it, or then also throwing it/withdrawing whilst releasing the part.
Therefore:
SPEED 1000 mm/s ALWAYS
ACCURACY 10 ALWAYS
JAPPRO pickup, 100
SPEED 100 mm/s
ACCURACY 1 FINE
LMOVE pickup
SPEED 50 mm/s
LDEPART 100
;
JAPPRO drop,100
SPEED 100 mm/s
ACCURACY 1 FINE
LMOVE drop
SPEED 50 mm/s
LDEPART 100
By using this method, my 'key target' positions are controlled specifically with the speed/accuracy changes applied for the 'next motion' instruction only.
The transition moves will use the ALWAYS value instead.
The Speed and accuracy applied for the JAPPRO instruction will be 1000 mm/s and 10mm accuracy.
The accuracy for the LDEPART target will be 10mm
This is common through out Kawasaki Robots, the concept of retention:
If something is changed, then that change could remain effective unless changed again.
Therefore:
ALWAYS specify what you want the robot to do, otherwise it will use a previous value set.
-
So my explanation for it is:
It remains valid until another value is set that does not include the ALWAYS, then that value will be applied to the next motion instruction, then revert back to the ALWAYS value as specified even if you are using subroutines.
Great real world example and thank you for clarifying. Reading the AS Language manual that's how I thought it was supposed to behave but I didn't want to assume that was the case if it didn't state so explicitly. Thanks for the thorough response!
-
You're welcome, glad it helps clarify things.
Also, it touches upon a 'hidden' enemy not necessarily aimed at the ALWAYS, but at the retentive nature of Kawasaki Robots and often can catch people unawares, but can also be used effectively to.
When referencing the AS Programming manual, make note of instructions that include optional 'omitted parameters' (usually highlighted in the command).
Carefully read these, as the 'highlight' indicates something specific to this parameter in addition to it's function that can have an impact on your application.
They can catch some people unawares, whom are just copying someone else's code without referencing the manual for each true function.
So Kudos to you that you are taking the time to read the manual and querying it...….
-
G’day, as this thread is a reference to speed I wonder if there are any thoughts on the following.
On our Kawasaki units we utilise speed as a percentage, ie SPEED100 or SPEED 60 throughout our programs. That in itself is all good, but I have some programs that were put together by others and they use SPEED 100,100 or SPEED 60,60 and likewise for accuracy.
I have been unable to find why this double number is used, or what if any effect this has.
This causes no dramas for us, just seeking to understand.
Thanks.
-
I've never come across the ACCURACY format as a 'double number'.
But the format for the SPEED, in the context you're referring to would be:
SPEED 'program speed', 'rotational speed'.
Usually this format is used when you are re-orientating the tool in linear of circular interpolations because you are effectively rotating the TCP around a fixed point, therefore the 'rotational speed' is speed to effectively control the rotational speed otherwise you can generate JTxx has suddenly changed errors.
Usually programmers assign DEG/S or DEG/MIN as unit to be more accurate, but in cases where this speed accuracy is not required, then they omit the unit and then it is expressed as a percentage.
Hopefully, this will tie in with your application and what you see during the motions.
I would be interested to see an example of the 'ACCURACY' though if you have one?
-
Thank you sir, it now makes sense to me.
I have just been through a couple of the programs and it appears i 'made up' the accuracy statement, though could have sworn i saw it somewhere <Grin>.
-
Lol......I've never come across an accuracy version but Kawasaki do have lots of undocumented commands, so if there is one out there I would not be surprised, but interested to see it.
Yes, your question is quite 'apt' here as the rotational speed is an option and an omitted parameter and when not used. ie in the singular then it is actually set at 100% unbeknown to anyone else (I've just read about this based on your question).
So if you replaced that command you have currently and just used the singular format instead, I wouldn't be surprised if you started to receive JTxx suddenly changed or maximum speed exceeded errors.
(Not that I would advise you to try it just for smarts).
-
Usually this format is used when you are re-orientating the tool in linear of circular interpolations because you are effectively rotating the TCP around a fixed point, therefore the 'rotational speed' is speed to effectively control the rotational speed otherwise you can generate JTxx has suddenly changed errors.
I
What application would this be beneficial/commonly used in? Mig Welding or sealing applications?
-
Mig Welding or sealing applications?
Possibly in MIG welding if you decide to 'hand ball' the AS programming as opposed to using the dedicated weld software which incorporates specific weld commands for speed and wire feed rate synchronisation already.
More associated with sealing applications in my opinion though where uniform bead width, amplitude and shaping is required to be maintained throughout the process especially around any radius where TCP speed varies - resulting in excess/reduction in bead material being laid down.
So this rotational speed is usually integrated for this purpose.
But saying that potatoes, potartoes……….any application that requires re-orientation of the tool really......like icing cakes, fettling, deburring, chamfering.
Any of those that lie under the 'sealing' application banner.