Tracking distance travelled by TCP for adhesive refilling

  • Hello, I'm working on an adhesive dispensing project where our application has a cartridge on it that has to be manually filled and does not contain enough to cover the entire part we are utilizing.


    I was looking for help to come up with a solution where the program can track the distance traveled by the TCP and call an interrupt that pauses the program so the cartridge may be refilled and then continued until the part has been covered. I am needing to do this programmatically because due to the nature of the project, the distances/speeds between passes may vary as we further develop. Or maybe there is an alternative route that is less complicated.


    I am utilizing a KRC4 controller running KSS 8.6.


    I've attached a snippet of the code below for reference:

  • Why are you trying to add up everything yourself. You can use $distance. Its nulled whenever you do not blend so over a blended sequence it adds up.


    Fubini

    Thanks for the tip, I'm currently doing my development in KUKA.Sim while waiting for some stuff. Do you know if this variable does not get calculated in this environment, or do my point shift calculations somehow cause it to be nulled/0? When I try to monitor the value it remains at 0 throughout the program. I imagine it shouldn't be the calculations, as the advance run pointer works fine and the motions are blending properly.

  • You simulate directly with kuka.sim or do you simulate with a office lite connected to Kuka.sim? In the first case its not supported. So no update in this case because it does not use the robot controller under the hood.


    Fubini

  • Hi, some alternative solutions:


    Why not put a sensor or three (depends on the shape and whether the cartridge is attached to the robot) into the cartridge? Then you could just see when it's empty from the inputs, no guesstimation needed.


    Could run a procedure in a submit that adds differences between previous position and current one when some flag is raised. No need to calculate movement lengths then. It's not going to be as mathematically rigorous due to timing issues, but I am going to assume you don't intend to use all the liquid/gas down to the last molecule :) Also significantly easier to implement coding wise.

  • You simulate directly with kuka.sim or do you simulate with a office lite connected to Kuka.sim? In the first case its not supported. So no update in this case because it does not use the robot controller under the hood.


    Fubini

    Just KUKA.Sim, no OfficeLite, so that makes sense. Thanks for your help

    .

    Hi, some alternative solutions:


    Why not put a sensor or three (depends on the shape and whether the cartridge is attached to the robot) into the cartridge? Then you could just see when it's empty from the inputs, no guesstimation needed.


    Could run a procedure in a submit that adds differences between previous position and current one when some flag is raised. No need to calculate movement lengths then. It's not going to be as mathematically rigorous due to timing issues, but I am going to assume you don't intend to use all the liquid/gas down to the last molecule :) Also significantly easier to implement coding wise.

    I would love to for the sake of simplicity to but unfortunately, this is a research project, and the adhesive cartridge was given to us by our customer and I'm unable to modify it. I will ponder the submit interpreter idea for sure, might be an relatively easier solution.

  • What pushes the plunger of the cartridge? It should be possible to place a sensor on that, even if it's just a temporary mount (some hot glue, or even light-duty Loctite adhesive).


    You mentioned changing speeds -- does the adhesive extrusion speed also change as the TCP speed changes? If not, then the TCP distance travelled won't match up with the extruded volume -- if the adhesive extrusion rate remains constant, then running the same path at 100mm/s will use up much less adhesive than running it at 1000mm/s.


    I would avoid using an interrupt, in any case. It's unnecessary complexity. I would break up the overall program into adhesive segments, and check the adhesive fill state (sensor, counter, whatever) between segments. Then set the "stop for refill" limit to leave enough "extra" to do your biggest, longest segment. That way, you never leave a segment short of adhesive, but once you're below the limit, the program won't run the next segment until you refill the cartridge.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account
Sign up for a new account in our community. It's easy!
Register a new account
Sign in
Already have an account? Sign in here.
Sign in Now