You don't create new modules in the TP folder. That is normally reserved for modules installed and used by KUKA Tech Packages.
Posts by SkyeFire
-
-
Well, you need to get your General Motion Enable input set True. If you don't have an external source for the signal, you can bypass this temporarily by setting $MOVE_ENABLE to $IN[1025] in the Auto-External I/O Configuration.
You'll also need to ensure your X11 circuit is closing the hardware Motion Enable contact, which is separate from the "soft" General Motion Enable $INput, but generates an identical error message.
-
Code for this is very robot-specific, by brand -- every robot brand has its own proprietary programming language, so sharing what (non-proprietary) code exists for this would almost be counterproductive, unless it was for a robot whose language you were familiar with.
I know Matlab and Scilab have some libraries available that can do this, but not much hands-on experience with them.
You could try the free robot simulator RoboDK, which programs in Python, although the various functions are, IMO, not very well documented.
The terms you want to research are position and orientation vectors, in either Euler, Tate-Bryant, or Quaternions. It's mostly matrix algebra -- the hard part is that most of the papers on it are "pure" math, and the conversions between a 6DOF position variable in a robot and an equivalent 4x4 matrix (and vice versa) varies, again, by each robot brand/language.
-
Yes. You can only use the same variable name once for a Global variable. You can have either the BOOL declaration, or the SIGNAL declaration -- not both.
-
For later versions of KSS, the robot should have pre-installed a module called MSGLIB.SRC, which provides a number of fairly easy-to-use libraries (and comments) for using different types of messaging.
One thing to be aware of: for the "Dialog" messages, the library (the ones I've seen) gets the key numbering backwards for the operator buttons, so watch out for that.
-
hello , Our friend
Kuka is KRC2 _360 kg L280
windows XP , KRC_ver 5.4.14
I need when time change $config.dat , I save my change made .
How can I do it ?
please help meI have merged these topics. Please do not open multiple topics for the same problem.
-
When you Open the $CONFIG.DAT, does the SPS icon turn from green to grey?
-
As Panic showed.
SIGNAL is, effectively, a special type of BOOL or INT declaration with an implicit link to one (or more) Inputs or Outputs in the $IN/$OUT table.
Now, one potential drawback to using this is that your named Signal will always reflect the state of the $IN input, in realtime. So if, for example, you want your Boolean to become True when the Input does, but remain True when the Input becomes False, then you will probably need to write some executable code in the SPS to accomplish that.
-
Any two variables of the same type can be passed into each other. However, if you want to pass only part of a structure variable (E6POS, FRAME, etc), you have to do it one sub-variable at a time, as you already are.
-
Touchsense works with inline-form points by using special inline forms that connect the Touchsense commands to a particular point. You can achieve the same using standard inline forms, as long as the name of the "search" point is standardized and is not changed.
Fast Measurement requires a hardware kit. Touchsense normally uses the Fast Measurement inputs, but it is entirely possible to use regular inputs. But the search motion must be slower to compensate.
-
Just an FYI-Update:
I just ran into this again, but this time, the file didn't appear to be corrupted, as such, and the RSI driver was fine. No, this time it showed up when I tried to run a Brake Test, and got back the MDR error 2848 calling BRK an "unknown device".
But rather than ASCII corruption, this time the driver line BRAKE_TEST, mdrBrakeTest.o was commented out.What's really strange is that no one has made any changes to these robots recently, in SafeOp or any other sections, either using WV or directly editing the files. So I'm really not sure how this happened.
But, whatever, un-commenting the line got my Brake Test running again. So, just another thing to watch out for.
-
TouchSense for doing a 3-point touch of the part, and a Base shift before running the weld? Yes, it can be done. You will need to create the math and the search motions to do this, but it is possible. Most KRCs come with a module called KUE_WEG.SRC (usually buried in the /UTIL directory) that has a lot of the math routines to do some of these operations (but they're not documented and the comments are all in German).
If you don't have the fast-sensing input hardware, you'll need to use normal inputs and make your search motions slower, to avoid issues with the 12ms input update time.
-
Well, the FileOpen and FileClose subroutines are stuff I've got in my standard library of support functions, and they've been in production use for a year+ without any issues. And the STATE.MSG_NO I get from CWRITE (note the MsgNotify) isn't -3 (no file open), but -11 (at least one function parameter has an invalid value). Back when I had STATE decl'd as a retentive in the DAT file, I kept it open in the VarCor while I single-stepped through. On those occasions when the file didn't open, the error-handling caught it and skipped past the FGETS cleanly.
Also, when I brute-forced it by replacing the FGETS with FGETC and concatenating, everything worked almost perfectly. I'm just trying to avoid the extra time cost -- I've got some huge arrays to load, so huge that I can't keep them all in KRC RAM simultaneously.
-
Nope. No go. I have officially hit the end of my rope. There is literally no functional difference between your code and mine that I can see, but the CWRITE gives me nothing but "At least one function parameter has an invalid value." I dunno, maybe I've just gone pie-eyed from staring at this code all day.
Code
Display More&ACCESS RVP &REL 86 &PARAM DISKPATH = KRC:\R1\Program\Test Programs DEF ReadLineTest ( ) DECL INT _nLineIndex, _nOffset, _nStringLimit, _nLineLength, _nColumnIndex, _nASCII, _nFileHandle DECL MODUS_T _Mode DECL CHAR _chFileChar, _chFileLine[100] DECL STATE_T _State bEOF = FALSE _nLineLength = 1 _nStringLimit = STRDECLLEN (_chFileLine[]) WAIT FOR STRCLEAR (_chFileLine[]) _nFileHandle = 0 FileOpen("ArrayRead.txt", "r", _nFileHandle) IF (_nFileHandle <> 0) THEN _nLineIndex = 1 _nColumnIndex = 1 FOR _nColumnIndex = 1 TO STRDECLLEN (_chFileLine[]) _chFileLine[_nColumnIndex] = " " ENDFOR WHILE NOT bEOF CWRITE ($FCT_CALL, _State, _Mode, "krl_fgets", _nFileHandle, _chFileLine[], 100, _nLineLength, ";") MsgNotify ("FGETS STATE.MSG_NO %1", "ReadLineTest", _State.MSG_NO) SWITCH _State.MSG_NO CASE 0 _nASCII = _chFileChar SWITCH _nASCII CASE nSeparator ;Parse line into array _nOffset = 0 ;SREAD (_chFileLine[], _State,_nOffset, "%g", ArrayVal[1,_nLineIndex].X) Increment (_nLineIndex) _nColumnIndex = 1 CASE nLineFeed, nCarriageReturn ; Do nothing, keep reading ;until next valid char DEFAULT ; Get next character and append to line _chFileLine[_nColumnIndex] = _chFileChar Increment (_nColumnIndex) ENDSWITCH CASE -4 bEOF = TRUE halt DEFAULT CWRITE ($FCT_CALL, _State, _Mode, "krl_fclose", _nFileHandle) bEOF = TRUE ENDSWITCH beof = true ENDWHILE CWRITE ($FCT_CALL, _State, _Mode, "krl_fclose", _nFileHandle) ELSE HALT ENDIF END
-
Yeah, I downloaded your newer version of the manual, which showed what I was doing wrong. But there's still some odd stuff happening.
So, if my Buff[] string is declared in the DAT file, CWRITE always fails with a "invalid character" error, pointing at the first EOL character of the line in the text file. Changing the Buff[] variable to a runtime variable fixed that, but only insofar as CWRITE failed "silently", without crashing the program, but still gave me a STATE.MSG_NO of -11: "At least one function parameter has an invalid value."
At this point, this is what my CWRITE and yours look like:
cwrite ($FCT_CALL, s, m, "krl_fgets", h, Buff[], 87, Read, ";")
CWRITE ($FCT_CALL, State, _Mode, "krl_fgets", nFileHandle, _chFileLine[], 100, nLineLength, ";")The only differences left between your code and mine (aside from the variable names) is that my nLineLength and State are declared in the .DAT file with initial values, so I can monitor them in the VarCor. I'll try changing that next. But seriously, if this function is going to treat runtime and retentive variables differently... WTF?
-
Okay, for a while there, I thought I was losing my marbles.
I put your program into my robot, changed the FOPEN to point at my test file, and it ran perfectly. I changed my test program to use FGETS again, and it failed utterly. And, as I said before, I could not put anything in as my Separator except an Integer variable. It was nuts.
Until I put your CWRITE and my CWRITE up against the wall... I mean, against each other:
cwrite ($FCT_CALL, s, m, "krl_fgets", h ,Buff[] ,87 ,Read, ";")
CWRITE ($FCT_CALL, State, _Mode, "krl_fgets", nFileHandle, chFileLine[],100, nSeparator)Your CWRITE has one more argument than mine does. Where does that '87' come from? Your CWRITE has 9 arguments, where mine (and the manual) only show 8.
Anyway, this should get me past the FGETS issue. Now I just have to get past the SREAD parsing issue....(edit)
So, of course it turns out that my copy of the CWRITE manual was outdated. Anyway, thanks, Panic, you saved my bacon.
(note to self, tell Werner this forum needs a bacon emoji....)
-
Well, that's a fairly simple two-point path plan. For most programmers, it's a simple matter of programming a Tool-axis shift from the point that the vision system provides. Almost all robots have a means to do this easily, baked into their programming language.
To do it explicitly, well, it consists of taking the 6-DOF location and orientation of the target point from the vision system, convert it to a matrix, cross-multiply by a matrix that represents the standoff vector, and convert the resultant back into a robot 6-DOF coordinate. Then run the two points in sequence, with the last move being Linear rather than Joint. That allows you to "thread the needle," as shown in the video.
As for limits... well, that should mostly be handled at the design stage. Lay out the robot, tool, and the bin the robot will be picking from. Work out how much the robot can tilt/roll to follow badly-oriented parts, in the worst locations in the bin, before (for example) the wrist hits the side of the bin. Run simulations to check for fatal singularities. Make changes to the robot tool, or mounting, and do it all again, until you eventually find a workable medium. Then program the vision system and/or robot to reject parts that are unreachable within those limits.
In the robot program, steps can be taken to mitigate the singularities as well. Like always having the robot start from an unambiguous axis pose that provides maximum freedom for all axes in both directions. Some robots have functions that can allow a program to predict the axial pose of a given Cartesian coordinate before moving to said coordinates, which provides an opportunity for a clever programmer to try different options. But in general, most of these issues should be handled at the system/process design level. If it comes down to the robot programmer on the shop floor to figure this out, generally that means someone's dropped the ball further up the chain.
-
Thanks, Panic, I'll give that a shot.
(edit)
Hey, how did you get fgets to work with your separator shown as an explicit ";" character? When I tried that, I got a "not a variable" error first from CWRITE, then once I changed it to a CHAR in the DAT file and tried to use it, I got a "wrong variable type" error. The only thing I found that got me past those errors was making it an Integer ASCII equivalent.
-
Trying that...
Ow, what a chore. And now SWREAD is being buggy about parsing the bloody strings.
And, it looks like "krl_feof" doesn't actually detect the end of the file -- another thing that directly contradicts the manual. In fact, "krl_feof" sets the Boolean False invariably, regardless of whether the end of the file has been hit or not.
The silver lining is, I can check STATE.MSG_NO after "krl_fgetc" and get what appears to be a reliable, non-stopping check of whether I've hit the end of the file. So there's that much, at least.
-
No, that variable only comes into play when your program posts a Dialog Message to the pendant -- the message type that puts a number of option buttons along the bottom row (max 7). $MSG_T.ANSWER just provides the number of the button that the operator pressed.