Slowing down after multiple executions

[Smallsvillanova]

Hello,

So before I went to hexagon for class we used to mark and un mark everything before every execution. Now I keep what I need marked and press CTRL+Q to execute. Never marking or unmarking again after my set up. One of our operators says after multiple executions the program begins to slow down if you don't mark and unmark. Has anyone else heard of this or come across this problems. He said it also is causing him problems with writing the reports as well. I don't have enough experience to confirm or deny what he is saying but personally I have never had the problems he is describing.

thank you

[Schlag]

Leave it to an operator to come up with another reason how the cmm is out to get them..... Make marked set programs and run everything from operator mode. The mark / unmark option isn't available in operator mode..

[Smallsvillanova]

Thanks Schlag. So PC-DMIS does not save or cache any data that would cause the program to slow down eventually under any circumstance? For example if you just kept running the same point over and over none of that data is being cached? Sorry this may seem silly but I do not have enough knowledge to dispute what he is telling me so I just want to be sure before moving forward.

[Schlag]

Operators are the most sketchy part of the whole CMM process. The CMM is out to get them and make their parts bad. They will come up with anything they can to blame the CMM for this or that.... It's kind if an toxic / abusive relationship. I would say to time it but then you're just validating it. Having an operator mark and unmark code seems like a road to un-needed / un-wanted edits to the program. I would lock that down and end this argument.

[Douglas]

of all the times I have been asked to look at a program that gives bad results, it was the dirt left on the part at least 80% of the time

[bherrin]

Might not help with your current dispute, but a GETPROGRAMINFO("ELAPSEDTIME") either in the report or written to another file elsewhere could give you the data to either confirm or dispute that kind of claim later.

[louisd]

I'm not a fan of marked sets. Flow control is where it's at. Add flow control, empower your operators to populate an input (with an error validation) then use that input to control the flow of the skipped segments.

Label/USERINPUT
Comment/input: What operation is this sample at? or Is this a FAIR, a Startup or an In-Process inspection?
Create an if statement to make sure that input is a value that your routine will use.
      If statement fails:
          Comment: Oper: invalid input. type only one of the following values: x y z p d q
          goto/USERINPUT label

from there, make the complete programmed routine.
insert an if_goto before any features you want to truncate,
point it to a label just after the feature intended to skip.

hope this helps.