VI runs slowly on other PCs

[Hoss183]

...and to Warrior

I have tried on several target machines, and in all case they have been superior to the dev machine (RAM, CPU) and with both XP & Win 7.

In all cases it ran much slower with the RTE than the dev engine.

[Hoss183]

(edited duplicate post)

[Wire_Warrior]

When you run the program on the development machine do you use the exe version or the IDE version?  Might be a clue.  Is it possible that your data acquisition is taking longer, for whatever reason, and slowing the loops down?

Is it possible to share the code?  That might reveal a clue or two.

Jason

[Hoss183]

Sorry, to clarify - both the built .EXE version of my program and the IDE version run fine on the dev machine. (but the .exe does not on others)

(I dont know which engine the .EXE would use if there is the IDE engine present...?)

Theres no reason why the data acq would ber taking longer on other PCs, in fact the VI is in full control of the timing. It uses a USB-Serial converer to clock data serially into/out of the acquisition board. Timing is either as fast as the baud of the serial allows, or with extra delays in VI in certian places.

I'm not sure i can really publish the whiole code, and in any case it wouldnt run without the hardware.

Is there any possiblity the 'wait ms' functions run slower in some cases?

Are there any particular 'time hogs' on the RTE? (I use a lot of local variables, an event loop with a timeout case)

[Wire_Warrior]

I've never hear of the Wait function changing it's timing from computer to computer.  There are no time hogs on the RTE that would be different from machine to machine without some of the aforementioned differences (memory, processor(s), etc.). 

As for publishing your code I do understand that but perhaps if you could share your timing control loop there might be something there.

If you are using lots of local variables then you may want to double check those and make sure you have no race conditions that could impact the operation.  Sometimes they can get a bit sticky.

Jason

[Hoss183]

Ok, heres the main loop part

all event cases are manually triggered by user input buttons.

Even the part you see here just running in the timeout part of the event struct, runs slowly on the target machines.

If i call any of the event cases, they also run slowly.

Dev machine: HP Laptop, XP sp3, core i5 M520 @ 2.4 GHz, 1.86 GB RAM  (normal execution in IDE or EXE - timeout case runs every 250ms )

Target 1: HP laptop, XP sp3, Dual core T8300 @ 2.4 GHz, 2 GB RAM (EXE runs slow - estimate 2-3 seconds for timeout case polling)

Target 2: HP desktop, Win7 x64, Core2 Duo @ 3 GHz, 4 GB RAM (Same as target 1)

[RavensFan]

One thing I notice is that you are writing to a large set of property nodes in every iteration of your while loop to enable or disable a bunch of controls.  I would recommend putting them in an event case that is trigger off the boolean value that is currently determining whether they are enabled or disabled.

[Ben]

USB 2.0 is about 10 times as fast as USB 1.0....

Are the USB ports all USB 2.0 or beter/

Ben

[Hoss183]

- I've moved the property nodes into a event case, that makes no difference.

- It's not a problem with the USB.

[Yamaeda]

---

@Hoss183 wrote:

- I've moved the property nodes into a event case, that makes no difference.

- It's not a problem with the USB.

---

One event for each control value change i hope. Putting them in the timeout makes no difference.

It could somehow be caused by some timeout issue, are all machines connected to a network? Do they react the same if unplugged?

/Y