Writing software limits from sps

    In the application, in the sps the software limits of axis E1 are now written in the submit program :
    f.i. $SOFTP_END[7]=180.0, $SOFTN_END[7]=180.0.
    The writing is always done (no if statement).
    We got reply of custommer that sps is sometimes stopped since we did last changes to the robot.
    The changes were not just the software limits but also other code.
    We did not get the ability yet to inspect the logs of the robot for diagnosis.
    Does anyone know if writing the software limits of an axis constantly in the sps is no problem for the controller, or if it could be the cause for the sps stopping?
    Until we get access to the controller it would be good to know if this is allowed.

    Hello, if in the sps is used $POS_ACT, $TOOL or $BASE they in some cases can stop sps from executing. For example when robot is turned on, those variables at boot have undefined values(you can see that by ? mark in tool and base window). Software limit switch you can also write at the start of the robot program, if you don't need to constantly overwriting the same value over and over again.

    if this is safety related use workspaces in safeoperation. I am assuming to some degree it is as you want to modify them on the fly. Modifying soft limits is not a good practice if this is at all safety related. Even if you choose to do it with soft limits you will have to handle what to do if the axis is over the limit and how to get out of it. And it will not fulfill requirements of any safety function as they can be modified with ease. If this is not safety related workspaces as suggested by fubini is a far superior solution

    Quote from Plc_User

    Does anyone know if writing the software limits of an axis constantly in the sps is no problem for the controller, or if it could be the cause for the sps stopping?

    It would help if you actually posted the code you are using. However, writing to $SOFTx_END should not cause the SPS to stop.

    However, it is not a good practice to always write to system variables. This should only be done when it is necessary.

    Quote from the leg

    Why dont you condition it so it only writes if they are not at the set value .

    As Leg said, the better way would be something like:

    Code
    IF (($SOFTP_END[7]<>1000) OR ($SOFTN_END[7]<>-1000)) THEN
  $SOFTP_END[7]=1000
  $SOFTN_END[7]=-1000
ENDIF

    This way, the system variable is only written to if it is out of bounds.

    Quote from panic mode

    not sure how would that make any difference... the way i see it that may takes more resources than just writing the value continuously.

    Just as a "general practice" thing. You're right that it probably doesn't make any difference with $SOFT, but for $OV_PRO, for example, it would matter.

    I just dislike writing to system variables when it's not necessary. And keeping a standard "style" across all the SPS-writes-to-system-variables lines just seems like a good idea to me.

    I'm not sure it takes more system resources, aside from two extra lines of code for the IF and ENDIF. At runtime, it'll probably take slightly less execution time (although the difference is probably in microseconds, if not nanoseconds, so it's not significant there).

    the effects are hardly measurable on a short piece of code (couple of lines).

    but on a longer code that would become not just easily measurable but obvious. even on short snippet, if one really wants to dive in and analyze differences can be found.

    for example every character in a file takes space and space is one of resources. wrapping code into IF statement make program longer. compound expression in the IF statement makes it even longer and increased length does not make it easier to process or read.

    beside sheer size there is execution. in this case one instruction is used to assign value but even if that instruction is not executed due to check, comparison still takes place and if i recall correctly that takes longer than just doing the assignment directly.

    actually, variable is of type REAL while compared value is an integer so additional implicit conversion takes place and this is done on every scan.

    not sure if KRL does short circuit evaluation but if that is not the case, it would make something like that IF statement more taxing because that would include two conversions, two comparisons, and additional OR operation.

    also the thing is that exact comparisons to REAL are a pitfall since many values cannot be represented exactly using REAL and compare without window may result in code inside IF block being processed anyway.

    so number of operations per iterations for that code can be in best case two assignments (if assigned values are real) and up to several times that because of use of IF statement, assignment and comparison values are integers and added comparisons. adding to that difference in code length, it seem to be less than ideal.

    simply writing limit continuously could be both shorter and computationally more efficient.

    and there could be more to that since modern processors are struggling with clock limitations. so to get better performance different techniques are used (parallelism, deeper pipe, branch prediction, etc.). the goal is to do more than one operation per clock per core. but things like branch prediction exist for a reason - because performance tends to get messed up with comparisons and prediction is trying to salvage what can be salvaged.

    fortunately writing code in KRL does not require same considerations as programming videogame or or some scientific application.

    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

Advertising from our partners