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

  • 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.


    By default, it was assigned to the Digital Input $IN[1025]. But I saw multiple assignments by default to $IN[1025], and being new to this, I assumed they had to be assigned to different inputs. 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].


    Should $MOVE_ENABLE be assigned to an input other than $IN[1025]? The error I get is quite clear about this. But is there some weird resetting that happens when I go back and forth between T1 and AUT EXT?


    Also, am I reading the signal diagram correctly, where it shows $MOVE_ENABLE as a first prerequisite? (see screenshot below)



    Thanks in advance!

  • Place your Ad here!
  • 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.

    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.

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

    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.

    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...

    1) read pinned topic: READ FIRST...

    2) if you have an issue with robot, post question in the correct forum section... do NOT contact me directly

    3) read 1 and 2

  • Thank you panic mode for the detailed notes!


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

    I'm now realizing that I may not have understood the non-synchronization of WorkVisual's Configuration and Programming workspaces, which may have caused the resetting of my changes. I will be mindful of this when I give it another try. But basically, I changed it in on the smartPAD under Automatic External Inputs.


    Quote

    i have shared one variant of the PLC code as an idea so you may check the forum

    Yes, I found that post, and I have downloaded the PDF of your sample code. I found your explanations of level-sensitive and edge-sensitive very insightful. Although I was already familiar with "rising edge" and "falling edge" of signals in general, I hadn't noticed/realized the edge-sensitivity of some of these AUT EXT signals in the signal diagram!

  • panic mode


    Could you please explain a bit more about generating the 10Hz clock? I'm not yet able to implement something like that on my PLC. I'm also using FBD, and some of the ladder logic is lost on me. Should I generate pulses in a SFC and loop back based on whether or not $PERI_RDY has been turned on?

  • 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

    Code
    BIT := NOT BIT


    or

    Code
    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:


    Code
    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.

    1) read pinned topic: READ FIRST...

    2) if you have an issue with robot, post question in the correct forum section... do NOT contact me directly

    3) read 1 and 2

  • here is pseudo diagram of one version

    Thank you. I understand what I asked is a bit off-topic for this forum. I was having a bit of a brain freeze yesterday in regards to generating a pulse train, so I ended up asking the question here.


    I did manage to generate a pulse train of about 10 Hz frequency, and I'm feeding the signal into the byte. I still cannot get $PERI_RDY to turn on.


    The only case where I can make $PERI_RDY turn on occasionally is using a single time-delayed pulse using TON. But even this doesn't work for repeatability.

  • 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.

    1) read pinned topic: READ FIRST...

    2) if you have an issue with robot, post question in the correct forum section... do NOT contact me directly

    3) read 1 and 2

  • panic mode

    Thank you for your extensive notes.


    After a lot of tweaking and working the code, I am now successfully past the stage where $PERI_RDY is ON.


    However, I can't get $PRO_ACT to go TRUE after sending the $EXT_START pulse, with adequate wait time.


    Does $EXT_START by itself trigger the running of CELL.SRC, which then turns $PRO_ACT to go TRUE?


    Do I need to change to T1 mode and select and run CELL.SRC until BCO run is complete, and then switch back to EXT and then pulse $EXT_START? I've tried this, but it doesn't work because CELL.SRC is now stopped and the "R" indicator is red even in EXT mode.

  • 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

    1) read pinned topic: READ FIRST...

    2) if you have an issue with robot, post question in the correct forum section... do NOT contact me directly

    3) read 1 and 2

  • Does the operator close CELL.SRC after BCO? Because leaving it open, it is stopped and the "R" in "SIR" is red, not green when mode is changed from T1 to EXT.


    "R" can be green only if CELL.SRC is running, not stopped. Is there a special way to run CELL.SRC?


    And from reading your notes "SIR" all need to be green??

  • 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.

    1) read pinned topic: READ FIRST...

    2) if you have an issue with robot, post question in the correct forum section... do NOT contact me directly

    3) read 1 and 2

  • 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.

    Not inventing things... there is a lot of conflicting information out there, even in the manuals. Or there just isn't enough information. Manuals do not explicitly say to select CELL.SRC and do BCO run. Nor did KUKA tech support. They said the code in SPS.sub should automatically select and run CELL.SRC if robot is in EXT mode.


    The signal diagram is not explicit about having to manually select CELL and do BCO in T1. All it says is $EXT_START triggers CELL to run.


    Code
    IF $MODE_OP==#EX THEN
    
        CWRITE($CMD,STAT,MODE,"RUN /R1/CELL()")
    
      ENDIF


    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.

  • 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:



    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).



    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...).


    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

    1) read pinned topic: READ FIRST...

    2) if you have an issue with robot, post question in the correct forum section... do NOT contact me directly

    3) read 1 and 2

  • 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...).

    Yes, of course the preconditions are met. As I wrote in post #8 above, I have $PERI_RDY on, and I also have the other signals in their correct state - $STOPMESS off, $MOVE_ENABLE on, $DRIVES_OFF on. I'm at the point of $EXT_START.


    I just cannot figure out what is wrong.

  • 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).

    I like this.... I will do this as well. Just to confirm, this code would go in the USER PLC fold, correct?


    How do you check if wrong program is selected?


    Thanks!

  • So I added this code inside the LOOP..ENDLOOP:

    Code
    IF ($MODE_OP==#EX) AND ($OUT[1021]==TRUE) THEN ;$OUT[1021] is PERI_RDY
        CWRITE($CMD,STAT,MODE,"RUN /R1/CELL()")
    ENDIF

    Now, I can get the SPS to select and run CELL.SRC when I switch from T1 to EXT. It doesn't seem to need $EXT_START.


    $PRO_ACT is TRUE.


    My PGNO_TYPE is 3, so according to the manual PGNO_REQ, PGNO_PARITY, PGNO_VALID are not evaluated.



    So, how does this alter the sequence of PGNO? I mean, when should I send the PGNO from the PLC?


    Right now, I'm getting an error "Incorrect program number" from P00. I read through P00.src, but I didn't find where this error is generated in P00.src.

  • Well, now I'm getting a different message.


    After switching between T1 and EXT, the error message "Incorrect program number" is gone.


    But, I'm getting "SIMULATE 3 Wait for not Input 40".


    This is weird because I have mapped $IN[33]-$IN[40] as the program number, and I am using program number 1, so it is [0 0 0 0 0 0 0 1] i.e. Input 40 is TRUE.


    The details on the message are:


    Possible causes

    1. Cause: KRC_Interrupt is set

    Solution: Call KRC_Continue

  • 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

    1) read pinned topic: READ FIRST...

    2) if you have an issue with robot, post question in the correct forum section... do NOT contact me directly

    3) read 1 and 2

  • "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

    Does PGNO_TYPE 3 work differently? The last few tries, I'm not getting "Incorrect program number" but some other message (see post #17).


    $IN[33] to $IN[40] i.e. 8 bits are mapped as PGNO.


    Type 3 is simple enough it seems. So I sent [33-40] = [00000001] for PGNO=1 but it gave me the message "Wait for not input 40". When I changed the bits to [10000000] it gave me the message "Wait for not input 33".

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account
Sign up for a new account in our community. It's easy!
Register a new account
Sign in
Already have an account? Sign in here.
Sign in Now

Advertising from our partners