Thoughts on why this VI is not updating my AC Calibrator?

[Kastun27]

Hello everyone. The attached project controls an AC/DC calibration system for resistive thermal devices. The system applies AC and DC voltages to these devices, measures the output, and compares them over a range of user-entered frequencies (for the AC of course). The project was created some time ago and uses some outdated practices, but it works, all except for one feature that is puzzling me. Here is some background on how it works:

1) User enters amplitude (current or voltage) relative to range of unit-under-test

2) User enters the desired frequencies. Eg. 1kHz, 10kHz, 20kHz, 50kHz

3) User enters N samples, the number of times the measurement will be taken for each frequency

4) One measurement sequence goes: DC+, AC (@ given freq.), then DC-

5) The AC/DC difference is stored, averaged, and standard deviation recorded.

6) The sequence repeats N*(number of discrete frequencies)

The attached .png shows where the issue lies. The ACV is supposed to update at the end of each measurement, i.e. calculate the difference in ppm and subtract that difference from the current ACV, then send that value to the AC Calibrator (via GPIB) for the next N iteration (measurement). But unfortunately...the AC calibrator does not reflect the value (the "Set AC Voltage.vi" does this), even though the control/indicator value for ACV does, in fact, update. 

The AC calibrator I am using (for reference in the case structure) is "Datron 48XX". I have no problems adjusting the amplitude of the AC calibrator "on the fly" if I were to create an individual control VI. I am not sure if this is some sort of initialization or timing problem I am not seeing. The separate VI I have attached, "Simulate Sequence.vi", crudely simulates that step in the program just to make sure I have the logic correct. It works just how I think it should, so maybe this is a fundamental GPIB communication issue I am not aware of. Hopefully someone here has experience with this. Thank you. 

[Mark_Yedinak]

This code is using so many local variables it is screaming race conditions. First, get rid of all of the frame structures and learn about state machines. There are plenty of good examples you can look at. Next, learn how to use dataflow. There is no need to access virtually all of your data using local variables. Use wires to carry your data. My general advice for this would be to throw it out and start over with an actual code architecture. Minimally, start with a simple state machine. Sorry to sound harsh but this code would not be accepted on my team. I would recommend going through the online tutorials.

[Kastun27]

Thank you for your response and I am aware of the issues you speak of. The locals and stacked sequences are quite absurd. I would start over with a state machine architecture if I had the time, but the program works and I've been told to get it running ASAP. Believe it or not (I am quite surprised myself) it works consistently with no problems other than the issue here, even on an old Dell Optiplex with an obsolete GPIB card...so we're going with it. In fact it could be used just the way it is, but then I will have to calculate and add additional correction factors. The program is here to stay. If you have a solution, please advise and it will be much appreciated. 

[Kastun27]

Never mind, I figured it out.

[billko]

---

@Kastun27 wrote:

Never mind, I figured it out.

---

DON'T SELECT YOUR RESPONSE AS THE SOLUTION UNLESS IT ACTUALLY CONTAINS THE SOLUTION!

[Kevin_Price]

Fair warning.  We have some notorious legacy code like that too and have been gradually working to replace it a little at a time.

We've had instances where code that ran perfectly for years on an old PC started revealing inconsistent, race-condition behavior when the PC died and was replaced with a much newer and more capable one.

Just because it's been working perfectly *so far* doesn't necessarily mean that it always will.  (But I do also understand that sometimes incremental band-aids are the only option that gives you a chance at meeting a deadline.)

-Kevin P

[Kastun27]

Don't yell billko. Violence is never the answer.

[Kastun27 · Accepted solution]

[Mark_Yedinak]

And what exactly was the solution? You posted a tiny picture of your code with no explanation or context. And while Kevin's comments are true I would highly recommend trying to convince the powers to be that this code needs a re-write. I recently found a race condition in some of my code that only manifested itself in the optimized exe. It never happened while running in the development environment. Granted, this code is entirely based on asychonous messaging between lots of components, but none the less race conditions are a very real concern especially with the over use of local variables in your code. Slight changes in execution speed and you may find yourself in a real mess.

[Kastun27]

The original post supplies the context. Anyone who was introduced to LabVIEW more than a week ago can see the extremely elementary additional code. All of your concerns are valid; however, this program has been ran 100+ times between the development machine and two stand alone machines via deployed .exe application. The program takes hours to run (depending on the desired iterations) and completes without issue. How long will it last? Based on the statistical evidence...pretty long. But maybe not. Nevertheless, I've done precisely what was asked of me. Case closed.