Functional Global Variable on Hold

[Ben]

Something is being missed here.

Could you post a zip of all of your code so someone can take a look?

I can not promise I can review it (doing code reviews for free really yanks my bosses chain) but others may be able to spot waht is getting missed.

SO either something is being missed or 12 years of LV thoughts have to be reevaluated.

Ben

[richjoh]

---

Edmi0 wrote: 

The source is running and generating the points of the waveform (it is a waveform but I only process one point at a time, therefore shouldn't exist the problem with the big data structure) but the VI timeout continuously when the expected would be to catch the rising edge.  

---

Although your AE output is 1 number, its likely your AE is processing the entire waveform and taking considerable amount of time. I would think you need to move the AE outside the loop if feasible since your 5 or more reentrant loops process 1 number or so. As you know, allocating memory for a waveform is time consuming.

[Edmi0]

Here it goes

[Edmi0]

More updates:

Since I'm running out of ideas, tried what was left to try.

First, used just one call to the AE, updated a control and passed the reference of this control to the subvi. It worked untill some degree, it is probably a slow method though and didn't meet my time requirements. Same thing for global variables, the program is not able to run properly.

I'm praying that I made an absurd mistake in the code (likely, because I can't believe this is an error never found before)

[johnsold · Accepted solution]

I do not see any Waits or other delays in any of the loops.  You could be seeing greedy loops rather than some strange FGV effect.  Even a zero ms wait will cause the scheduler to release the CPU to another loop. In addition to the Wait shown below, a Wait in the False case of the outer loop is appropriate. It could be tens of milliseconds or more since it controls polling of user input.

Lynn

[Edmi0]

Greedy Loop it was! After the insertion of the Wait(ms) with 0 connected to ir, the program simply started to work.

Thank you so much, would've never figured that out!

Edit: On a side question, would you guys think it is worth to turn this loop (with the machine state) into a subvi or would that just make things more complicated?

[johnsold]

Greedy loops are well known to experienced users, but are one of those subtle things which are easily missed whiel you are learning.

Side question: Yes and no.  Because you do exactly the same thing multiple times, making a subVI avoids problems of maintaining the code - you only have to change things once.  On the other hand you cannot use the stop local variables to stop the subVIs.  You also cannot directly make the "stopEquip n" buttons readily available to the user (subpanels may be a possibilty).

It would probably be a good idea from the code reuse and maintenance perspectives.  It will require some re-architecting of the program to make it work.  If you ever might want to add a sixth set of equipment, then subVIs become even more attractive.  I would look into a Producer/Consumer (Events) architecture with the buttons all handled by one event structure in the Producer and the Consumer would have something like an array of cluster of data in a shift register for the Equip data with one state machine handling all the Equip(s) at the same time.

Converting to this would not be a trivial task, but might be worthwhile if the requirements change very often or very much.

Lynn

[Edmi0]

Thank you for the tip.

I'll see what I can do about this structure, but it defintely has to be changed. Repeated code gives me an awkward feeling

About the

---

Consumer would have something like an array of cluster of data in a shift register for the Equip data with one state machine handling all the Equip(s) at the same time.

---

I'm not sure I understood the "one state machine handling all the Equip(s) at the same time". Does that mean that the event structure would queue the "startEquip x" event and then start then, one by one, running then? So I would have to maintain the while loop inside the subvi so it doesn't result in a sequencial function as opposed to the parallel expected, correct?

What if I turned only the machine state into a subvi? That would already simplify thing and help code maintenance, right? (Naturally it results in a subvi with ten tons inputs and outputs, i guess)

[Edmi0]

Just another question. Guess I hit a wall regarding performance.

With 5 loops the "wait(ms)" idea provides the ideal result. However, for 6 or more, the loops kinda starve and don't work properly... any idea on how could I fix that? Guess I still have the greedy loops issue.

I thought of queues or something related, but I guess it really has to be parallel to guarantee the specification =/