Writing my own home check (instead of P00 CHK_HOME)

  • Quote


    $H_POS=XHOME
    IF CHECK_HOME==TRUE THEN
    P00 (#CHK_HOME,#PGNO_GET,DMY[],0 ) ;Testing Home-Position
    ENDIF



    This is the original snippet from the basic cell.src template.


    Is the $H_POS=XHOME line necessary? Aside from that I am going to be writing my own home check..


    I basically have three home positions from which I would like the robot to be able to start. XHOME, XHOME1 and XHOME2. I was planning on writing a fairly basic if statement to check for one of three positions. Has anyone done this? I am just wondering if I will run into any unexpected issues from doing this. Thanks.

  • Place your Ad here!
  • Basically $h_pos is what it looks for for the home position, you are just making it to be the same position as XHOME.


    I think this is to make it backward compatible with older versions of KSS, I've never used multiple home positions but there was a thread about in the other week or two.

  • I know already that I can assign up to 6 home positions... my question is more specifically regarding the home check in cell.src. Will any one of the home positions create a chk_home=true condition?


    I need to be able to completely abort all programs and start back up from cell.src in any of the home positions :smiling_face:

  • It appears P00 home check only looks at $IN_HOME which is xHOME, not any others... so P00 calls an If statement. I'm just going to skip all the nonsense and put my own check in..


    Thanks for the help anyway. I'm 97.5% sure my own check will work without any issues. I'd really like to not use any p00 functions if I can help it.

  • It's not hard to do. You can simply compare the values of $AXIS_ACT to your "home" position, using a tolerance band, like so:

    Code
    DECL BOOL CheckPassed
    CheckPassed = (ABS($AXIS_ACT.A1 - MyHomePos.A1) < Tolerance.A1)
    CheckPassed = (CheckPassed AND (ABS($AXIS_ACT.A2 - MyHomePos.A2) < Tolerance.A2) )
    .
    .
    .
    CheckPassed = (CheckPassed AND (ABS($AXIS_ACT.A6 - MyHomePos.A6) < Tolerance.A6) )
  • I was thinking of something even simpler...




    Would this not work?...

  • Ah, well, if you have all the various HOMEx positional variables set, then yes, that'll work. Although this might be simpler:

    Code
    HomeCheck = (($IN_HOME1 EXOR $IN_HOME2) EXOR $IN_HOME3)


    Reduces it down to one line.

  • Here's another way to do it: (for reference)



    This is under the assumption that 59 and 60 are already configured for home 1 and home 2. This way is not really that great as all you are doing is modifying home0 (as I call it) to reflect home1 and home2 so you can pass the silly p00 homecheck which only checks H_POS.


    It is also possible to add a few lines in P00 to check for the other home positions but to me this seem the longwinded way of doing it...

  • Yeah, since the Signal assignments can change, the better way is to simply access the $IN_HOMEx variables directly.


    P00 isn't holy writ -- it's intended as much as a template as an actual ready-to-use program. There's no reason you can modify the Home Check section of P00 for your own application.

  • The reason I'm trying to stay away from it is to make the program easier to understand for operators and on the floor techs. There are a lot of people that get confused when variables are passed back and forth between routines and/or when the operation of the code isn't extremely obvious...


    This is my new cell.src:


  • Another way to make things easier to understand.....why not use SIGNAL declarations?


    SIGNAL name $OUT[18]


    The you could use name=FALSE in your program, which would be easier for others to work out what is being set false.

  • Yes, I realized that yesterday and drew up the IO declarations for each robot. It will help big time, the way I was doing it before I had to add comments everywhere there was IO...


    My question is though, where and when do the signal variables get updated? Do they get updated at the exact same time as the IO table or do they have to run through a scan first?

  • Eusty is correct -- from the system perspective, $IN[1] is no more, or less, valid a "handle" to a given bus signal than any SIGNAL declaration you make yourself. The only difference is that $IN and $OUT are "baked in" at the factory. But input updates are all simultaneous, and all outputs are effectively instantaneous (interrupt-driven).

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