05-10-2009 12:04 AM
Hi
I created a data acquisition program using LabVIEW 6 which basically interacted with PC sound card and acquired data from microphone. I developed it using a Pentium 4 Windows XP machine, and it worked as expected. Moreover, the program wrote the processed data into a binary file. The program was used successfully in a number of places.
Now, we encountered a new scenario. We gave the program to a new set of users who had installed new machines which were either Dual Core or Core 2 Duo machines. The program still runs fine. However, we find that the data file it generates is in a format that's different from what it should be. This is really strange, and we're not able to figure out what is the problem here.
I suppose this may have to do something with a multicore environment. Pls suggest. Has anyone encountered such a scenario?
Thanks
Sunny
05-10-2009 09:47 AM
I doubt it has to do with a multicore environment. Is it the same operating system? What is different about the format? That will usually clue you in on what the problem is likely to be. Clearly you can see it's different, but in what way?
Is this the same as this other question you posted?
05-10-2009 02:36 PM
sunnymax2002 wrote:Hi
I created a data acquisition program using LabVIEW 6 which basically interacted with PC sound card and acquired data from microphone. I developed it using a Pentium 4 Windows XP machine, and it worked as expected. Moreover, the program wrote the processed data into a binary file. The program was used successfully in a number of places.
Now, we encountered a new scenario. We gave the program to a new set of users who had installed new machines which were either Dual Core or Core 2 Duo machines. The program still runs fine. However, we find that the data file it generates is in a format that's different from what it should be. This is really strange, and we're not able to figure out what is the problem here.
I suppose this may have to do something with a multicore environment. Pls suggest. Has anyone encountered such a scenario?
Thanks
Sunny
You may have a race condition in your software. LabVIEW diagrams are dataflow driven. This means code is executable as soon as all inputs are available. If you write to data files without forcing a strict dataflow in the write functions the order of the writes is random. This may for some reasons work on a single core machine by sheer luck. But once it executes on a multi core machine LabVIEW can and will schedule code sequences that have no data flow dependency on different cores so that they can run in real parallel execution. Then your file write functions might get messed up very easily if you have not a strict serialized execution that you can easily achieve by using dataflow.
Rolf Kalbermatter
05-11-2009 08:31 AM
Also be aware that LabVIEW 6.0 does not really take advantage of multi-core or hyperthreaded processors (it uses an internal scheduling mechanism). LabVIEW 7.0 introduced an upgraded threading system to work properly with operating system threads. It has been tweaked multiple times since.
One last point - make sure you have installed the 6.0.2 update. Note that 6.0.x is not officially supported under any OS newer than Windows 2000. You may want to consider an upgrade, if you can.
05-11-2009 08:38 AM
There was a bug ....
Back in the late days of LV 6 something there was a very nasty bug that would manifest itself as file references getting mixed up resulting in files of one format being appended to files of another type. It would only show up when closing a bunch of files and re-opening another set at the same time.
So if you are opening a closing a bunch of files at the same time then an upgrade can help.
Otherwise ignore this post.
Ben