Should $MOVE_ENABLE be assigned to an input other than $IN[1025]?

normally $MOVE_ENABLE is always TRUE. this is why by default it is mapped to input 1025 (always true).

but in EXT mode robot i controlled by PLC. this signal simply give a way for PLC to say "oooops this did not go according to plan, better stop everything....". so if PLC needs, it can stop robot easily and quickly. that may not sound like something special but let me tell you - it is a very important feature.

some 15-20 years ago i was asked to assist with programming of the machine which used linear actuator as an adjustable hard-stop for another device. don't remember brand but basically it was just a linear jack that was controlled over profibus. it would move to programmed position and stay there for a while. the actuator was not very fast (maybe 80mm/sec) but it was very strong and stroke was less than 500mm. unfortunately there was nothing tied into it to stop it directly. so in case one needed it to stop, all one could do is issue sequence of commands. each command was telegram of few bytes containing command word and bunch of other parameters. it was not on a safety circuit because it was inaccessible by operator. but it could do significant damage that would be mess to repair.

unfortunately it did not have direct way of triggering stop and since some of the signals are edge sensitive and rely on feedback of previous message, things could easily go wrong. and that would mean more commands to cancel and start again - while this thing is still moving relentlessly.

KRCs have $MOVE_ENABLE for just this purpose - to easily and reliably stop robot without IFs and BUTs. it is not a safety signal but it sure is a handy thing to have.

the timing diagrams in KUKA manual show the sequence of signal transitions in normal (expected) cases. things on the time diagram are in order of time progression and it is not to scale, it is compressed to fit the page. but for discussion we could pretend that each of the vertical dashed lines is 1second increment just to easier communicate things.

Quote from robotninja

Should $MOVE_ENABLE be assigned to an input other than $IN[1025]? The error I get is quite clear about this.

normally this is set to input 1025 in all cases except when robot is in EXT mode because that is when decisions are done by PLC so PLC need a way to say stop. This is why when planning to use EXT mode, this signal should be changed from input 1025 (always true) to some other input that PLC can control.

optionally one can disable move enable check. in this case message you saw would be gone even if move enable is still on input 1025 ...but ... obviously this is not recommended and should be used only in special case after considering all risks and potential effects.

Quote from robotninja

Hi everyone,

I'm currently working on coding the most basic AUT EXT signal timing diagram (reference: Section 6.22.7, Figure 6-25, page 289 of the KSS8.6 SI V7 manual).

I have read and re-read the explanation given in the SI manual (Section 6.22.3.8) for $MOVE_ENABLE, but I'm still confused.

So, I assigned $MOVE_ENABLE to $IN[100]. However, this doesn't seem to have resolved the issue. And the assignment change hasn't been taken by the controller. It is still defaulted to $IN[1025].

Display More

that should work. how exactly did you change it and where?

Quote from robotninja

But is there some weird resetting that happens when I go back and forth between T1 and AUT EXT?

it could be... all depends on login in PLC. i have shared one variant of the PLC code as an idea so you may check the forum. it is just an example, not a silver bullet for every case.

Quote from robotninja

Also, am I reading the signal diagram correctly, where it shows $MOVE_ENABLE as a first prerequisite?

yes...

initially (at time "0") pretty much everything is false, the only signals that are TRUE include :

$IN_HOME : this part is done manually when CELL.SRC is selected and before switching to EXT mode.

$I_O_ACTCONF : this should always be true (result of $I_O_ACT being assigned to input 1025)

$STOP_MESS : robot is faulted since drives are not on yet - in T1 during BCO drives were on because operator was using enabling switch to get robot to home position.

then it starts by operator dealing with safety ($ALARM_STOP and $USERSAF are true) and following that PLC setting initial signals ($MOVE_ENABLE, $DRIVES_OFF). this part is compressed so it looks like at "0.7sec" all of them are instantly on. in reality they do need to get to that state but edges do not line up that perfectly. and the edges do not matter here - these signals are level sensitive (no edge sensitive)

then at "1.5sec" there is a pulse on $DRIVES_ON. rising edge here causes drives to turn on ($PERI_RDY becomes TRUE). this is an example of edge of $DRIVES_ON resulting in level change on $PERI_RDY. the thing about edge sensitive signals is that they do not care about level, they only respond to signal change. in case it is a rising edge ($DRIVES_ON had to be low for at least 20ms, then change to TRUE for at least 20ms). that is what makes $PERI_RDY to turn TRUE. if the $DRIVES_ON was already on, there would be no transition from FALSE to TRUE and this would not turn on the drives.

then the pulse need to be issued to $CONF_MESS to clear/acknowledge robot messages. this too is edge triggered change making $STOP_MESS to go false.

finally, one more pulse is needed on $EXT_START. this would make robot start running CELL.SRC. once this is working, everything on top of smartPad is green and robot is ready to move...

this part of the handshake happens every time you need to get CELL.SRC started. but once the CELL is running, these signals no longer change - except when you WANT to stop robot.

what remains is telling to robot which program to run. so PLC need to set the PGNO to some value, verify that robot sees the same thing and then turn on PGNO_VALID. at that moment, CELL calls one of the user programs. when PLC sees that, it need to turn off PGNO_VALID,,,

when robot is done and returns home, PLC need to send same or another program number then again confirm that robot really sees the value and then pulse PGNO_VALID again...

well... don't you think it would be a good idea to share what that PLC is? also this is a robot forum, not a PLC forum. finally working with timers is basics regardless of platform and forum is not meant to replace formal training. if one does not understand basics, automating industrial robotic cell is not something to start learning on.

most PLCs already have flags or free running clock. in some cases one may need to map it to some variable range. there could also be ready instructions that generate pulse train. and finally nothing stops one from making own clock using timers or counters or whatever...

clock is simply signal that repeats at some rate. in software this is usually done by using timer, specially when accuracy is required. also on some systems timers may be precious resource (old or small PLCs), therefore it is always good to know how to solve something in more than one way.

if using timer, simply enable timer until it is done. then use done state to reset timer.

in ladder file i shared, that oscillator is exactly as described, NC contact of timer done enables and disables timer. and since contact is NC the run reads "if timer_X is not done, run timer_X"

the fastest oscillator in software is limited by scan time and looks like this.

things on left are "condition" and things on right are "results"

note that both use same thing, just that one of them is inverted.

in this case condition is inverted (using NC contact) but as long as there is inversion at one place (could be coil at least on some PLCs) and code is processed continuously, there will be some oscillations.

following line simply tells : if BIT is not True, make BIT True, If BIT is True, make BIT is False.

in ST that would be

BIT := NOT BIT

or

BIT:= BIT==FALSE

but this example is not very good, this would be too fast for interfacing to robot.

using timer, one can simply bring inverted Timer.Q to Timer.IN and the same process would be repeated but this time, timer would be involved and delay signal change.

such signal is asymmetric, Timer.Q would only turn on for an instant (one PLC scan). so duty cycle is VERY low. one option is to add another timer or flag to keep track of things - the goal is not to use this asymmetric signal but that is convenient intermediate step to produce 50% duty cycle.

since BOOL flag is just one bit, it takes less resources than a timer, all we need to do here now is to flip some bit when Timer.Q is True. this way it is guaranteed that duty cycle is 50%.

so... how to flip the bit? there are many ways actually. some PLC brands have special instruction for this (KEEP, FF, ALT etc.). but one can do the same with XOR function. and XOR function is not brand specific, it can be used on any PLC (even yours, although we still have no clue what that PLC that is of what instruction set it uses).

here is pseudo diagram of one version

but since timing here is not critical one does not even need to use a timer. it is perfectly fine to use a byte or INT or whatever. just increment it couple of times to get to desired value then reset it. and use that reset event to toggle the flag so you get 50% duty cycle.

first convert frequency to time. f=1/T or T=1/f

so for 10Hz clock, we need signal that repeats every 0.1sec. and for 50% duty cycle that means signal is TRUE for 50ms and false for remaining 50ms.

next we need to know PLC scan time. again no clue what PLC you have there but lets assume scan time is about 3ms. 50ms/3ms is about 17, this means every 17 scans toggle the flag that is used as a clock.

example:

I := I+1    ; increment
IF I >= 17 THEN ; only keep desired number of bits (in this case 8)
  I:=0 ; reset count
  Output1 := NOT Output1 ; toggle output1, this can be out clock signal
ENDI

Btw, if interested in playing with ladder but have no PLC, there are online simulators like this one, it also works on the phone.

you need to do things in steps in accordance with timing diagram from SI manual...

since some signals are edge sensitive, it is important to do things in correct order.

so before you start programming, connect couple of switches to your PLC, and use signal of those switches to activate the outputs that control robot. then produce signals in documented order. this should be easy to accomplish but even if takes few tries, it is an easy way to test. once you are done, program logic that does the same things in exact same order.

sine robot/plc connection uses IO, latency of the IO must be taken onto account. do not generate signal trains too quickly or robot may not be able to see them. make sure that your outputs are glitch free. a lot of inexperienced programmers will create something that may "look" ok but it does not work. as a rule of thumb KUKA recommends that minimum duration for any signal is at least 20ms.

here is an example of a common problem, signal as seen in software or on output LED may look solid more or less but in reality is oscillating (glitchy) or off time is way too short so robot does not even see that signal was ever low:

so here we go:

1. if in EXT mode, it is expected that robot is already at home and program is selected. so first thing is to set drives-off and move enable to TRUE, set drives-on, ext-start and conf-mess to FALSE. yes, you can do it all at once but then comes the key point...

2. wait at least 20ms (this is important). this is preparation for the rising edge that will follow.if you do not WAIT, signal here may look like "PROGRAMMED #2" (off time way too short) and handshake will not work - at least not RELIABLY.

3. if in EXT and robot reports problem (stopmess), acknowledge it by turning on conf_mess. the signal must be TRUE for at least 20ms to be reliably detected by the robot. this rising transition can be done more than once (if so desired) but it need to be done at least once if stopmess is TRUE. if it did not work on first attempt, turn off the conf_mess and wait at least 20ms before turning it on again for at least 20ms. when successful, stopmess will turn off and we can proceed to the next step. note: you may not always be able to acknowledge faults this way. some faults cannot be acknowledged remotely. for example if EStop is pressed on the smartPad, toggling output will not magically release that EStop. if the cell door is open, toggling conf_mess will not close the cell door. how and when conditions are going to be met will depend on user awareness too so you may want to alert them that something need to be done.

4. if the process so far worked, robot is still in EXT mode, drives-off is TRUE, drives-on is FALSE, move-enable is TRUE, and confmess is false (so you can stop pulsing the conf_mess).

5. at this point drives-on is still FALSE (was that way since first step) and that was at least 20ms since we started. you can wait a bit longer if needed but this signal too has to be low for at least 20ms before proceeding.

6. turn the drives-on to TRUE and wait at least 20ms. that will produce desire rising transition and drives will be on - unless something still prevents that (door or estop or someone changed mode to something else). if the drives are on (pery-rdy is on) then this step is complete. and we can move onto next one.

7. at this point robot is still in EXT mode, drives off is TRUE, drives on is FALSE, move enable is TRUE, and confmess is false... if you followed this exactly, so you can wait some more before net step

8. since the ext-start was false the whole time (well since step1) we can go to the next step. if for some reason it was not TRUE, forst you need to turn it to FALSE ad wait at least 20ms. then you can proceed

9. now it is time to turn ext-start on and this too has to last at least 20ms. if you followed procedure correctly, you will have robot running CELL and all indicators on top of smartPAd are green.

read the manual. this will start program if it is already selected. but if no program is selected it does nothing.

operator is supposed to manually select CELL.SRC and perform BCO. once the robot is at home and BCO is done, THEN operator is supposed to change mode from T1 to EXT and THEN the PLC logic can take over.

to know what is going on you need to look at the states of signals listed in AutoExterna. interface

where do you get that idea? did manual or I state that program need to be closed after performing BCO?

stop inventing things, just read and follow instructions.

color of R indicates program state. red means program is not running any more. that is fine. do NOT cancel program after BCO (CELL must still be selected). then change mode to EXT.

side note - it is possible to create code that automate things:

a) checks if mode changed to EXT

b) checks if robot program is selected

c) checks if that is a correct program or not. if wrong program deselects it. if no program is selected it selects the correct one (CELL.SRC).

d) starts it

and i do it all the time. but (there is a big BUT in there) this is not for noobs and must be done correctly - because there is no BCO in EXT mode and if robot is not at home, robot would try to get there and likely crash into something. so for this to be used one must spend time to develop and test home recovery procedure. that that procedure need to be used to bring robot home safely.

then user can do anything they want but robot will still use smarts of the program to get home safely. since this is a custom engineered solution, it is not prepared for you. this is why KUKA documentation tell you to use operator to perform initial part of start - select program ,get the robot to home position and then switch to EXT.

Quote from robotninja

Manuals do not explicitly say to select CELL.SRC and do BCO run.

yes they do. you mentioned system integrators manual for KSS8.6 version 7 so here is the screenshot from that very manual. it clearly states in 8.11 what needs to be done when robot is to operate in EXT mode:

Quote from robotninja

Does it make a difference if I switch from T1 to EXT, or have it in EXT mode at cold start?

I have tried multiple times selecting CELL.SRC in T1, doing BCO run and then switching to EXT, and then sending $EXT_START pulse. But nothing happens. $PRO_ACT never turns on.

I have not modified SPS.sub at all. CELL.SRC only to add my motion program in the switch cases.

it does make difference what the operating mode is on startup - check content of the SPS.SUB

before LOOP/ENDLOOP there is a CWRITE that should select CELL.SRC if robot is in EXT mode.

but because this is before LOOP/ENDLOOP, it will only be processed once - on powerup.

so IF on powerup mode is EXT, this will select CELL.SRC. but if the mode is different, this will do nothing.

personally i do not like that so i have my own code that is called inside LOOP/ENDLOOP and therefore acts even after startup. so in my add-on code i check mode. when mode is EXT and wrong program is selected, program is deselected and then CELL.SRC is selected (or whatever my main program is).

Quote from robotninja

I have tried multiple times selecting CELL.SRC in T1, doing BCO run and then switching to EXT, and then sending $EXT_START pulse. But nothing happens. $PRO_ACT never turns on.

That is possible of course because that is not good enough.

triggering start will not work if preconditions are not met. first you need to follow the sequence and get robot into operational state (clear messages, enable drives...).

Quote from robotninja

I have not modified SPS.sub at all. CELL.SRC only to add my motion program in the switch cases.

that is fine, you do not have to unless there is something specific you want to accomplish

as you noticed, CWRITE function with "RUN /R1/CELL()" will not just select but also start program.

to prevent that and just select (but not run program), use CWRITE while move enable is low.

"Incorrect program number" is displayed when number that PLC is selecting is not used in CELL.SRC.

for example CELL has cases for program numbers 1,2,3,4,5 but PLC sends program 9

Last I remember the start number for PGNO is the lowest bit for PGNO. That is, in your case, if PGNO=IN[33..40] that IN[33]=1 and all others 0 means PGNO=1.