I think I’ve over thought this somewhat lol
I was starting to think relays wouldn’t be happy to be constantly energised.
But I assume you needed their resting state to be normally open if the power fails, it would trigger the safety.
I think I’ve over thought this somewhat lol
I was starting to think relays wouldn’t be happy to be constantly energised.
But I assume you needed their resting state to be normally open if the power fails, it would trigger the safety.
Kuka KRC5 8.7.6 basic xg11.1
I’m looking to add a sick laser scanner to the operator safety on the kuka without too much extra kit.
I need to go from 24v high low from the scanner to dual NC on the kuka, safely. Can’t seem to find a safety relay that’s configured like this. Closest is dual NO outputs.
Any suggestions?
ps Sorry if this post is in the wrong section
I don’t think so, there’s nothing else really wired to the robot other than an external E-Stop.
I’m convinced it’s not a mistake in the manual, as I guess the drives are ready when the robot is on and no E-Stop is applied.
If it came on when applying the enabling switch in T1 then that would indicate drives enabled.
Drives ready lamp question ??
Kuka KRC5 8.7.6
I've wired the optional drives ready lamp to the XG33 plug and it lights up while the robot is powered and goes out if an E-Stop is triggered or enabling switch is pulled to panic.
I was under the impression this light would only come on when the drives are enabled!? And the reason I came to this conclusion was the drive lamp test procedure in the manual. It states the test is passed if the lamp lights up when the enabling switch is held in the centre position.
Mine is already on before touching the enabling switch so has failed the test.
Anyone got any ideas why this could be?
I'm looking for some clarification on setting up a custom linear track.
KRC5 8.7.6 KR20
I'm using a Kuka motor which i've found in workvisual and added it to the controller, left all the settings as default. Now configuring the Machine Data - E1 where i've changed the properties of the axis to linear but currently everything else is default.
So my question is regarding the Transmission Ratio, Motor/Axis currently set to 100/1. It says revolutions/m so in my mind after measuring it that would be 1/0.044 so one revolution moves 44mm. But i've been reading a lot of posts that suggest it should be expressed as 44000/10000
Can anyone shed some light on this and is there any other properties I should be looking to change before deploying the project for first tests?
Thanks
So firstly if you’re likely to start RSI from different positions why even bother with AxisCorrMon?
And what baffles me is AxisCorrMon A2 set to 190 and starting RSI at 0 degrees why should it exceed A2max at just 45??
We solved the issue by just upping 190 to 235 but not a satisfying solution
Did you set the correction limits inside RSI Visual with the object AXISCORRMON?
Yes, but all are set to the upper limit figure except for A2 which is set to 190 which makes zero sense to me.
If we have the limits (upper and lower) set in AxisCorr what should the value in AxisCorrMon be/represent
Having a strange issue with RSI , we are triggering AxisCorr outside permissible range A2max
Problem is the limits are set to -190 to +45 and A2max warning is kicking in at around -45
Anyone experienced similar
Also it seems to be intermittent which is irritating.
KR10 r1100-2
KSS 8.3
RSI 3.2
I was thinking simpler,
So if you have one input and it pulsed for 30ms for example. So if it was capable of going from false to true and back again in under a second.
I’m assuming 30ms pulse would be enough to turn the interrupt on and move the program to the pause routine.
If you put a wait 5 sec before WAIT FOR NOT $IN[99] would this essentially stop if form checking the input for 5 sec to give the sensor/input 99 a chance to settle?
I thought that maybe the case, I’ll hopefully have the sensors soon so I can have a play with them and see what the outputs are capable of
Is it possible to add a wait to slow down the sample rate of the sensor/input? It wouldn’t matter if the pause had a minimum time once triggered
I see, so the loop would continuously run and pause and start with input 99
Would it be stable if input 99 was triggered in quick succession?
Almost seems to easy when you put it like that.
Do you not have to turn the Interrupt off at some point?
So should the SEARCH() routine contain any INTERRUPT commands..!? what turns the interrupt on for the first time?
Also thank you for this, the help is greatly appreciated.
Yes anywhere along a path at any arbitrary time, would be ideal.
I have read around 10 or so examples of Interrupt code on here but all seem to be different and all seem to go about things in slightly different ways
I've pulled the code below form the KRL-Syntax (please let me know if theres more info in a different manual) but can't get me simple little mind around it.
So from what I understand if input 99 is true it will brake (controlled ramp) then PTP $POS_INT what does this do? Then resume back into Search() how does it know which part of the path to resume from and will it require a BCO run before resuming or anything to figure out where it is?
DEF MY_PROG( )
INI
INTERRUPT DECL 25 WHEN $IN[99]==TRUE DO ERROR( ) SEARCH()
END
_________________________________________________
DEF SEARCH()
INTERRUPT ON 25
... (put my path here with BCO?)
WAIT SEC 0 ; Stop advance run pointer
INTERRUPT OFF 25
END
_________________________________________________
DEF ERROR()
BRAKE
PTP $POS_INT
RESUME
Display More
What’s the best practice for using a digital input to pause a program/robot motion when TRUE and continue from the same point when FALSE without reset or message clearing ?
Also is there any part of the X11 that could act in this manner or do they all require acknowledgements from the smart pad?
Essentially we’d like to set a program running AUT with the smart pad then disconnect it. Then have one button that would pause the program to allow for examination and then resume the program once examination was complete.
KRC4 8.3.4
No not exactly, it varies.
My guess is windows poor time keeping is the issue
Yes multi threaded etc ,
We send/receive 137 packets before our data stream falls over and then at around 6-9seconds the error message is displayed and shortly after KSS crashes
We have now had some success in UDP so we potentially think TCP was the issue which is a shame as we can make TCP much safer
RSI is new to us and we are all working remotely with a lot of trial and error. It would be great to get some clear info as to RSI ‘s potential on windows before we waste any more time and money on it.
Yes and we striped down everything so windows could be at its best and 137 packets before error is the best result we’ve had.
So we are faced with only a few remaining options:
Can windows even do this for us?
Do we revert back to UDP to speed things up that way?
A more powerful PC or switch to RTOS?