VI runs slowly on other PCs

[RavensFan]

I think you are just going to have to add some code to see how long different sections of your VI take to run.  Put the millisecond timer in there with some indicators.

[Hoss183]

Ok, a development...

I have just migrated my development machine from the laoptop to a new desktop (HP Z400 - Zeon 3GHz, 6GB ram, Win 7 x64)

And it also runs slowly on that machine even when using the IDE.

So it does seem to be something specific to my laptop. Why would that runs VI at a speed that i consider normal, and all other PCs slowly?

I've been trying to hunt for some setting or driver difference, but i dont see anything obvious....

[Hoss183]

In fact its worse...

My code which was generated on the laptop in LV2010, does not run correctly on the new desktop machione in LV2010. (clean install + updates & sp1)

Not only does it run very slowly, but it seems that something (the comms drivers?) has corrupted all of the read values.

This is bizzare and very frustrating.

[DFGray]

As mentioned earlier, you need to put some code in to find out where your slowdowns are occurring.  I have had a lot of success using writes to the Windows debug output.  I wrote up this method awhile back and posted it here.

Using this method, you can dump timestamps to tab separated text files, which can then be read by LabVIEW or any spreadsheet for further analysis.  The better you do your location tags, the easier this will be.

Good luck.  Let us know what you find out.

[Hoss183]

DFGray - thanks that looks very useful i will try that.

But, I still dont see why the same code will runs just fine on my original laptop, slow in the RTE on other PC, and slow+bad readings on my new dev PC.

Surely there must be something in the PC/Driver/Configuration thats different. Is there any global configuration for LV that i can run a diff on?

What else could be so different between a clean install of LV2010 on win7 and a existing LV2010 on XP that causes susch different operation?

[Yamaeda]

How about your program or LV accesses the network or internet and cannot solve the address/doesn't have rights and thus tries until timeout it reached?

/Y

[Hoss183]

It makes no difference having (or not having) network/internet access.

[DFGray]

The usual culprit for such things is drivers.  I have solved these kinds of things in the past by updating video drivers, adding missing VISA, DAQmx, IVI, (insert missing driver here) drivers, etc.

But I have also solved them by noticing issues in the code itself (race conditions, hardware specific implementations, etc.).

Things sometimes work differently, and the only reliable way to find out is to test it.  Until you find out where your code is slowing down, finding out what is slowing it down will be a guessing game.

[Hoss183]

@ DFGray - I have used your excellent debug VI, scattered it around the main loop, and established where the time is being lost.

I have done this on 2 PCs (the original laptop dev machine & the new desktop dev machine)

Below are 2 logs of the same code, running on each machine. We can see that the Read_CPLD vi is taking around 2ms to run on the laptop, and almost 100ms on the desktop.

Slow:

00000000	0.00000000	LVDebug ::: FMCK_Interface.vi ::: readtemp 	
00000001	0.00039836	LVDebug ::: Read_CPLD.vi:2 ::: RCPLD_call 	
00000002	0.09961620	LVDebug ::: Write_CPLD.vi:1 ::: WCPLD_call 	
00000003	0.10151616	LVDebug ::: FMCK_Interface.vi ::: READ_ck1 	
00000004	0.10168411	LVDebug ::: Write_CPLD.vi:18 ::: WCPLD_call 	
00000005	0.10352496	LVDebug ::: Write_CPLD.vi:19 ::: WCPLD_call 	
00000006	0.10554645	LVDebug ::: Write_CPLD.vi:20 ::: WCPLD_call 	
00000007	0.10755793	LVDebug ::: Write_CPLD.vi:21 ::: WCPLD_call 	
00000008	0.11179493	LVDebug ::: Read_CPLD.vi:9 ::: RCPLD_call 	
00000009	0.24161868	LVDebug ::: Read_CPLD.vi:10 ::: RCPLD_call 	
00000010	0.36662310	LVDebug ::: FMCK_Interface.vi ::: READ_ck2 

 Fast:

00000000	0.00000000	[4516] LVDebug ::: FMCK_Interface.vi ::: readtemp 	
00000001	0.00014611	[4516] LVDebug ::: Read_CPLD.vi:2 ::: RCPLD_call 	
00000002	0.00225308	[4516] LVDebug ::: Write_CPLD.vi:1 ::: WCPLD_call 	
00000003	0.00472881	[4516] LVDebug ::: FMCK_Interface.vi ::: READ_ck1 	
00000004	0.00480620	[4516] LVDebug ::: Write_CPLD.vi:18 ::: WCPLD_call 	
00000005	0.00496460	[4516] LVDebug ::: Write_CPLD.vi:19 ::: WCPLD_call 	
00000006	0.00518697	[4516] LVDebug ::: Write_CPLD.vi:20 ::: WCPLD_call 	
00000007	0.00537079	[4516] LVDebug ::: Write_CPLD.vi:21 ::: WCPLD_call 	
00000008	0.00685059	[4516] LVDebug ::: Read_CPLD.vi:9 ::: RCPLD_call 	
00000009	0.00889722	[4516] LVDebug ::: Read_CPLD.vi:10 ::: RCPLD_call 	
00000010	0.01076645	[4516] LVDebug ::: FMCK_Interface.vi ::: READ_ck2 

Thus the main loop, which really only conatins more of these read/write calls, takes 4.25 sec on the desktop, but only 68 ms on the laptop.

I have attached the VI concerned Read_CPLD.vi, and the USB-Serial port manufacturers FT_Write.

From putting debug messages into my Read_CPLD vi i can establish that the time is lost in the FT_Write, but this is just a call to a .dll...

Why would this take 100x longer between 2 pc's of similar performance?

I'm thinking that you are correct DFGray, its a driver issue. But, how? I have the same .dll on both machines....

Still stumped...

[Hoss183]

Actually, It could be the comms .dll, but it could also be something to do with how Labview is calling it.

Some configuration of LV that causes the .dll call to be slow....