KUKA.LaserTech V3.1.X with NON Trumpf Laser

    Anyone here having experience with KUKA.LaserTech 3.1.X and configuring that for other than Trumpf Laser?


    After facing wall with KUKA support :wallbash: I'm trying to find out whether it would be possible to configure and use KUKA.LaserTech 3.1.X with one other unnamed laser power source when using very simply digital+analog communication.


    What might be the simpliest I/O configuration what LaserTech requires to work? I'm looking for something as simple as adjusting laser power with analog output, starting and stopping laser beam with digital output and checking laser status with some digital inputs.


    I just got to know that LaserTech software has been made for Trumpf lasers having robot interface for more extensive communication.


    We are having KRC4+KSS 8.3.27+KUKA LaserTech 3.1.5 but I think that LaserTech has been basically quite similar since KRC2...

    Edited once, last by tbex ().

    I haven't used LaserTech since KSS 5.4 or so, but I imagine it wouldn't have changed much. And, yes, it's designed entirely for Trumpf lasers. Which I learned the hard way, after a customer bought some KRC2s with LaserTech, then bought lasers and other associated support equipment without ever bothering to ask KUKA about compatibility... and then I got stuck fixing it.


    The good news is, LaserTech's source code is open and editable. The bad news is, it's rather complex.


    The first thing you need to do is work out the signal timing diagram for the laser. What signals it needs, when, and in what sequence. Then it's a matter of finding the closest equivalents in LaserTech. You may end up needing to modify or even eliminate certain options in LaserTech if the laser you have doesn't support them. With the particular non-Trumpf laser I got stuck with, there were certain issues with signals that were pulsed where the Trumpf used steady-state, or inverted logic, or vice versa. Those required a bit of creative code editing in places.


    Fortunately, the LaserTech option is pretty tightly packaged -- all the LT-specific variables added to $CONFIG.DAT are located in a specific clearly-named Fold, and everything else is in the TP subdirectory for LaserTech. So you won't be on a snipe hunt through the entire controller looking for breadcrumbs.

    Thanks for sharing your experience with LaserTech :top:


    I'm not yet sure about laser timing diagram but based some information I suppose it's very similar to basic arc welding. After browsing through some LaserTech files I got an idea whether it would be easier and simplier to use KUKA.Arctech package?


    What you think, would that be possible to get work? Would there be any timing matters? Would that communication be fast enough? Anyway it would be quite easy to test.

    Communication and timing will work the same regardless -- that's dependent on your hardware, not the software.


    ArcTech... maybe. It really depends on the complexity of the signalling your laser requires. If all you need is a simple On/Off and Ready/Error signal pattern, then the easy way out is to write your own KRL. But if you can map the laser's signals to matching signals (remember, you need to match timing and sequence, not just function), then yea, ArcTech would probably work for at least basic laser operations.


    The real bulk of the KUKA TPs isn't in the basic operating code, it's in all the user-interface stuff for enabling "easy mode" inline-form programming, menu-driven configuration, and (this is the biggie) error handling and fault recovery. For instance, one of LaserTech's selling points is that it supports re-starting an interrupted weld, with some configurable parameters to "merge" the newly-started weld with where it was interrupted, without (hopefully) leaving a gap or blob. That's where a lot of the complex coding resides.


    In situations like this, I'll often write my own "bit-banging" KRL code to get basic control of the peripheral hardware, and work with that until I've got a a good handle on how the basics work. Then I'll back-port what I've learned about the signal patterns into the KUKA TP. Most of the TPs are flexible enough that you can do this with little or no re-coding, just some creative use of the configuration parameters. But it does require studying the TP carefully so you have a full grasp of what's going on when you make a change.


    Have you managed to run non-Trumpf laser with lasertech?
    I am trying to use nLight Alta with KRC4+lasertech 3.0
    nlight is controlled by pulse profiles. 50 pulse profile program can be edited in Nlight

    I have, although the laser had to be very similar to a Trumpf. It's been long enough that I don't recall all the details, but a simple example: if the Trumpf uses a digital word for controlling the laser output, and the non-Trumpf laser needs an analog signal, then simply hacking the TP probably isn't going to work. You might need to add a hardware layer.

    I didn't need to modify LaserTech because customer finally bought Trumpf laser and it was easy to continue with LaserTech.


    On the other project there wasn't LaserTech option in KRC2 controller. It was very easy to code own functions for basic communication with non Trumpf laser. But in this case error handling and fault recovery is big issue like SkyFire mentioned. I didn't have time to write standstill monitoring which could be very nice to have.


    On the next project I would prefer to continue writing own functions than trying to modify LaserTech. Standstill monitoring would be quite easy add with interrupt + cycflag commands I think.

Advertising from our partners