Need Help!

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Need Help!

    Hey guys,

    I am new to this world as I have come from years of measuring with a manual CMM (Starrett). I also have a degree and years of experience as a Systems/ Network Administrator in IT. Can someone please explain to me why a program can run on a part consecutively say 6-7 times and then all of a sudden crash and never work properly again. This makes no sense to me as the Datums are established and the part runs through 90% of the program just fine and then on run 7 that's it. It makes attempt after attempt to try and go through the part. Now this was clearly NOT programmed and evident in the prior runs as it performed flawlessly. Working with machines (PCs) in the past I realize these things don't make decisions or adjustments without being instructed to do so. Is this corruption? If it is, is this common? I did not write these programs; however, the gentleman that did has 20 years experience. We are running version 3.2 if this helps. I'm going to hunt the site for a list of bugs pertaining to this version. Any insight would be greatly appreciated. Thanks in advance.

    EC

  • #2
    Originally posted by ElroyCarbon View Post
    Hey guys,

    I am new to this world as I have come from years of measuring with a manual CMM (Starrett). I also have a degree and years of experience as a Systems/ Network Administrator in IT. Can someone please explain to me why a program can run on a part consecutively say 6-7 times and then all of a sudden crash and never work properly again.
    Welcome to PC-Demon (PC-DMIS)!

    Originally posted by ElroyCarbon View Post
    This makes no sense to me as the Datums are established and the part runs through 90% of the program just fine and then on run 7 that's it. It makes attempt after attempt to try and go through the part. Now this was clearly NOT programmed and evident in the prior runs as it performed flawlessly. Working with machines (PCs) in the past I realize these things don't make decisions or adjustments without being instructed to do so.
    In the case of PC-DMIS I seriously believe that they do make decisions or adjustments on their own.

    Originally posted by ElroyCarbon View Post
    Is this corruption? If it is, is this common? I did not write these programs; however, the gentleman that did has 20 years experience. We are running version 3.2 if this helps. I'm going to hunt the site for a list of bugs pertaining to this version. Any insight would be greatly appreciated. Thanks in advance.

    EC

    It is more common than I think anyone would like. I don't know if it is exactly corruption as some of the program still runs correct?

    My best guess is that someone accidentally inserted a move point somewhere in the program and that move point is causing the crash. Either that or it isn't measuring something quite right and an alignment is being affected. A good example of this would be the vector of a cylinder measured with two rows of hits will sometimes be 90º off if the length of the cylinder is close to the diameter. IF such a cylinder were used in an alignment CRASH! That is why 3 rows for a cylinder is always a good idea.

    I would recomend stepping through the program using ctrl+e for each line of code until you get to where it is going wonky. Then something may be obvious.

    Comment


    • #3
      Originally posted by Goodluck View Post
      Welcome to PC-Demon (PC-DMIS)!



      In the case of PC-DMIS I seriously believe that they do make decisions or adjustments on their own.




      It is more common than I think anyone would like. I don't know if it is exactly corruption as some of the program still runs correct?

      My best guess is that someone accidentally inserted a move point somewhere in the program and that move point is causing the crash. Either that or it isn't measuring something quite right and an alignment is being affected. A good example of this would be the vector of a cylinder measured with two rows of hits will sometimes be 90º off if the length of the cylinder is close to the diameter. IF such a cylinder were used in an alignment CRASH! That is why 3 rows for a cylinder is always a good idea.

      I would recomend stepping through the program using ctrl+e for each line of code until you get to where it is going wonky. Then something may be obvious.
      Make sure that your CURSOR is either at the TOP of the program (after the probe file has been selected or at the very bottom of the program, do NOT leave the cursor in the middle of the program.
      sigpic
      Originally posted by AndersI
      I've got one from September 2006 (bug ticket) which has finally been fixed in 2013.

      Comment


      • #4
        Guys thanks for all the input. I ended up just removing the latter end of the program in order to get some of the dimensions. I still am concerned, again I ran the part six times in a row back to back. I was the only individual here and it somehow changed on the 7th part. The program NEVER ran the same again. It apparently created a new path and that was that. I have a fella that comes in later who will assist with my issues (mentor if you will). Thanks again.

        Comment


        • #5
          Another habit you might want to get into, create a backup of all your part programs. Then when something goes wrong, you can recall the backup and compare them. I had one where someone had added one pesky movepoint that I just wasn't seeing. Using the backup helped me to find it!
          Welcome to our world of insanity!
          When in doubt, post code. A second set of eyes might see something you missed.
          sigpic

          Comment


          • #6
            Sometimes the unexplained happens!!! Try rebuilding your probe .I have had weird things happen and a probe rebuild fixed prob on several ocasions.
            sigpic

            Comment

            Related Topics

            Collapse

            Working...
            X