More problems with indexing

  • Filter
  • Time
  • Show
Clear All
new posts

  • More problems with indexing

    I have brought this up before.
    Now we have had a serious crash and I really need to get this figured out.

    V 3.7 MR3

    Older DEA machines and a 1-year old DEA Global
    PH10M and PH10T

    During program execution a tip rotation/index is programed to occur.
    It doesn't (very occasionally).

    This may happen on any of the 3 machines. It happens with older programs written with earlier versions and with programs written with 3.7MR3.

    There are a couple of programs where this happens very often in various places within the program. With those I have inserted an operator comment to stop the action and watch to make sure the rotation works as planned.

    After we catch it (crash or not) the problem will not repeat.
    I think that every time this has happened there is a clearplane before the indexing command.

    This must be created by something I am coding but I cannot figure out what it is. Is it possible that a copied and pasted clearplane/tip change causes this?

    Any ather ideas?

    How can I find what is causing this?

    We now have a 1" long, .200 deep groove in the granite.
    Lately, it occurs to me
    What a long, strange trip it's been.

    2017 R1 (Offline programming)

  • #2
    Well, in V3.5 (all MR's as far as I know) it would miss or skip over the first "UP" move of the first clearance plane in the program quite often. However, if you were to trigger the probe, causing the illeagal touch error, then told it to continue, it would move to WHERE IT SHOULD HAVE MOVED for the "up" move of the clearance plane. So, it appeared that it was going through the move, but not executing it, even though it new it was there. The fix I found to get-around this was to insert a very small incremental move just before the clearance plane move. It never missed the first CP move with an incremental move of 1mm ever. I know you are using a newer version, but could it be a carry-over, maybe, why with 'new' 3.7 program? I don't know, I have not yet had it do that to me. So, try the incremental move, see if that fixes the missed CP move.
    Originally posted by AndersI
    I've got one from September 2006 (bug ticket) which has finally been fixed in 2013.


    • #3
      I am using an older Xcel machine. I found a similar problem, but I was able to determine that the main time my tips failed to index was immediately after a tip change. My solution was to get in the habit of having a move point immediately after the tip change and before the tip rotation. This has solved 90% of the problem for me. The remaining 10% seems to occur when there is an operator comment immediately before the tip rotation, (usually as part of the manual alignment). For the later case the only solution I have found is to watch and make sure it rotates and be prepared to stop it if it does not. HTH
      sigpic"Hated by Many, Loved by Few" _ A.B. - Stone brewery


      • #4
        Have you noticed if this happens when running a program and not marking the manual stuff? Just a thought because in the past I have had that as an issue.


        Do you have a for sure area that you can make it do this(I think you said no)? If so, how about some code to look at?

        James Mannes


        • #5
          This also happens to me but not very often. The last time was about an hour ago but before that I can't even remember.

          I never use clearance planes so I do'nt think the answer lies here.

          Hope this helps


          • #6
            I do what Wes does, in all my programs now, Before and after tip changes and rotations

            B&S Global 544
            Using 3.7mr3


            Nothin left ta dew but :) :) :) !


            • #7
              I haven't had this problem but am curious about a related problem.

              During all of my moves if the tip is triggered by something (air, collision, vibration etc.) the machine will stop and throw up the unexpected hit error. It does this without fail EXCEPT for during the first move immediately after a tip change. If it does encounter a hit (such as say the programmer missed a move point ) it will try to keep going and say, bend a tip, knock the module off the tp20, or cause an overload error for the PH10.

              Anyone know why? I assume something is turned off during the rotate and not turned back on until just before measuring the next feature. This must be a "hidden" command though as nothing shows in the program. Is there a way to "activate" the tip right after the angle change and before the move?


              • #8
                I'm using 3.5 MR2, and I've had this happen to me a long time ago. The occurances were random in the program location and didn't happen every time the program was executed. Then it would happen multiple times during a given run.
                I remember that I had selected an empty CAD level, so my graphics were essentially turned off and executed that way. The program ran faster and error free.
                I believe there must have been corrupt math or many duplicate features in the data, and it affected PS-DIMIS adversely.
                all throttle


                Related Topics