Compatibility of windows xp with labview and windows 2000 with labview

[Josh_B1]

Hi RobinX,

Honestly the best solution would be to start from scratch. As smercurio_fc mentioned there are two many issues with this code for it to be salvaged. Since you are new to LabVIEW I would suggest taking a look at some of the online tutorials National Instruments provides. You could start by going trough the LabVIEW basics which I have link to below.

http://www.ni.com/gettingstarted/labviewbasics/

Regards,

Josh Brown

[smercurio_fc]

---

@RobinX wrote:

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. 

---

Well, I can sympathize with your situation, as inheriting crappy code is not fun. I don't think this will make you feel better, but at one of my early jobs I was tasked with modifying some VB code to add some printing capabilities. The programmer used the names of animals as variable names. I am not kidding. Try to debug that one.

As for your code: I can already see at least one race condition by just looking at the code. Caused by? The local variables, of course. This has to do with the LC Calibration Cluster, where you save/load the data. See screenshot:

You don't know which one is going to write to the local variable first  -- > race condition. This is probably not the only one.

[RobinX]

Thank you very much for your adive Josh. But it is really unpractical and time consuming for us to start from the scratch. Now every parts of the device works great only this minor problem. Is there by any chance other simpler way to fix it? 

[smercurio_fc]

Yes. Find the race conditions and fix them. How? Use data dependency to make sure some part of code runs before another, or if you cannot use data dependency, then use sequence frames. Other than that, there's not much else you can do.

It's not simpler, and it's not a fix. It's at best, a band-aid on something that is likely to fall apart under its own weight sooner than later. 

[JÞB]

---

@RobinX wrote:

Thank you very much for your adive Josh. But it is really unpractical and time consuming for us to start from the scratch. Now every parts of the device works great only this minor problem. Is there by any chance other simpler way to fix it? 

---

---

I heartilly agree with the rest of the posters (Thats some pretty poor code!) One way to debug race contioions, is no FAST way, is to replace all the local reads and writes with LV2 style Globals.  This does not enforce data dependancy and the race conditions will still exist BUT, you can use breakpoints to see where the FGV is being called from and what the data value is as it is called.  Add Error In and Error Out terminals too and you can add data dependancy as you discover the race conditions.

As far as why it is more noticible on XP than 2000:  I bet the XP machine has multiple cores and the 2000 does not adding a large number of threads to the execution mean just that many more potential chances to process the non-data-dependant code clumps in just the wrong order.

- If we had a horror of the week award You be in the running!  good luck