As far as I know it is a paid option. So if you did not buy it it will not be available.
Btw. Isn't TIA Siemens?
Fubini
As far as I know it is a paid option. So if you did not buy it it will not be available.
Btw. Isn't TIA Siemens?
Fubini
Fubini
Forgot #tool or #base as first parameter after the position.
Yes. If e.g, e1 is at 270
lin_rel {e1 -270} #AS_PROG
should bring it to zero. The same can be achived by
slin_rel {e1 -270}
Here #as_prog is not needed since this is the default for spline.
Fubini
AS_prog should also work on relative motion commands.
Fubini
Yes. Lookup #AS_PROG.
Fubini
No there is neither. Spline is bounded only by memory size. Your conclusion at first glance looks unplausible to me. Planning and sampling priority is less than lrs_hp where hp stands for high priority. So that if lrs_hp is not resumed fast enough would require some sort of priority inversion. Something I would not expect to happen, but who knows ...
Fubini
We agree on that. And data reduction is possible in many cases. I would like to know if the is a hard constraint (like a maximum number of points per second) so I can 1) assess the need for data reduction beforehand, or 2) program a reduced speed in point-dense areas
No there is not. In blending you can not get faster as programmed by the two moves you want to blend over. Also you always have to be able to stop at the intersection point if blending is not possible. The reachable velocity therefore is mostly determined by the accelaration for short distance LINs. If distance of LIN is short you no longer get a trapezoidal velocity profile (having a constant velocity phase) but a triangle shaped one connecting maximal acceleration to maximal deceleration. Obviously you also want to keep blending velocity as high as possible, i.e. blending should not start when you are already in the deceleration phase (which is probably what you are experiencing). This is achieved best with using C_VEL instead of C_DIS blending. C_VEL basically tells the system to choose blending radius such that velocity does not need to be reduced. Also blending is automatically reduced by the system to half point distance no matter what you programmed as blending radius.
Fubini
Take a KRCDiag when the error is shown and send it to KUKA HQ support. R&D can find out by studying the task switch monitoring log files inside the diag files which operation is taking up too much time so lrs_hp is not executed according to it's cycle. Nothing much else you can do.
Fubini
Then how about posting your program? Any other messages? Usually there is also one stating the line of code with invalid instructions. Maybe it is only to big. Try the same with a small example.
Fubini
Expert programs or inline forms?
In both cases you can in principle use the colon operator : aka geometric operator. How exactly and where to apply it to depends on the above question.
Fubini
Sure. Read about the : operator aka geometric operator. Just use forum search and you will find plenty info about shifting/offset points.
Fubini
Because its percentage value and more than 100% is not possible. Lookup the logic inside bas.src.
Do actual and commanded velocity fit?
In general you should give a lot more details about your specific problem. Otherwise help will only be very limited.
Fubini
The same way as mentioned above. This is not different for a KSS running on a KRC4 based controller. In expert programs you can assign values up to 3m/s directly to $vel.cp. In case of inline forms you are limited to 2m/s.
Funini
Install everything from scratch starting with Windows Image from KUKA.
Fubini
make sure the velocity limit would slow down my tool after setting velocity limit
I monitored $VEL_ACT while running to see the speed reduction
Before limiting velocity, $VEL_ACT topped out at 180 mm/s
After limiting velocity, $VEL_ACT topped out at 15mm/sI am not sure why I wasn't getting up to the set velocity. My LIN move seemed long enough to accelerate to 200 mm/s.
If I understand this correctly you restricted velocity to 20 mm/s by setting this limit in the safety configuration and when running your program you see $VEL_ACT reaching 15 mm/s. Is this correct?
Then probably $SR_VEL_RED is true and $SR_OV_RED in $custom.dat is set to 75 meaning non safe internal override control aims at 75% of the configured safety velocity restriction. $SR_OV_RED can be set up to a value of 95%. Since override control can lead to overshoot over and some oscillations around the velocity bound there is a safety margin. The overshoot will be maximal when entering constant velocity (acceleration needs to be reduced to zero) and fades out over time. Its not a planned trajectory but control! The higher the setup dynamics of the robt the higher the overshoot needs also to be considered. So for high speed/accelaration/torque applications the safety margin in $SR_OV_RED needs to be set to smaller values than for low speed/acc/torque applications.
Btw. $SR_OV_RED and therefore override control is not needed if you would use spline SLIN instead of old motion LIN. Here the mechanism is no longer control (a beforehand planned trajectory needs to be stripped down during execution) but the reduction is considered differently and the overshooting override control is not applied.
Fubini
Thats not what AUT mode is for. For this there is EXT or only stop the robot without loosing drives when your light curtain is hit. The latter might not be allowed due to safety regulations.
Fubini
No. There is not afaik. If you would use something like UserTech and create your own inline forms you could always append it.
Fubini
Not really. I think the bottleneck here is the KRL compiler. The compiler needs to analyze the file line by line so basically the duration only depends more or less on the number of lines of code.
Fubini