Instability in Karel Loop Routine

    Hi, I found a very strange thing with Karel looping.


    So we tried a simple test loop with 8msec interval. The test code reports the time every loop. I was expecting a nice 16msec interval, but it turned out, it would do 8msec for about 6-7 times before it missed a cycle, see the plot at the attachment.


    This is very strange. Is there anybody who also has similar experience?


    Thanks,


    Jay




    PROGRAM ZKAREL

    %ALPHABETIZE

    %COMMENT = 'ZKAREL//r0b'

    %NOLOCKGROUP

    %NOPAUSE = COMMAND + TPENABLE + ERROR


    TYPE

    dpmm_t = STRUCTURE

    shutdwn_req : BOOLEAN -- program abort requested status

    ENDSTRUCTURE

    CONST

    LOG_PFIX = 'ZKAREL '


    VAR

    this_ : dpmm_t -- prog instance

    stat_ : INTEGER

    inputs : ARRAY[19] OF REAL

    pos_log : FILE ---log

    time_pos : INTEGER


    ROUTINE handle_tp_data(this : dpmm_t;pos_log: FILE) : INTEGER FROM ZKAREL

    BEGIN

    stat_ = handle_tp_data(this_,pos_log);

    END ZKAREL


    ROUTINE handle_tp_data

    VAR

    stat__ : INTEGER

    BEGIN

    time_pos = 0;

    inputs[1] = 1.0

    OPEN FILE pos_log('RW','ud1:POS_log.txt')


    WHILE ( DOUT[1] = OFF ) DO

    CONNECT TIMER TO time_pos

    WRITE pos_log(time_pos,inputs[1],CR)

    DELAY(16)

    ENDWHILE

    lbl_hc_break::

    CLOSE FILE pos_log

    DISCONNECT TIMER time_pos

    RETURN (-ABS(stat__))

    END handle_tp_data

    Most Fanuc robots have an 8msec scan time. My guess is you are too close to that edge that occasionally you get an extra scan.


    I wouldnt expect a delay function to be deterministic down to the exact msec.


    What happens if you set delay to 10?

    Quote from HawkME

    Most Fanuc robots have an 8msec scan time. My guess is you are too close to that edge that occasionally you get an extra scan.


    I wouldnt expect a delay function to be deterministic down to the exact msec.


    What happens if you set delay to 10?

    Am I completely misinterpreting this section of the Karel manual, or is Fanuc outright saying there is an extra 8msec delay every 250ms (by default) on top of the actual scan cycle.





    I'm not sure how often op is seeing this extra delay (the x-axis of his graph seems to imply it's more often than every 250ms) Ops graph shows the extra delay is happening every 96ms, but maybe his controller has a different default %Delay value or this is part of it? Please let me know if I'm being an idiot and not understanding the manual here though.

    Quote from HawkME

    Most Fanuc robots have an 8msec scan time. My guess is you are too close to that edge that occasionally you get an extra scan.


    I wouldnt expect a delay function to be deterministic down to the exact msec.


    What happens if you set delay to 10?

    OK，I will try and report back. But I think if I do delay(10), I will still get 16msec according to the manual. The extra scan, if it is, happens very regularly.

    Thank you. This is very interesting. We will give it a try and report back.

    Dear Erik,


    Indeed, with %delay=0, the problem is gone. Thank you!


    Jay

    You might already know, but delays exist for a reason. At least this one.


    It prevents the round-robin scheduling from not being able to suspend your task.


    Runaway programs are much harder to deal with without some forced yielding every now and then.

    Quote from rf103

    You might already know, but delays exist for a reason. At least this one.


    It prevents the round-robin scheduling from not being able to suspend your task.


    Runaway programs are much harder to deal with without some forced yielding every now and then.

    Does a delay of 0 still fulfill this purpose? Or would some "greater than 0" value be needed to ensure protection against runaways?

    Quote from rf103

    You might already know, but delays exist for a reason. At least this one.


    It prevents the round-robin scheduling from not being able to suspend your task.


    Runaway programs are much harder to deal with without some forced yielding every now and then.

    It is actually quite easy to put a conditional break in the loop. So it will not become a problem of runaway.

    Well, we thought the problem is solved, but it isn't. It just had an improvement, but when we taking longer data, the system still shows instability. So with %delay=0, the instability which occurs every 100ms or so is gone. But the problem shows up at a much less frequency, see the plots attached. It must be the system wonders around doing some extra stuffs. （The X axis is count and the Y scale is usec)

    Interesting. It seems that there is always a matching short and long cycle so it probably averages out to the correct total time.


    I think you are probably at the limits of what the controller will do. In my experience Fanuc controllers are very slow processing compared to a PLC or microcontroller.


    Does your application require it to be this precise it is it just a curiosity of yours?

    Quote from 4wheeled

    Well, we thought the problem is solved, but it isn't. It just had an improvement, but when we taking longer data, the system still shows instability. So with %delay=0, the instability which occurs every 100ms or so is gone. But the problem shows up at a much less frequency, see the plots attached. It must be the system wonders around doing some extra stuffs. （The X axis is count and the Y scale is usec)

    I assume the controller is still occasionally performing some lower-level functions that result in this instability. If consistency in your application is more important than raw polling rate, then it may be worth trying to add your own short wait that occurs every cycle, while still keeping the %delay at 0. This might give the system time to perform other operations without causing an unpredictable, longer cycle. Try increasing the length of this wait until the instability is gone or you are no longer cycling fast enough for your application.

    Quote from HawkME

    Interesting. It seems that there is always a matching short and long cycle so it probably averages out to the correct total time.


    I think you are probably at the limits of what the controller will do. In my experience Fanuc controllers are very slow processing compared to a PLC or microcontroller.


    Does your application require it to be this precise it is it just a curiosity of yours?

    Yes that is very strange. And we also approached Fanuc Japan for support on this one but they said it was too fundamental an issue that they would not be able to support us at the moment.


    The application we tried to run is the DPM, which is also lacking factory support. So maybe we will consider giving up Fanuc. The RSI from Kuka is much easier to run.


    DPM requires an update rate of 8msec which seem to be the limit on this system.

    Quote from Erik Olsen

    I assume the controller is still occasionally performing some lower-level functions that result in this instability. If consistency in your application is more important than raw polling rate, then it may be worth trying to add your own short wait that occurs every cycle, while still keeping the %delay at 0. This might give the system time to perform other operations without causing an unpredictable, longer cycle. Try increasing the length of this wait until the instability is gone or you are no longer cycling fast enough for your application.

    Thank you Erik for the advice. This is excellent thinking. But it seems that the minimum time unit is 8msec. And the application that I'm running requires an 8msec cycle too. So I'm not sure I can add a short wait like 1msec, but maybe I will give it a try.

    What controller version are you running?


    The R30iB+ offers a 4ms ITP. This is probably one of the biggest advancements of the controller versus previous versions. Before this version, the ITP had been 8ms for a long time. I think as far back as the RJ3. I couldn't attest to anything older than that. Although, I don't know if DPM can truly keep up. I can find out if you're interested.


    Two other huge improvements of the R30iB+ controllers are:


    1gig DRAM file storage. Yay we're getting late 90's PC performance, albeit this is more impressive since it's on a RTC.


    The other is spline motion, although I've yet to test it. I have a specific application that I REALLY wish I could test this on. Some have told me though that karel path motion could work also. I don't want to hijack this thread, so if anyone has an opinion on this, please PM me or feel free to start a new topic. (Or PM me to let me know I should do it myself😏)

    We are using the newest version which is the R30iB+. Yes, we are working on DPM and it has been a lot of problems as I stated above. Thanks for the help.

    Quote from rf103

    4wheeled: what is it you actually want to do?


    Discussing these Karel VM scheduling details is interesting, but perhaps not the most efficient way to go about achieving what your goal is.

    Hi, we are trying to run the DPM and it looks like the looping problem causes DPM interruption because DPM needs offset input every ITP of 8msec.

Advertising from our partners