problem with dequeue, preview works okay

[marv_mcd]

Hi there,

I am trying to use the Queued State Machine - Producer Consumer design in LabView 8.2.  It is overkill for my application but I'm using it deliberately as a learning tool...

As you can see in the image attached, the subvi tries to initialise the serial port/device.  At the moment it's not connected so it generates an error.  The queue manager correctly adds the ERROR state to the front of the queue.  I dropped in a preview queue block and I see that it is there at the front of the queue.
On the next loop iteration, I expect the dequeue element block to dequeue the state ERROR off the queue.  However it doesn't, it removes a dummy state called 'startup'.  This is the default state of the state machine.
If I drop a preview queue block into the vi at the same point as the dequeue element, it correctly shows that the ERROR state.  I can preview the correct element, but not actually dequeue it.  I therefore of course never go to the ERROR state.

I hope this makes sense, please can anybody offer any advice?  It would be very much appreciated.

Best regards,


Martin

[marv_mcd]

I have fixed this problem.  The issue was with feeding the error line through the dequeue block. If I disconnect the error line it works okay.

[Norbert_B]

Marv,

i am sorry to say that: Your "fix" is a workaround, and it is a bad workaround. You should never just disable error handling if you are running into problems caused by previous errors!
Since the screenshot only shows a small part of your VI, i cannot tell you where the real issue might occur, but you should definetly rethink the error-handling strategie.

hope this helps,
Norbert

[MikeS81]

Hi Martin,

i agree with Norbert. You will get the next shock, if you run your vi on a system where automatic error handling is activated. Can you explain where you get the error and maybe upload your vi? Why do you have the 500ms wait in this loop? Your loop will only run if there is an element in the queue because the default timeout is -1.

Mike

[smercurio_fc]

---

@Norbert B wrote:
Marv,

i am sorry to say that: Your "fix" is a workaround, and it is a bad workaround. You should never just disable error handling if you are running into problems caused by previous errors!

---

This reminds me of what happened when I left my first job due to voluntary layoff (partly because I didn't want to work for the new management). I had been in the middle of writing a new version of test code and was implementing customized error handling functions. Well, they weren't done, and were bound to have bugs. A lot of this was part of an effort to verify that the instrumentation was programmed to the value requested. The fellow who took over for me wasn't that good of a LabVIEW programmer, so he was getting all sorts of errors being generated, mostly because of the bugs in the error handling functions. This new manager's solution? Disable all the error handling functions. I was so glad I had chosen voluntary layoff rather than work under that manager.

[marv_mcd]

Hi All,
-Thank you for you input, it is much appreciated. 
-My code is based on this: http://expressionflow.com/2007/10/01/labview-queued-state-machine-architecture/ 
-In the example above the error line on the dequeue element is not connected.
-The delay time was just to slow things down for debug purposes.
- I don't intend to disable error handling, my 2nd post was to show that I'd found something that made a difference, the next step being to understand what is going on.  As I said, this is a learning exercise 🙂

Best regards,


Martin

[ShotSimon]

smercurio,

I realize this is off the thread but you made me think!

This seems to be a trend in management 🙂  I started using a simple alternate solution that allows for errors. 
Instead of disabling error handling (and assuming the error is only happening periodically) put in a retry and track the number of retry attempts that are required.

Instead of reporting no error, which can be expensive say a product gets out to a customers in large volume, it's just a matter of working on reducing the number of retries until the retries are eliminated all together.

-SS

[Norbert_B]

Martin,

the link you provide here seems very elaborate on the matter and covers quite many features. But without reading it, i am wondering why the dequeue is not connected with the error handler. I would think that the originator ran inot the same issue like you did and decided to drop this dequeue out of error handling. This is not correct in regard of proper (stable) programming, but might be suitable for a whitepaper like this.

For the application itself, i'd suggest you to observe the errors very closely and decide how to react on them. The originator of the whitepaper already gave one example for a possible error, but there could be more.

hope this helps,
Norbert

PS: Please don't pass wires behind structures!