Compatibility of windows xp with labview and windows 2000 with labview

[RobinX]

I have a very weird situation that I am not sure even I can decribe it clearly. The thing is we have two set of equipments. One: windows 2000 with DAQ card, PCI card, the other is windows xp with same DAQ card and PCI card. All the labview software are the same version. All the program are the same. But the program on windows xp has a really weird problem. Sometimes, the signal is wiped out when I run the program and sometimes it doesn't. I am curious whether the two windows system have different order sequency. Is it clear? I am really sorry about the description since the problem is really strange. Thank you very much!

[RobinX]

With more research, I think I probably find the problem but I don't know how to fix it. Here is how the program work. In Calibrate LC.vi, there are four buttons of "set". When you hit set button, the program will aquire 10 data points which will form the signal we need. But the problem is when I hit set button, no signal at all.So I am thinking the program didn't aquire any data in. I uploaded the Calibrate LC vi and also the Aquire Data vi. Does anyone can give a suggestion how on to fix the problem? Also, I double checked the PCI card. The interrupt request for PCI 6036E in windows2000 computer is 19, that in windows xp computer is 21. Will this be a problem too? Thanks!

[smercurio_fc]

No, there's no different "order sequency" between the two operating systems. I'm not sure why you would think that. The most likely issue based on your description is that you have a subtle race condition in your code (i.e., a program bug), and you happen to see it on one system and not the other. I'm not saying that's precisely what you have, but this behavior is typical of a race condition. Without seeing some code that's about all you're going to get.

EDIT: You posted the code right when I was making the reply. Will try to look at the code.

EDIT 2: Where is the rest of your code? The VI you uploaded has a taskID in, so where is the higher-level VI? Are you running these VIs on their own?

[RobinX]

Hi 

Here are the other sub VIs. the load control 4.0 vi is the main program. The initialize load cell vi is where the task id comes from. I think the problem might be in the initialization. 

[Josh_B1]

Hi RobinX,

I took a quick look at your code and one thing stood out to me. Is there a reason that you are using so many local variables? Local variables are generally not the best programming tool may be contributing to some sort of race condition that smercurio_fc mentioned. 

Regards,

Josh Brown

Applications Engineer

National Instruments

(866) ASK-MYNI

[RobinX]

Thanks for your reply. I am not very clear about the local variables. Do you have any suggestions to fix it? What kind of variables should I use to replace the local variables? I could give a try. 

[Dennis_Knutson]

ideally, you would use 0 local variables and always use wires.

[RobinX]

Josh

Is there anyway that I can keep the local variables but still fix the problems? I guess replacement of the local variables would be a big project and may cause some more unknown problems.

[smercurio_fc]

Frankly, your entire architecture needs to be rewritten, and I don't say this lightly. If you were on my team that's what I'd tell you. Your program is a mess. It appears to have been written by someone who knows text-based programming, and not data-flow programming. It is virtually impossible to follow the code and the litter of local variables makes it an almost near certainty that you probably have a race condition. I've posted your code in the Why some people say Local Variables are bad thread.

[RobinX]

Thank you so much for your advice. But I am not very familiar with labview. This code was programmed long time ago, and there is no way to get in touch with that guy. I am very confused that how come this code works very well on one system but bad on the other. I am sorry about my silly questions, but I kind of hope to make as few changes as possible. Once again, I really appreciate your time, I know reading messy code is a headache.