Posts by AiSard

I only tried #VAR_ALL and tested it going near the singularity (not through it) (I gathered that #VAR_ALL_MODEL had a higher velocity cap than #VAR_ALL so didn't try it out)
Not seeing it slow down, I became unsure if I understood the command correctly and so came to check in the forums before moving further
I guess I just never hit the maximal axis velocity (not being quite close enough) so didn't see any effect hm

Is it possible to set the max axis velocity that #VAR_ALL references? (or something to the same effect)
This was my initial direction, thinking to cap the overall velocity near singularities.

A4-6 singularity. Not looking for other options. Specifically looking for speed reduction.
Path and Orientation is Fixed. Only looking for ways to reduce speed.
(sadly too late to change the tool orientation as usual )
Thought I had constrained the question properly, guess not

Ah. Main thrust is not for production, but for an audience. If that makes it easier to understand. [EDIT: Use-case is a paintbrush. ]
Trying to specifically reduce the fast movement of the A5 here,
while singularity avoidance is being handled by simulating the possibility space as much as possible (which is a separate thing to this)

I guess no-one mentioning $CP_VEL_TYPE means I was going down the wrong path then I guess (also in the Systems Variable Manual).
SPS to manually monitor the axis seems like the way forward... Except not quite confident enough to mess with the SPS for the first time in the time left..
Might have to fall back on just reduced overall speed at this point and hope for the best

As for use-case, hopefully this truncated version is enough, not sure if still needed (wrote it before the above) but I spent an hour wracking my head on how to succinctly explain it so..:

Quote

Path can be treated as (effectively) random if constrained
Orientations are curated to minimize singularities.
But due to the randomized path and wide orientation possibilities, affected points are also unknowable ahead of time.
Pose is fixed to maximize volume of working area (and orientations are curated according to pose)

Other motion paths passed over as they leave orientation unconstrained in various ways

Again, Path and Orientation are effectively Fixed.
Speed is the only free variable to change.

From what I understand, isn't #JOINT to do with freeing up the orientation?..
Which would be rather dangerous for my set-up....

I am asking specifically for ways to limit/reduce the speed when getting close to the wrist singularities (with LIN movements during AUT)

I feel like I've read in passing that this might be possible on the forum (granted may have misunderstood as it didn't go in to detail), but usually gets passed over as I guess the normal use-case (spray painting?) would suffer from variable speeds (whereas my use-case is unaffected)

KR C4 KSS 8.3.25

Is there a way to slow down LIN movements as the robot approaches singularities during AUT mode? (similar to how it is in T1 and jogging)

I've tried setting $CP_VEL_TYPE to #VAR_ALL but not seen any effect (unless it only kicks in when the robot would otherwise BRAKE?)
Or is there a way to set max axis velocity limits for LIN movements or something similar?

After looking in to this a bit more, mine eyes have been opened
Didn't know about the Programming Messages documentation before, though will probably be fine with MsgLib
Thanks guys

KR C4 compact
KSS 8.3.25
?

Been bugging me for a while but can never quite figure out how to word the search criteria for this,
But is there a command to print text and/or variables, perhaps in the error log portion of the pad, during the running of the robot?
something similar to a print to console, println(), etc?

thanks,

Aaand nevermind, forgot to initialize Random. Didn't know that CWrite attempts to read the value before setting it (I think?)
Just put a Random=0 before the CWrite function and it works now thanks!

Hm, not sure what I'm doing wrong, but the CWRITE function keeps spitting out a "Random Value Invalid" error.. Doesn't seem to matter if its inline, subprogram or function..

DECL E6POS rPos
...
rPos.X = RandomInt(0,300)
...
DEFFCT INT RandomInt(Min:in, Max:in)
	DECL INT Min
	DECL INT Max
	DECL INT Random
	DECL STATE_T State
	DECL MODUS_T Mode


	CWrite ($Fct_Call, State, Mode, "krl_getRandom", Random, Min, Max)
	Return Random
ENDFCT

Am I doing something wrong? I'm not so versed in Interface functions(?) or anything that uses more than the single .src file so might be fudging something up..

Is there a way to generate a random number in KRL?
I've been using a work-around via RSI,
But no RSI in this project so was trying to figure out a way to hack one in

KR C4 compact
KSS 8.3.25

Will try that out this afternoon, is there no way to get rid of the variable 0-500ms delay though?
Though I suppose I could try 100ms cycle and just trigger the pulse every 10 cycles or something like that (if that works? is there a problem / minimum cycle time for running a REPEAT cycle?)

Also people seem to be missing the second part of the question..
What do I replace the HALT command with? so that the Play button on the pad triggers $IN[1]
(unless I'm missing something very simple here?)

Quote from davidina

You could also use a WHILE loop and use that input as a condition. Inside the loop you can use your pulse as you want.

Which input? I am currently using Halt which requests the play button be pressed to continue..
WHILE loops only check at the beginning of the loop, if inside the WHILE loop there's only a PULSE and WAIT command, that's a really long period of time between checks...

Quote from Leon

the first thing that come's to mind is the sps. there you could write a function to pulse when the robot is halted

Any alternative to that? Never touched SPS and don't want to mess it up inadvertently..
If I allow for a small delay (trying to avoid this) would something like this work instead? (rough draft):

DECL REAL STEP


STEP = 0.25


LIN P1
LIN P2
LIN P3
HALTPULSE()
LIN P4
LIN P5
LIN P6
HALTPULSE()
LIN …
…
END
_______________


DEF HALTPULSE()
LOOP
$OUT[1] = TRUE
CHECK()
$OUT[1] = FALSE
CHECK()
$OUT[1] = FALSE
CHECK()
$OUT[1] = FALSE
CHECK()
ENDLOOP
END


DEF CHECK()
WAIT SEC STEP
IF(?) ;input replacing halt became true*
$OUT[1] = FALSE ; immediately stop $out and exit
EXIT ;but exit all loops??**
ENDIF

*Not sure how to trigger the IF with the play button (replacing the HALT command)
**And have forgotten what the command is for breaking out of all nested loops.

Would prefer if there was no delay whatsoever, but I guess I could just have 0.1 sec intervals for checking instead (any negatives to that approach?)

A question on coding:

I currently have a tool mapped to $out[1]
During a portion of the robot movement, the robot HALTS and waits for input before continuing.
During that time, I would like to have the tool pulsing on/off continuously.

Is this possible while using Halt? or perhaps by replacing Halt with something else?
Just that it doesn't introduce a delay once the input is pressed,
and if possible for the pulsing to then immediately stop (less important)

KR C4 compact
KSS 8.3.25

Thanks,

got the ground from X55, IO is working
would have gotten it sooner but had the pins for X12 mirrored (was stupidly looking at the labelled numbers rather than where the wires were actually going)

Thanks for the info about X12 though

Is X12 the one with 30+ pin holes?
Someone must've mixed the labels around as I've been thinking that was X69 all this time..
(and was wondering why it didn't match up with the manuals...)

But yes, I'm connecting to EL1809 through the 30+ pin hole interface, not directly.
The common ground thing is the thing I was stumped on, but I've since figured out I can take it from X55 (right?) pins 6/8?

The WV is already configured.

I want to use the robot IO to control a solenoid valve, we're using a KRC4 Compact.

The default IO mapping for the EL1809 is already mapped and working (checked the lights when I fiddled with the outputs on the pad) but I'm unsure how to do the physical IO wiring.
My solenoid valve has two wires, positive to go to one of the ports on the EL1809, while I understand the negative would go to the EL1100?
But of the three negative ports on the EL1100, two connect to each other, and the last connects to X55 (which I vaguely recall got connected to itself (to close the circuit?) by the kuka guy when we were setting up the robot years ago.

In this case where should I be plugging the wires in to?
(sorry if I'm missing any information/context, very weak in terms of hardware )

tl;dr For my valve, where should I connect my negative wire?

edit: added photo

Kuka Agilus KR 10 R1100 sixx
KSS 8.3.25
KRC4
RSI 3.2

Is there a way to easily turn RSI on/off in the .src code itself, while the robot is working?
And specifically if it can be Triggered remotely in one form or another (..by variable over.. RSI?..eh..)

My primary goal is to have periods of robot movement in which I can safely cease udp communications without RSIBad stopping everything. So if there's an alternative to turning RSI totally off I'd be open to that as well. I have periods of (usually non-movement) where the server needs to do some heavy computation.

If anyone has and leads or ways to do this?

EDIT: I vaguely know of ST_OFF, is this a promising lead? but also, can ST_ON then be triggered from server-side afterwards?..

Thanks,

As a very basic example, I'm trying to move the camera in a curved path, with the camera always pointed towards an arbitrarily selected point.

LIN doesn't work as it breaks up the curve and, in between the LIN commands the point is no longer centered
PTP in between commands points in random directions due to PTP

My question is if there are ways to, in between the commands, keep the camera targetted at the selected point (or as close as possible?..) using SPL or other commands or enabling some modes that I may not be aware of? to atleast have a smooth transition between commands (from the perspective of the camera)
For a fixed focus point, if I set the TCP to the focus point it might work, but if its dynamic I'm kinda lost..

No feedback loop. Set of positions/planes pointed towards a fixed point (or moving if possible)
Problem is that in between the positions/planes that I program, the robot seems to slightly point in other directions before centering back on the object (this was from tests done last year, won't have access to robot til about Thursday to do more tests)

Ah, when I said 'focus', I really meant 'centered'. The camera is not synced up to the robot or computer in any way at this point. More concerned about how the camera won't stay centered on the target in-between positions/commands.

I think I had figured out an ad-hoc solution eventually, but it didn't fit all my needs and regardless I've gone and forgotten it (been over a year and that project got scrapped early)