AnsweredAssumed Answered

Why is Schrödinger's cat inhabiting ProcessBook VBA?

Question asked by andrew_Inwood on Jul 24, 2018
Latest reply on Aug 21, 2018 by gregor

This is all about PI SDK running from VBA in Processbook.


I have a routine that uses the PI SDK to calculate a lot of PI Values, and write them into a msFlexGrid.  The routine seemed to take a long time, so I was running a timer to see where the bottlenecks were, so that I could optimise it.


The bizarre thing is that when I use breakpoints, it executes significantly faster.  Yes; even stopping, having me hit "run" to move past the break-point, means that it executes about 15 seconds faster.


Execute times when I use breakpoints (two runs, times in ms)

Run 1:

Reading PI Data and updating Grid:2028
Cleaning up PI Interface:780

Run 2:

Reading PI Data and updating Grid:1856
Cleaning up PI Interface:608


Execution times when I don't use breakpoints, and just let it execute:

Run 1:

Reading PI Data and updating Grid:3247

Cleaning up PI Interface:16651

Run 2:

Reading PI Data and updating Grid:1077
Cleaning up PI Interface:16390



So:  When I don't break, the "cleaning up PI interface" takes 16 seconds.  When I do break (breakpoint just before), it takes less than a second.


The Cleaning Up Pip Interface code is a single line:

     Set PI =Nothing


In this case, PI is a custom PI_Interface class, to behind the scenes, its running a Class_Terminate.  That includes:


Private Sub Class_Terminate()

If m_PIServer.connected Then


End If

Set m_PIServer = Nothing

End Sub


Now:  Reading all the data uses this PI_Interface, and I wondered if there was something going on behind the scenes that meant that the breakpoints caused enough of a delay that when I called the set PI = Nothing, the server connection was a bit more ready to close quickly, so I used Sleep(1500) for a 1.5 second delay.  Nope.  Didn't work.


Any suggestions as to why this might be happening?  I'll try again tomorrow after a reboot, but it was pretty consistent today.