What is it that you would like to print? Your modules? Or messages?
Posts by Metalikooky
-
-
Any chance you can post the code? The simulation looks like there is no motion programmed, but obviously, the robot is moving. If there isn't any additional motion programming, then I suspect it may be because of an external tool center point.
Edit: Upon watching the actual robot more closely, it looks like your milling bit is rotating at the same speed as the workpiece. This observation leads me to more strongly believe it's something to do with external TCP.
Are you using inline form motion commands, or just straight KRL?
Check the value of $IPO_MODE. I suspect it is #TCP and you'd want it to be #BASE.
Just a guess...
-
Just duplicate both files. If you do the .SRC file first, when you rename it, it will show a red "X" because it won't be able to be compiled. This is due to the fact that any locally declared variables are in the .DAT file that you won't have duplicated yet.
1. Duplicate one of the files - rename it to whatever you want.
2. Disregard the compilation error if you get one.
3. Duplicate the other file - just make sure you use exactly the same name.This has worked for me flawlessly many times. KSS 8.X.
-
Glad you got it. We don't use any welding packages, so I would have been useless to you. Thanks for the knowledge!
-
So ARC_ON and ARC_OFF are just names of points in your programming? Any chance you can post the code you're actually trying to execute?
-
I've heard of people using joysticks to remotely move a robot manipulator (with force feedback!) I think they used Force Torque control, but I don't really know.
-
I'm a bit confused by your code. Is POSITION being updated/changed every time I is evaluated? If that's the case, the robot can't motion blend because it needs to evaluate I every time it comes back into the FOR statement.
Maybe I'm missing something?
-
That's most likely because you're trying to edit the code while the program is SELECTED rather than OPENED. IF statements cannot be edited while the program is running in the robot interpreter. Cancel the program. Open the file, rather than selecting it, and you should be able to edit as you wish.
-
The problem you're going to run into is that the programs the robot runs are stored on a RAM disk to which you do not have access. So any time you change the files in the R1/Program folder that you can see through the Windows directory structure, you're not actually changing the files in the R1/Program folder that you see on the SmartPad.
In order to do what you want to do, you're going to either have to utilize KRL XML, Vision Tech, or, possibly, Directory Loader. All three are Kuka option packages and will thus cost extra money.
That I know of, there is not a way to change the files the robot is running in real time without one of those packages.
-
Out of curiosity and ignorance, why is this in a Kuka forum?
-
It is one way, though I'm not too familiar with how to implement OPC. You can set your variables to robot outputs and then look at them with an external controller (PLC) as inputs. So, for instance, if you wanted to report Axis 1 actual velocity in real time to the PLC, you might do the following:
In the config.dat file, you could declare a non-system variable as a group of outputs:
And then in your SPS, you could send the value of the system variable to this output group:
This combination will essentially update the output group to the actual axis 1 velocity every time your SPS is scanned (on the order of milliseconds). That group of outputs could then be read by the PLC to use as you wish in your controller program. Of course, this all depends on setting up your robot to talk to a PLC, which greatly depends on what type of controller and network you're using.
Is this what you're trying to do?
-
Very cool. Any day I can learn something (which is most days) is a good day. Thanks guys (or girls)!
-
Or, if I'm not mistaken, in the "Name" field, you could just type "INWORD" - that should report the value of that variable.
-
Controller version? KSS version? Do you want to view the value of a variable? Or do you want to read that value by an external controller or other interface?
And, you can view variable via Cross? How?
-
You'd like to know ahead of time how long the motions WILL take or you want to know after the motions are completed how long they HAVE taken?
-
I don't think you'll find a manual anywhere for one particular file on the robot. It is, essentially, a global signal declaration file. Many of the signals in STEU/$machine.dat are configured when you configure Auto External control through the menu sequence Configuration > Inputs/Outputs > Automatic External. Documentation on that can be found in the System Integrator's manual beginning on page 170. Some of the other signals in that file relate to Safe Operation, Workspace Monitoring, and Collision Detection. Most of the signals have a comment describing what they are, albeit in German. I just use Google Translate to determine what they do.
-
I've been told that KRC4s with KSS 8.3 have a syntax-hilighting file for KRL that works in NotePad++, and N++ works under Linux. But that's just a hilighting file, not really a full "helpful" editor like OrangeEdit. Although sometimes I want to strangle OE when it's trying to be "helpful," especially with how it keeps trying to complete IF statements for me when I don't want it to.I think turning off "Syntax Completion" might eliminate that frustration for you.
Extras -> Options -> KRL Syntax -> Uncheck the "syntax completion" box.
-
It sounds like what you're dealing with is a situation where there would need to be some physical human interaction with the robot. Do you have a fence circuit? If so, when the cell is opened up, the fence circuit should stop the running program anyway. Once the issue is taken care of, motion parameters can be re-instituted and the program can be continued from where it was left off. Maybe I'm oversimplifying the issue. It's always hard without experiencing what's happening.
-
-
...And, I can tell you from experience that the robot will not programatically change operating modes. It has to be done manually. What kind of problems are you expecting to possibly have to fix? Is it a robot problem or is it something external to the robot?
If it's external, you could generate a dialog message. Something like:
"Take care of XXX (whatever has triggered your input). Press OKAY to continue robot program."
<OKAY> (button)
This would allow the robot to stay in EXT mode, but would stop the program if the input comes high and then allow the operator to continue the program once the issue is taken care of. In this case, you would probably want to loop back and check the status of the input before continuing the program, but that's easy enough to do inside the condition programming.