Hmm ok... So something like this?
DEF FUNC1()
DECL INT VALUES[5]
INT ARRAY_LENGTH
; ARRAY_LENGTH should be set to 5 by this
ARRAY_LENGTH = DETERMINE_LENGTH(VALUES)
END
; Increment all values in array
DEFFCT INT DETERMINE_LENGTH(VALUES:OUT)
INT VALUES[]
INT COUNTER
INT LENGTH
FOR COUNTER = 1 TO 255
IF (VARSTATE("VALUES[COUNTER]")<>#DECLARED THEN
BREAK
ENDIF
ENDFOR
LENGTH = COUNTER
RETURN LENGTH
ENDFCTHello
Lets say that I have a KRL function that takes an array as input. Is there any way to tell how many elements the array holds?
For strings we have "StrDeclLen()", is there something similar for arrays?
/RoboticsMan
I guess the USB stick is an option - but it is just not less cumbersome than opening the project again via work visual. I was hoping for a better option.
/RoboticsMan
Thanks for the answer!
QuoteVery few people are capable of writing robust code, that will work without any debugging. If you know one, let me know, he/she is hired.
Point taken! Also, I would not write huge programs offline. Usually it is just a small utility, or a small change I need to send to a man in the field. And in that case it would be nice to be able to do it without having to go via a robot every time. I guess I have to ask the boss for OfficeLite.
/RoboticsMan
Thanks for your reply, it has been an eye-opener!
But about this:
Quoteof course controller is more strict
I see no "of course" in this. It is a sign of poor software design in my opinion. It makes it hard to make programs offline, and send them to customers without actually trying to put them on real a robot first. I could send out something that still contains a syntax error. That is not impressive....
/RoboticsMan
Hi
Let's say I am working with WorkVisual, creating a program. I deploy it on the robot, and I then make some small changes in the program via the teach pendant. I now want to bring these changes back into the project in WorkVisual. As far as I can see, the only way to do this is to close the active project, and then open it again from the robot. This seems to be cumbersome. Is there really not a better way to keep things synchronized?
/RoboticsMan
Hi
One of my colleagues noticed the following: When he writes a program in WorkVisual, he can generate code just fine. But when he deploys the program on the robot, he gets a lot of syntax errors. It seems that the robot is a lot more strict in its syntax checking than WorkVisual is. He also said that it is as if it only compiles the active file in WorkVisual, it does not perform syntax check in all files when code is generated. This is a problem if there are dependencies between the different files.
I can't remember the software version (KSS and WorkVisual), but it is a brand new robot, and he uses the WorkVisual software that came with the robot. It is a newer version than the one that can be downloaded from Kukas homepage.
Is this a known issue? It certainly makes WorkVisual less usable if that is the case.
/RoboticsMan
The presses and robots at Tesla seem to be very well synchronized:
Is this possible, or just pure marketing? Is it actually possible and safe to operate at that speed with those margins?
/RoboticsMan
not trying to hijack this thread(some interesting stuff in here) but you mentioned feeding those points from an external PC. We have done work where we read from an external text file, but I am wondering if there are other ways you would write those points? I can imagine if it was just a few points, you could map I/O but I am assuming that is not what you are doing. Is there another way to change those points remotely?
The application is bin picking. The points are generated at run-time based on part positions, so they have to be transferred from the pc. We send around 9 via points to the robot in each cycle. Data is transferred via the Kuka Ethernet XML Software. (I don't remember if that is the exact name)
Sendt fra min D5803 med Tapatalk
QuoteWhat's the actual error code you're getting?
I dont remember the error code, but the message is something like "CP/PTP approximate positioning cannot be carried out" and NOT "CP/PTP approximate positioning not feasible". It is not just a warning, it is an error that the user has to acknowledge.
Quote...what? With that code, the $IN check will occur when the robot is at P1, or earlier. That's how CONTINUE interacts with the advance pointer -- the advance pointer is always ahead of the main run pointer by $ADVANCE number of motion commands -- if you have I/O commands in between those motions, they break the advance pointer. If you buffer those I/O commands with CONTINUES, then they get executed several motions in advance of where the robot is physically.
What this means is that, in your example code, if the Clear input is True when the robot is moving from P1 to P2, but then goes False while the robot is moving from P2 to P3, the WAIT FOR has already been passed and evaluated, and the robot blows right through. And if you change the $ADVANCE value, or add/remove points between P1 and P3, the location in physical space where the WAIT FOR is evaluated changes unpredictably. That's why CONTINUEs are dangerous.
Well ok, I have to admit that it was not the best example. Here the assumption was that the input will be false until the robot asks for permission to enter, and once it has seen the signal (and acknowledged, which is not shown in the example), the signal would be reset. It is not a "area is free" signal as much as a "the area has now been allocated to YOU" signal.
I understand that you used a trigger to ask for permission to enter, but there must have been some sort of "wait for" in the "main program" also, i.e. outside the subroutine. The sub routine called from the trigger will not stop the "main program" on its own, no matter the amount of "wait for" you have in the subroutine. It runs in a separate thread, and I guess you dont even need any "continue" in the sub routine? Perhaps the main run could be stopped with an interrupt from the sub routine, but that isn't pretty.
I do understand your concerns about making the code fool-proof. In the projects I have worked on, this has not been a consideration. We have had enough headaches even without having to worry about accidental "saboteurs" 
Thanks, Fubini! That was the one I was looking for! 
I used it a lot for zone interference calls when I needed to avoid pausing at the boundary (which would be caused by looking to far ahead), but still needed a safe check of the zone clearance before entering.
A couple of questions:
1) How do you have a safe-zone-check in a subroutine which is called from a trigger? I just tried on our KRC2, and no, the "wait for" in a subroutine from a trigger does not stop the robot, even when the condition fails. This means that the robot would always move into the "safe" zone?!
2) Why would looking far ahead cause a stop at the boundary?
If I have a program like this:
$advance = 5
ptp p1 c_ptp
ptp p2 c_ptp
ptp p3 c_ptp
; request to enter safe zone
continue
$out[31] = true
; Wait for permission to enter safe zone
continue
wait for $in[31]
ptp p4 c_ptpThen it will not cause a stop between p3 and p4 unless the motion-pointer gets to the start of the blend-radius at p3 before $in[31] switches to TRUE.
If I put the "$out" and "wait for" statements into a subroutine called from a trigger between p3 and p4, then the robot will happily move from p3 to p4 without waiting for permission.
Or maybe I misunderstood you?
It's in my KSS 5 System Variables manual. I don't have a KRC2 handy to try it out on.
My mistake, sorry! I forgot to add "[ ]" at the end of the name, when typing it into the variable view.
On our KRC2 robot, the string is "10626 32 11 30". What would it be on a krc4?
Sendt fra min D5803 med Tapatalk
QuoteOh, no, that is due to the system variable $STOPNOAPROX, like I mentioned above
Wait, what? The way I use $STOPNOAPROX, is to find out when ANYTHING stops the advancepointer. So I set $STOPNOAPROX to TRUE, and when the advance pointer comes to a statement like "$OUT[241]=TRUE" and is stopped, the robot will stop immediately, and show an error message that must be acknowledged. Using the "caller stack" window, I can see which line stopped the advance pointer, and "fix" this by adding CONTINUE.
The stops I have seen on KRC4 are most definitely not related to $STOPNOAPROX. I have used $STOPNOAPROX to try to learn more the problem, but it was FALSE when I saw the problems. And leaving it set to TRUE doesn't make sense, obviously. Then I would have to acknowledge all the time!
QuoteHaving the WAIT FOR (with a CONTINUE) inside the Trigger-called subroutine works just as if you had the CONTINUE-WAIT FOR in the main program, with the exception that there's no look-ahead evaluation by the advance pointer. Instead, the evaluation (and the Wait) take place only when the Trigger makes the call. I used it a lot for zone interference calls when I needed to avoid pausing at the boundary (which would be caused by looking to far ahead), but still needed a safe check of the zone clearance before entering.
I still don't quite understand it - I guess I will just have to try it by myself
QuoteAs far as the program "getting ahead of itself" -- it is, somewhere. That's what's causing those approximation errors. If the advance pointer was never getting blocked, you would never see those errors.
I will politely disagree! I'm convinced the problem is that the next coordinate arrives too close to the blend radius of the previous point. I think the problem would be the same if $ADVANCE was set to 1. The motion planner simply cannot handle the late arrival of the next coordinate correctly. It has not been a problem on KRC2 for almost 10 years, so why am I seeing this on KRC4 now? It must be an issue that has been introduced in the newer versions of KSS. On the KRC2 the robot simply stopped at the point and continued afterwards, when it was too close to the end-point to perform the blend. Maybe this is not the desired behavior in all cases, but it certainly is in our case
QuoteHm... what's your $ADVANCE value?
Advance is always 5 in our program. The whole program is written so that it doesn't "get ahead of itself". "wait for" and "wait sec 0" is used where it is needed. We have used various iterations of this program for almost 10 years, so most of the problems are solved by now 
QuoteGenerally, when I've needed to do things like this, I use TRIGGER calls to subroutines, and put my WAIT FOR logic, with CONTINUES, inside the subroutine. That explicitly ties the timing of the WAIT FOR evaluation to a specific point.
A "wait for" in a sub routine called by a trigger? I have never thought of that. But how does that work? Where does the robot stop to wait for the condition??
The "wait for" in my example was just used to simulate the effect of a coordinate that arrives in the last moment.
Hello
Thank you for your answer! It is always interesting to know more about what is "going on behind the scenes". But why does this error pop up if we receive the next point too late? This should not change the estimate of the joint values at the start of the blend, or should it?
My program looks something like this:
PTP XP1 C_DIS
continue
waitvar = false
trigger when distance =0 delay = 600 do waitvar =true
LIN XP2 C_DIS
continue
wait for waitvar == true
PTP XP3 C_DISDepending on the delay, I will get the error at the start of the blend between XP2 and XP3. Does the delay change the estimate of the joint angles?
So actually, what I want to know is not whether the error will occur - I want to know how close the robot is to the start of the blend, when the next point arrives. If it is too close, the error might occur. If this is the case, I can prevent the error by inserting a "wait sec 0" between the two points.
Related to this problem I have also had another problem where a trigger (like the one in my test program) is never "fired" under certain circumstances. In this case it would "wait for waitwar== true" forever. I also think this is related to blends and the arrival time of the next point. I also never had this problem on KRC2.
/RoboticsMan
$PHGINFO is what you're looking for, I think.
Hmm, it doesn't seem to exist on our krc2 (KSS v5.5.10)
Sendt fra min D5803 med Tapatalk
Im trying to prevent that the robot sometimes (depending on timing) stops with an error message (CP/PTP approximate positioning cannot be carried out), and at the same time I want it to blend (i.e. not stop!) if it is at all possible. In the current implementation I have to stop in order to be sure, whenever I have received the next coordinates from the PC. I did not have to do that on KRC2. It is not easy to "fix the path", because the path is generated by the software on the PC.
