Compiled program is not responding on windows 7

[JFMoynihan]

I've developed a program on a computer running Windows Vista.  The primary loop is a queued state machine.  A secondary loop monitors a heartbeat from a PLC and runs every 8 seconds.  Communication to the PLC and two other devices is accomplished using Kepware, an OPC server.  The LabVIEW program communicates with Kepware using Datasocket.

I have no problems running the program in the development environment, or as a compiled and installed executable, on the Vista computer.

The computer that program is running on in production use has a Windows 7 operating system.  When the compiled and installed executable is started on that PC, the front panel will not show up for more than 60 seconds.  Once it shows up, the program runs with no problem. 

I watched the task manager during start up and the program is "not responding" for nearly all of that 60 seconds.  I have checked the computer logs and can find no messages that pertain to the program start up.  I have disabled several parts of the program to see if I can isolate the problem.  Only when I completely disable the primary loop does the program start immediately.

The first thing that happens with the primary loop is opening a queue. 

Has anyone experienced a similar problem?  I'd appreciate any help on this.

Thanks.

John M 

[Chris V]

Hi JFMoynihan,

Is there any chance that your connection to the OPC server or any other connections you have in your program are slower on the Windows 7 machine than on your Vista machine?

I'm assuming with the queue you are using a producer/consumer architecture?

Have a great day,

Chris

[JFMoynihan]

I am using the same version of Kepware and the same configuration on both computers.  I can run the test system from either computer with no changes to the program, kepware or the test equipment.

The queue powers a queued state machine and is not a producer/consumer architecture.  The program is a test program for parts as they come off the production line and the test process is user driven.  I use an event structure to handle the user interface.  However, the problem is before any initialization of the system takes place.  Once the "not responding" times out, the state machine executes as expected. 

I have 6 controls that are not inside a loop that are bound, using datasocket, to points in the PLC, power supply controller, and a third device that measures partial discharge.  The datasocket connections and obtaining a queue are the first things that should be happening. 

Because the user interface does not show itsself until the "not responding" period is over, I have no reliable way to see what is happening in the program.

[Brian_P]

Is there any way for you to look up in OPC Quick Client to see what is happening during that time when the program is not responding.  This can show us if it is a LabVIEW problem or a server problem.

[JFMoynihan]

values are udating in quick client during the "not responding" period

[richjoh]

"The first thing that happens with the primary loop is opening a queue."

I would put a "Get Que Status" on your development and leave it in a build with FP indicators, then troubleshoot. Not sure about your queues but they will hang when empty.... Likely to happen when you have an empty queue and you code hasn't put a value enqueue yet.

[JFMoynihan]

I enqueue an element immediately after obtaining a queue.  In this case it directs my state machine to run an initialize routine that verifies communication and sets defaults.  That routine does not run until after the "not responding" period is over.