There are detailed instructions in the "KAREL MANUAL ".
[attach=40477,'none','false'][attach]
Thank you for the reply! Unfortunately, the manual did not have what i was looking for; as I mentioned I want to be able to center as well as realign everything used by both the TPFUNC and TPDISPLAY routines.
Hey everybody,
I am working on a Karel program right now that calibrates a peripheral camera and figures out a relative space between the two so that it can offset TCP data based on results of image. Anyway im working on the UI aspect of it now, I am looking to make a routine that takes in the data fed to it from the TPFUNC routine and center/aligns on the teach pendant so it looks nice for the user.
I hope my question made sense, I've been programming robots for a fair amount of time but am newer to karel programming so everything helps!
Hey everybody,
So we’ve been working with a new application that we’ve been using to replace GMAW, or really any arc welding in-general; we’ve attached a handheld laser welding gun to the end of a robot— we’ve got parameters related to the welding all done and now we’re about to run it in auto, all the moves in the welding path are at 15mm/sec when moving in T1, what’s a rough estimate I can expect to slow them down to when moving in full auto?
I have a passing knowledge of the laser system. I am a decently competent general robotics guy, but welding is not my strong suit. I know enough about the laser systems to be dangerous, but mostly I only ever need to make minor adjustments to the weld location if the need arises. I have only ever created welding programs in practice and have never tested any program I've written.
We use remote laser welding. I know that we also use the YLS 6000, But I believe we use an RLSK 3D scanner. We use the point and shoot method. I honestly didn't know that on the fly was even a thing. I found your post to be quite informative.
If you don’t mind me asking, did Valiant integrate that system? The only reason I ask is Valiant normally uses RLSK for beam-delivery and IPG for beam generation.
Since you guys are doing point & shoot, does the part allow for you to hit multiple welds from one location or do you guys hit welds one at a time? On-the-fly is really cool, especially if you have quality software to build the process on like RLSKstudio; a lot of the time though it can be a lot bigger hassle than anything, most people think because the robot is constantly in motion, that on-the-fly is the best route to go and if we’re speaking in terms of cycle time it definitely is. Customers see that and they automatically want to use that process, I always advise that if we’re still able to meet production and cycle-time with point and shoot than that is easily the best method; this is because of practicality, as I mentioned, building on-the-fly processes’ is essentially building a OLP except it can be a lot more difficult. It’s nowhere near as practical as point and shoot, as you mentioned sometimes you have to make mirror adjustments; with OTF you have to go into the software and figure out when the “Trigger” (the DO that tells the laser to start firing) sends the signal relative to where the TCP is over the fixture based on your reference point. Because of this you normally need either more people to maintain the process, or highly skilled people because not a lot of people know robotics, simulation, lasers, and welding so it can be hard to implement and keep running.
So due to GM’s autogenous laser welding standard, we can’t particularly just go over a keyhole that fails— it has to specifically be repaired using GMAW or as I mentioned a handheld laser welding gun with a wire feeder. What your talking about seems like a general rework or a process that’s more suitable to fixing missed welds as opposed to welds that fail due to standards.
Do you guys have a remote laser welding application or is it a wobble head? Scanner optics are normally fairly bulky with a big optic so they can have a wide FOV; wobble heads or regular welding heads have a very small opening that the beam comes out of and they can really only weld seams or areas the robot moves the head around.
With robotic remote laser welding, there pretty much two different variations of the process: point & shoot and on-the-fly— if you have laser welding cells, I assume you’re familiar with these terms, but I’ll write a brief description for anybody that doesn’t still. So scanner heads/remote laser welding heads generally have two mirrors attached to galvanometers that sit on both the x and y axis, if you have a 3D head, there’s a mirror attached to the z-axis to help adjust the focal length for a number of reasons— this allows programmers to make different shapes from stitch welds, circles, infinity signs, etc. Due to this functionality we get our two main processes, point and shoot is where to robot comes to a complete halt and hits one weld or multiple welds based on weld location and scanner specs; on-the-fly is when the robot lays down the weld in-motion, it’s essentially an OLP depending on the software you use. The software takes your weld parameters and builds a path program for you with custom acceleration and deceleration values based on a point-of-reference set in the software relative to the TCP of the robot so that each weld is laid down at the right spot. These processes have two totally different I/O structures normally.
To answer your questions about what systems we’re using, they’re IPG YLS-6000 lasers with IPG 2D high-powered scanners and we have the extended I/O interface— while the beam delivery systems are terrible, the IPG generators are some of the best and most cost-friendly lasers on the market. This makes them one of the more common systems now in automotive, even though everything except their laser is garbage—even the way the system interfaces with everything is archaic and nowhere near as practical and user-friendly as Trumpf, RLSK, or Blackbird heads.
My apologies if you have prior knowledge and all I did was tell you things you already knew, in my experience, people either know a fair amount about these systems or nothing at all. I’m a robotic laser applications specialist so that’s all I do, I’ve been wanting to get into it more from the controls side of things.
What I have found easiest in repair programs I have made for missed spot welds is to have the robot go through each weld position and use DI's from the PLC to determine if that position needs welded. If not, it skips the spot instruction and moves on to the next point.
This would actually be used to repair welds from a remote laser welding cell, what I mean by that is based on how the welds were placed and the application we were able to hit 10 welds from one position. Remote laser welding is becoming increasingly popular for its speed, you’re able to weld a lot faster with remote laser welding; so I’ll use the piece I’m talking about in this thread as an example, there’s 80 welds on these rails that get attached to a floor pan— it takes about a minute and a half to hit all 80 welds, this is because depending on your focal length has well as the scanners FOV you can cover a lot of real estate from one spot.
That’s also what makes this repair system so difficult, because I get all 80 welds from 12 positions— so for the repair program I’d have to make a position for each individual weld, which isn’t too bad but it’ll be a big program that’s Forsure. I was thinking of just making PR’s for each position, then I could save a offset as another PR, from there I could just send the robot to whatever weld that needs to be repaired and just have it offset however many mm’s to repair it.
I am really intereseted how you would repair a bad weld with a robot? What kind of problems would the machine be repairing? Missplaced welds, porosity, ...? You usualy need to grind the weld out and make a clean weld groove, so Im genuinely curious how you would go about something like that
So this would be a cell meant to repair autogenous laser welds on a lap joint, autogenous welding means there’s no filler metal being added to the part (my apologies if you knew that). With autogenous laser welding, you need there to essentially be zero-gap in the tooling, if you’re welding with gaps in-between the two materials, this can cause concavity— this is when the top surface of the weld tries to escape between a gap in the piece or if the base material is blown through will escape through the bottom before it solidifies. This happens when doing what’s known as “keyhole welding,” which is a specific method of welding for lasers; it’s really interesting if you have the time to read about it. Anyways, to repair autogenous laser welds according to GM standard you use GMAW welding to either fill gaps or replace the top surface of the weld, we’re experimenting with handheld laser welding to do the repairs on a robot; it’s essentially GMAW but just with a laser and we’ve attached it to a robot because as far as we can find, nobody else has done it. I hope this answered your question!
PRs... are you planning to use a Fanuc, then?
It sounds doable. As long as each weld is an identical set of motions, you could use a PR to offset to the start point of each weld, then run a subroutine that performs the weld, then moves on to the next point. If the rails are curved, or the welds have unique requirements per weld, it gets trickier.
Yes, it would be a fanuc robot. That’s what I was thinking, I could save each weld as a position register and from there have one other PR as my offset and then as you mentioned run a subroutine that does the actual weld.
Hey everybody,
I had a question regarding an application my company wants to develop, all our work revolves around industrial laser processing, from technology repair and integration to process development. I handle to programming and integration for all robotic based laser applications.
My question regards a weld repair system, we setup a remote laser welding cell to weld rails, each rail has 80 welds a piece on them, they do all weld repairs manually right now. I was wondering if it’d be possible to design a cell that did all the weld repair for you, using a handheld laser welding gun attached to a robot; the idea would be to figure out which welds need to be repaired based on a cut and etch, from there the operator could punch that into the HMI and the robot goes and repairs those specific welds.
I guess my question would be on the robot side is how would the PLC effectively communicate that to the robot? Could we link the numbers in the HMI to position registers inside the robot and from there the robot could go and repair those specific welds? That would be a lot of position registers if so, I figured I could just use one PR to save the offset; as in once you get to position register 76 offset along the y-axis however many mm to succesfully repair the weld.
Any and all suggestions would be greatly appreciated, as I mentioned this isn’t a current project but one we’re hoping to build on and hopefully be able to offer to customers.
This is a Fanuc robot we’ll be testing it out on, I put it in the general thread though because we might attach it to a staubli or ABB robot as well.
Probably not -- KAREL is being deprecated by Fanuc as a motion controlling language. These days it's mostly reserved for operations TP doesn't support, like socket communications, or custom modules that the developer wants to keep proprietary. OLPs are probably generated in TP, although I have heard of setups where the OLP is too large for the robot's internal memory, and instead a KAREL program is used to "stream" the positions to the robot via I/O or TCP/IP.
hermann has the right of it -- the biggest issue with learning any of the robot languages is the lack of execution environments, unless you either have a robot of the correct brand, or a brand-specific simulator. You can write most of these languages offline in a text editor, but testing and debugging would require a robot (virtual or real). And there are no free options. RoboGuide, RobotStudio, and OfficeLite have, IIRC, 30-day trial periods, but after that, you're stuck.
This all makes a lot more sense now, I thought outside of Fanuc all robots had a TP language and structured text language so to speak; I didn’t know they only used one language for all formats of programming.
I guess when I asked if it was better to program in a text editor I meant more how does that workout with motion and everything? If you’re programming in a text-editor, doesn’t it make it difficult to gauge distances and such?
Which way?
On Abb and Kuka robots you use the corresponding language (rapid/krl) on TP and offline, there is no difference in used language. Only Fanucs have this difference where you have to use offline tool to compile Karel, but you also can use TP language online and offline.
For learning one of those languages you should use either a real robot or an offline programming software like Kuka office lite, robotstudio, or roboguide. Everyone of these are expensive, but for the last two you can get a 30 day test version.
That makes way more sense, I was not aware of this; we have a staubli in our apps lab, obviously that’s all programmed off of VAL3. I thought outside of staubli, the other major companies were like Fanuc in that they had Karel as well as TP; I didn’t know the language was the same on both the pendant and in a text-editor for Kuka, ABB etc.
We don't use Karel at all, only TPP. We realize we may be losing some functionality, but the advantage is that when there is a problem on the shop floor we can go out and fix it straight from the pendant. We have cells made by outside vendors that use Karel. The difference in time to troubleshoot and correct problems can be quite substantial.
when you say they program the cell in Karel, they made the whole cell with OLP?
Hey everybody,
So I’ve never worked with Kuka before but my company is laser applications focused and we were thinking about getting a kuka yo use their laser tech software. From what I’ve read, you’re able to tailor the source code to your need.
I was wondering, does anybody have the source code for this software they’d be willing to send over email? I want to download their offline software and play with it that way after customizing it. We’re going to use it for brazing and welding.
Hey guys,
So I’ve been messing around with robots as part of my job as a laser applications engineer; I’m currently in school for computer engineering, I know Python and C, but I want to start diving more into KRL, Rapid, and Karel.
Would anybody have any suggestions for projects where I’d actually be able to put these to the test.
Also, is programming this way more efficient or better than using a teach pendant? It seems like all the best robot guys I met had a really good grasp on these languages as well.
If you’re talking about running IPG scan systems on-the-fly, it is a complete nightmare; I had the same issues where the triggers would misfire at the wrong distance— we ended up just turning it all to point & shoot and it worked a lot better, IPG’s beam delivery systems suck though.
Hey everybody,
So I have a question regarding I/O and tying it to position registers or argument registers.
If you’ve seen my posts before, I’m a laser engineer who’s now working with mainly robots in order to integrate different robotic applications.
When you’re laser welding, air flow is a main component to quality welds as well as not spending money replacing cover lenses. On prior jobs I would just turn those bits on and off as needed relative to what position the robot would be moving to; while this works, it leaves my main program really long and messy— I was wondering, is there a way for me to tie those DO’s to certain positions without necessarily making a bunch of position registers? I’ve heard of some people using argument registers to do so.
I’ve seen a lot of things people are able to do with these robots, especially if they’re knowledgeable in writing Karel; I’m good at C++/C as well as Python so I’m really interested in getting more experienced with the actual computer science side of these machines.
Robots move to positions in space that are defined relative to a reference frame. The default reference frame (variously World, Base 0, UFrame 0, Work Object 0, etc) is usually located in or near the center of the robot base. But it's possible to define additional reference frames in the robot, as offsets from the robot's World frame.
Imagine a situation where two robots are on opposite side of a car, spot-welding it. With the two robots facing each other, their respective World frames are 180deg opposed. This means that to move a weld towards the front of the car, one robot would have to shift in it's World Y+ direction, but the other robot would have to shift in Y-. If one robot is mounted to the floor and another to the ceiling, or if they're mounted at odd angles to each other, the problem gets even worse.
But if you create a reference frame, "Car 0", on each robot, located at the same point and in the same orientation, then program the spot-welds relative to Car 0 instead of World, then the reference frame being used by both robots are aligned.
This is especially helpful because quality control inspections on these spot welds will usually take place in a completely different department, that does everything in the Car 0 coordinate system. So if they issue a directive that a particular weld is off position by 5.3mm in X+ and 2.1mm in Z-, those numbers are going to be in the Car 0 coordinate system. So if the robot was originally set up to use Car 0, that makes it much easier on the robot technician to fix the weld position, without having to sit down and try doing 6DOF conversions with Cartesian coordinate and Euler rotations. Setting up Car 0 in the robot does all that math for you implicitly, "under the hood."
Thank you once again for explaining this so in depthly, as I mentioned above, I only do robotic laser applications; my boss is an expert in laser technology, mainly the laser side of it, from high-power fiber, disk, Nd:Yag, and so on and so forth. Being that he focuses on the physical side of the laser, I handle all the robot as well as scanner programming. We’re doing a on-the-fly remote laser welding job for Mercedes, from what I understand they use this car 0 frame and he wasn’t able to explain it to me; that makes sense though, I’ve seen roboguide simulations that use this frame and it’s always right at the corner of the drivers side headlight I think. This should really help with scanner welding, keeping the optic nominal with your part is crucial for not reflecting the beam, with this it should be easy to get tight seams.
"On" is a bit vague. Most robots can only execute code in their own programming language, or option packages built and sold by the robot manufacturer. There are a few 3rd-party tools out there, but they're usually either from the robot manufacturer's technology partners, or are "no warranty, use at own risk" types of thing.
OrangeApps.de sells 3rd-party software that executes on KUKA robots, but I suspect they have some sort of business relationship with KUKA. Then there's OpenShowVar, which falls into the "use at own risk" category. Without massive resources, it's impossible to achieve the level of testing and certification that manufacturers like KUKA put into their option packages.
First of all, thank you for taking the time to give a thoughtful reply; I should have clarified better, I’m more interested in building like application specific software such as coherix, perceptron, and things of that nature, or even like building the ArcTool and DispenseTool sort of software. I’d really to get into vision work as well, unfortunately my company only does lasers, since I’m the robot guy I do all the robotic applications, mainly remote laser welding but also Brazing and cutting. I think vision would really be a good stamp on my resume, both being able to build the software and integrating it into a system. I’m doing my bachelors in computer engineering right now, I really love computer programming, but I also love programming/engineering applications in automation. I’m trying to find a way to mesh these.
Hey everybody,
I had a general question about the different types of software you’ve used on all the major robot brands, I’m a computer engineering student with a focus in intelligent systems; seeing as I work with robots, I think building some-type of third-party software to integrate on a fanuc or something would be cool for a project.
It can be any type of software vision/process monitoring, frame calibration, etc. I’m already familiar with the different OLP softwares, I’m thinking more application focused.
Also, I’ve heard a lot about this thing called “car 0,” I know this has something to do with frames, but I was wondering if somebody could explain to me better what it is.
I don’t know if there’s anybody on here who’s used to working with lasers, but I’m currently setting up an IPGscan system at a customers site; I have experience with trumpf iPFO head, Hyag RLSK, and nLight scanner heads— this is just my first time using IPG’s heads. I’m able to fire the laser from the IPGscan software, I just can’t get it to just run through the program using the IPG macros.
Its a point & shoot job for anybody that’s integrated these systems. I understand how the logic works with the I/O, as in it uses binary to send the Group ID to Port A, then it uses a DO ‘strobe’ to pull the Group ID from Port A and send it to the register where from there it goes through another action and then all you have to do is turn ‘strobe’ off and turn on start to fire the laser.
When I try to run the program from the robot, the select binary bits are sent to Port A, after I turn on strobe they’re not loaded into register even though I modified the loop actions to do so. When running the program it gets stuck at waiting for an input from the ‘emission status’ bit to be active/on in the IPG_EXECUTE_WELD macro.
As I mentioned, I’m able to manually fire welds from the IPGscan software so I’ve got everything correct as far getting it into remote mode, when I manually fire it I see the emission status bit turn on so I know I configured all the I/O for both the scanner and the laser properly. I wonder if it’s an issue with the software setting because it won’t load the bits from port A to the register at least when the robot does it on its own. Before anybody says it, I know using select bits to send it Group ID’s/program numbers is stupid; every other laser uses GO/GI’s.
