works in debub/highlight mode but fails in real run

[Jpdas06]

Hi

The attached code works fine when I am using debug/highlight mode (light bulb). However, in actual run, it fails to restart the for loop. As you can see, I am scanning between 'StartField' to 'EndField' and the number of steps is decided by the value of 'Increment'. I am expecting that the for loop works for that many steps and when the while loop runs on completion of for loop the value of 'Current Field' gets reset. In highlight mode this works but in actual run, my Current Field values goes beyond the 'EndField', It seems that the for loop does not stop. What am I doing wrong here?

[JÞB]

lets try a snippet instead

From the BD Ctrl+A then Menu>>Edit>>Create snippet from vi selection

Save the darn snippet

Hit that camera looking icon in the post editor and upload the snippet

[Norbert_B]

You have NOT attached any code. You attached a picture of code. That is a HUGE difference.

Looking on the code, you have a lot of issues:

1. Overuse of property nodes. You obviously know about shift register. Use those.

2. Incorrect usage of loop/event structure. The event structure has to be INSIDE the while loop, not the other way round.

3. Race Conditions. At least "Current Value" is a classic race condition as you do not know when writing a value takes place outside the for loop compared to reading it inside the for loop iteration 0.

4. If your description is correct, once the for loop finished the first time, the computation of "Steps per cycle" has to equal to (or be less than) 0. As you haven't attach actual code, we cannot verify this. It does seem incorrect, however without seeing all code, you could easily write incorrect values in non-displayed segments of code of that picture of code.

Please do also try to improve your style. For instance, your subVIs are hard to identify (e.g. Read from Dvm) which is very bad.

[aputman]

Your while loop is going to keep running until you click the stop button, which means the for loop is going to start over.  How do you expect to click that stop button exactly at the right moment when the for loop finishes execution?  And most likely, the front panel is locked out until this event finishes, but it will never finish because you can't click the stop button.  Seems problematic to me.

[altenbach]

A few more comments:

• Prepending to an array from the front is significantly more expensive than appending to the end. Does the sort order really matter?
• Why do you keep all these duplicate datasets? The three arrays (2x DBL, 2x points), duplicate a lot of information. Done right, a single 2D complex array would be sufficient to carry the xy graph data.
• If the event is configured with default settings, the stop button cannot be pressed because the event locks the front panel.
• Where are all the terminals?
• You can use a single property nodes for the two x-scale properties.
• Unless the while loop stops quickly, you'll run out of memory eventually.
• ...
• ...

[Jpdas06]

What is being done: This is done for a mass spectrometer where a magnetic field is being set in incrementing steps from startfield to endfield. At currentfield value, a reading being made from a detector. In normal case, the scan needs to be iterative, keep on running until stopped.

In reply to a post from Norbert:

1. I agree, I will try to reduce the user of property nodes.

2. I also agree that loop/event structure should be other way around. However, what I want is repeating scan between 'StartField' and 'EndField' with increment steps. I had to introduce event structure because I want a feature that when a user changes values of 'StartField' 'EndField' and 'Increment', the scan should reset and start all over again (however changes on FP by a user will not be frequent).

3. Why is the race condition for current value? Current value keeps on going from 'StartField' to 'EndField' in for loop, once the For loop is over, it is reset to startfield. I am assuming that while loop will wait for for loop to complete, right?

4. The other part of the code is collecting values of 'StartField', 'EndField' and 'Increment' through user inputs kept in sequence structures. Proper criteria has been set so that startfield is always less than endfield, therefore the concern regarding steps per cycle being less than zero is irrelevant. 

This code is a tiny section of highly complicated mass spectrometer software, and subVIs are being well documented, may be its very bad in look, I would be happy to learn what else i can put in that tiny icon and improve my style.

 To aputman:

As i said in above reply, i think that while loop will go for next run when it finishes the for loop inside. I am not going to stop the while loop exactly when the for loop finishes, rather i want the 'Current Field' value reset on completion of for loop and before restarting the for loop.

To altenbach:

I will see what can i do about the array arrangements and reduce the expense on memory.

Event is NOT configured with default setting, I can click the stop button as FP is not locked.

Thanks for all your inputs on 'Picture of code' however, there is little that leads to a solution for the problem that why highlight mode works and not the real run.

[Ben]

---

@Jpdas06 wrote:

...however, there is little that leads to a solution for the problem that why highlight mode works and not the real run.

---

When in execution highlighting mode the diagram is executed as a single thread. Race conditions are avoided when running as a single thread.

Fix the race conditions as a first step.

If you do not believe me, wait for Jeff to reply to see what he thinks.

Ben

[JÞB]

---

@Jpdas06 wrote:

Thanks for all your inputs on 'Picture of code' however, there is little that leads to a solution for the problem that why highlight mode works and not the real run.

---

Yup, that is why we want more than a picture (Like a snippet! Argh!)

Highlight execution forces the code to run in a single thread.  This hides a lot of potential race conditions and many of them may be caused by code hidden in other event cases.  A snippet, OTOH, embeds all of the source in a single *.png file that we can "Poof" into existence and inspect.

[altenbach]

---

Jpdas06 wrote:

Thanks for all your inputs on 'Picture of code' however, there is little that leads to a solution for the problem that why highlight mode works and not the real run.

---

It "works" in both modes, but execution highlighting may expose other bugs..

For example writing to the first current field property occurs in parallel to the start of the FOR loop, so the first read of that value property could return a stale value.

Your loops don't start over if some of the settings change, so I don't see your point above.

What is the typical loop rate?

[Jpdas06]

here is the snippet, the property nodes didn't came with their names.