LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Dequeue in executable with runtime-engine 2014 doesn't work

Solved!
Go to solution

Hey,

 

I'm using LabVIEW 2014 SP1. In the labview development environment my VI works great and without problems.

If I make an executable it works also fine. If I try the executable on a pc with runtime-engine 2014, then the dequeue structure doesn't works. The exe doesn't enter the case-state "set zero", if i click "Button_4_Zero". In LabVIEW Devel.Env. it enter the case! Some ideas?

 

PC1: Windows 10, 32bit, LabVIEW 14.0.1 Professional Development System, SP1

PC2: Windows 10, 32bit, LabVIEW 2014 (32bit) Run-Time Engine for Windows, release date: 09-08-2014

 

queue-example.JPG

 

Thanks! Best wishes.

 

0 Kudos
Message 1 of 8
(3,752 Views)

There are some issues/questions with your 'code' (in fact: screenshot of a part of your code!):

1. Why do you enqueue "Set Zero" in opposite end?

2. Having the button terminal OUTSIDE of the appropriate event case can lead to issues (review caveats of event structure)

3. Why do you enqueue something in the consumer, but flush the queue after the case structure? This makes NO SENSE!

4. How do you identify that the event is not executed and the queue not reacting? I don't see code to prove this

5. NEVER write code which cannot be terminated properly for Windows/Linux/Mac targets. This is only OK for Real Time and FPGA!

6. Consider to remove wait/wait until functions as you want to work event-based. Using Wait functions outside of very specific cases seems like Rube Goldberg code.

7. Remove unnecessary code (e.g. boolean case with constant connected to selector) as it makes the code more complex to read and potentially affects compilation in a bad manner

8. Consider moving "Read Config" into the Start Case as this executes first and always once the program starts executing

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
Message 2 of 8
(3,735 Views)

In your consumer loop, you begin with 'Start Case'.  Not sure what you do within that case, but next the queue may return empty, are you handling the timeout condition from the dequeue?  If you were to use the 'Get Queue Status' first and check that '# elements in queue' > 0 before dequeuing an element.  Place your Dequeue Element and case within another case that verifies at least a single element is in the queue.

 

Norbert is correct.  Especially the flushing of the queue after responding to one item in the queue within the consumer loop.  I just overlooked that as I did not expect to see that.

Help the Community (and future reviewers) by marking posts as follows:
If it helped - KUDOS
If it answers the issue - SOLUTION
0 Kudos
Message 3 of 8
(3,729 Views)
Solution
Accepted by topic author E.R.

Hello,

 

I don't know what 'Read Config' does, but if 'Read Config' throws an error (e.g. file not found) what does your consumer loop do?

Is there any error handling in this case?

 

UliB

Message 4 of 8
(3,708 Views)

Do you flush your queue at the end of the consumer? That's the reason.

/Y

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 5 of 8
(3,681 Views)

Hey,

thanks for the suggestions! Now it also works as executable.

The Problem was: If I got an error in my "start case" (like wrong COM-Port) and I enqueue an element/state in the "start case", then the number of elements of the queue was zero at the beginning of a new loop.

 

I changed the following things:
1) Insert "read config" in the start case

2) flush queue after dequeue > Reason: to make sure that my queue is not growing.

3) Change error state to false at the end. (I know its not perfect, but for this project I have no time to handling errors. If its works, then its enough)

4) producer loop: enqueue elements at opposite end > Reason: make sure that this commands are priority

 

solution.JPG

 

So thanks.

Best wishes!

0 Kudos
Message 6 of 8
(3,642 Views)

@E.R. wrote:

Hey,

[...]

2) flush queue after dequeue > Reason: to make sure that my queue is not growing.

3) Change error state to false at the end. (I know its not perfect, but for this project I have no time to handling errors. If its works, then its enough)

4) producer loop: enqueue elements at opposite end > Reason: make sure that this commands are priority

[...]


All these points together manifest bad software design. This is not how to develop software.

 

Why is that?

2) Flushing the queue each iteration of the consumer totally obliterates the purpose of a producer/consumer design. Choosing a design and then destroying it is not a good practice and might come back to you very angry in the future. If a producer/consumer ever runs into an overflow of the queue, it is only the proof of bad implementation or incorrectly understood requirements. If that is really a concern for you, use a notifier instead of a queue.

3) Deleting error information on every error is an absolute no-go for any software. This behavior already lead to the situation where you had to spend time and effort to escalate this here. You potentially repeat exactly that situation later on.... Please take the time to add an "error transition" and a generic error state which at least pops up the error information.

4) Priority enqueue is a valid approach. However, it is a no-go when discarding the remaining queue elements by flushing the queue.

 

Still, your consumer loop will never terminate leaving the application as zombie in your system. This is also a no-go.

 

Please help yourself from stumbling from issue to issue by implementing constructive feedback from experienced forums user.

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
Message 7 of 8
(3,635 Views)

ER,

For future reference: the individual that offered the information that gave you the solution should be marked as the Solution while all of the other inputs that helped improve your code get marked with Kudos.  It is generally poor to mark yourself as the solution when you used inputs from everyone else to arrive at the solution unless you were to arrive at the solution on your own.

Help the Community (and future reviewers) by marking posts as follows:
If it helped - KUDOS
If it answers the issue - SOLUTION
0 Kudos
Message 8 of 8
(3,617 Views)