Runtime script with inexplicable results...

I have a function in my scripts to calculate the runtime in seconds for a program, using the Timer value from windows, which returns the current time as seconds from midnight.

The blue code is my script run at the beginning of a part program. The red code is what is run at the end. (I've cut and pasted these sections from the scripts...they are too long.) In the event that a program runs through midnight, I have a section in the red code to correctly calculate runtime. I've tested this code in the excel editor while resetting my computer clock to 11:59 PM and running it through midnight, and it works. Unfortunately, this code does not work when running PC-DMIS through midnight. I get program times of more than 86400.

Any ideas why this is not calculating correctly only when run through PC-DMIS?

[COLOR="Blue"]Sub Main()

Dim BeforeTime As String
BeforeTime = Timer
BeforeTime = CLng(BeforeTime)

End Sub[/COLOR]

[COLOR="Red"]
Sub Main()

Dim Aftertime As String
Aftertime = Timer
Aftertime = CLng(Aftertime)
Dim RunTime As String

If Aftertime < BeforeTime Then
RunTime = (86400 - BeforeTime) + Aftertime
Else
RunTime = Aftertime - BeforeTime
End If

End Sub[/COLOR]

Parents

Chally72 over 14 years ago

Yes, that is what this does. I do it through a begin and end script because I have operator inputs at the beginning and end of a program, and I want to track the time the PROGRAM runs. I have a separate bit in the same endscript that tracks how long it took for the operator to enter his queries after the program actually finishes. I think you were going to suggest another method of tracking program time, and this is why I haven’t done it like the examples elsewhere on the board.

With the script, I export a txt file with a ton of information each program run, and I pull a lot of data into excel and use pivot tables and charts to track variables such as: Runtime, machine number, delay time, whether the probe crashed or missed during a program execution, number of dimensions out of tolerance, serial number, part number, operator number, operation number, etc….

This allows me to very easily evaluate everything that goes through the CMM. I can see what part goes through the CMM the most, what part always shows bad because of an incorrect program tolerance, where we are losing time because an operator is always away from the machine when a program ends, how much of the day is spent on tooling vs part measurement, etc.
Cancel
Vote Up 0 Vote Down

Sign in to reply

Cancel

Reply

Chally72 over 14 years ago

Yes, that is what this does. I do it through a begin and end script because I have operator inputs at the beginning and end of a program, and I want to track the time the PROGRAM runs. I have a separate bit in the same endscript that tracks how long it took for the operator to enter his queries after the program actually finishes. I think you were going to suggest another method of tracking program time, and this is why I haven’t done it like the examples elsewhere on the board.

With the script, I export a txt file with a ton of information each program run, and I pull a lot of data into excel and use pivot tables and charts to track variables such as: Runtime, machine number, delay time, whether the probe crashed or missed during a program execution, number of dimensions out of tolerance, serial number, part number, operator number, operation number, etc….

This allows me to very easily evaluate everything that goes through the CMM. I can see what part goes through the CMM the most, what part always shows bad because of an incorrect program tolerance, where we are losing time because an operator is always away from the machine when a program ends, how much of the day is spent on tooling vs part measurement, etc.
Cancel
Vote Up 0 Vote Down

Sign in to reply

Cancel

Children

No Data