Continuous Looping

[JimSchwendeman]

Hey Everybody!

I've had quite a bit of luck with the devzone in the past, and I'm hoping you might be able to point me in a better direction.

I attached the code that I'm currently working on implementing.  The large loop on the right handles a some counter/timer inputs, as well as a couple of digital output operations that I have to perform at regular intervals.  I have local variables that I'm continuously updating that are passed to this loop. 

The problem that I'm currently running into is:  I have a couple of different operations that need to be able to independantly modify these local variables.  For instance, I have a homing sequence mode, a manual operation mode, and an automated run mode.  The issue is that I cannot continuously update those variables when I click into the manual operation mode tab, for instance.

Any thoughts?

Thanks very much!

.jim

[Ray.R]

From a very quick look at the code, you should execute the contents of the Manual case faster than the homing sequence, which would point to a race condition.

I'm actually surprised that you are not seeing more random results, especuially since you are reading some Local Variables before they get an initial value from the leftmost case structure.   Remember, LV executes code as soon as it can execute parts of the block diagram, not in the order they appear on the diagram.

I'm curious, why do you not wire the Capstan Freq Ind directly from the left protion to the right one?  I'll attach an image (in a few minutes).  Same for the Slide Freq Ind. 

My suggestion is simple:  get rid of all Local Variables, they are not needed at all.

RayR

[Ray.R]

As I mentionned in my previous email, avoid Local Variables.  Wire values directly.  You can make proper use of the Shift Registers (if needed) to update values within the loop.  If you have to update values from outside the loop, try a Functional Global variable, and better still, use Semaphores to avoid collision or to synchronize when valid data is ready to be read or updated.

What is happening at the moment is the vi is reading the contents of the Locals (Capstan Freq Ind & Slide Freq Ind) before they are set from the Case structure to the left.

See image below:

Message Edited by JoeLabView on 10-30-2007 09:21 PM

[Ray.R]

The other "surprises" you may see while executing the code, is that you are getting unrepeatable behavior AFTER running the VI at least once, and running it subsequent times wuithout closing LV.

I'll explain...

You have some uninitialized shift registers.  So when the VI compares the first values for the "Capstan Freq Ind" or "Slide Freq Ind", it is actually comparing the last two values that remained in memory from the last execution of the vi.  Which means it could be TRUE or FALSE that they are not equal.  Now, the very first time you execute the vi after starting up LV, you will get a FALSE because the uninitialized Shift Registers will both contain the default values of 0 (zero), therefore they are equal.

Now back to the Local Variables discussed earlier.  The values in the Shift Registers may actually be set to 50 during the first run(s) because the loop on the right may very well execute before the values from the leftmost Case Structure writes to the Local Variables at its output (for the Homing Sequence Case).

RayR

[JimSchwendeman]

Ray,

I'll work on implementing that tonight, and see how it goes.

Thanks for the suggestions, they are much appreciated!

.jim

[JimSchwendeman]

Ray,

I have a new question.  So I've hardwired the lines, as you suggested, but I'm still getting the same behavior, i.e, the command loop (on the left) runs indefinately but never seems to update the drive loop (on the right).  How can I make it so that the command loop can constantly spit out updated values, while still letting the drive loop run at it's normal pace?

I attached most current .vi for reference.

Thanks!

.jim

[altenbach]

If but loops should run at the same time, you cannot have a data dependency between them.

This is basic dataflow and central to all LabVIEW code.

1. An element or structure cannot start executing until all inputs contain data.
2. The outputs will only produce data once the structure has finished.

In your case, the first loop will start, but the second loop must wait because it depends on outputs from the first loop. Once you stop the first loop, the wire from the stop button is TRUE and immediately enters the second loop, which will stop after one iteration because the stop condition is immediately satisfied.

You should start out with a much smaller mockup of the code logic (that does not include any hardware), then run it in execution highlighting mode to understand how dataflow works. Good luck!

There are also some tutorial that could help.

[Ray.R]

Oops, I must have missed somewhere that you had to run both loops at the same time, in which case a producer / consumer approach may be more adequate.  I had seen the Global Variables at the end of the loop or case to the left, but did not realize that the loop could run continuously.

It may be wise to look at the producer / consumer loop structure.   But first, start with the suggestion from Altenbach.

RayR