"Handled message" counter in queued message message handler loop (see screenshot)

[billko]

---

@Mark_Yedinak wrote:

I would also be concerned with many of the outputs on your case statement. Some have the "Use default if unwired" and at least one is changing data type. I would avoid running wires backwards. In your progress bar you are multiply 100 by 0, which will always equal 0. That makes no sense at all. I don't see anywhere were you are actually incrementing your number of processed messages. I would also question how you are getting the total number of messages. If you are getting it every iteration of the loop your total message count will keep decreasing since you are pulling message from the queue as you process them. You also can run into issues if tasks outside your state machine can queue messages. This would allow for additional messages to be queued while you are processing a set of messages.

---

I think you're right about the "Use default if unwired".  It would seem that the only thing I see incrementing has the tunnel set to that, so probably the last state it goes through has it unwired, making the final value "0".  It's very difficult to troubleshoot because there a re wires running all over, behind things, and not lined up with their tunnels.  And since we don't have any code, we can't even do a block diagram cleanup; therefore, I won't be doing any more troubleshooting.

Hint to OP: Clean up the code!  it's for your own good, really.  I'm betting if you had the wires all cleanly laid out, you would've seen the issue a long time ago.

[Mark_Yedinak]

I hope you are using typedefs for your clusters. If not, you should be. If they are UI based you can even use strict typedefs which allow your formatting to be updated as well. Don't rely on the default value in the typedef since that does not automatically get updated when changed. For default values I will often use a simple VI which outputs the cluster. The block diagram is nothing more that setting the cluster to the desired default values. That way if I need to change the default I only need to change it in one place.

[CatDoe]

Hello Mark, 

Thank you for your feedback. Is there a white paper that explains the UI functions? I have read a lot about clusters, but not found anything regarding editing elements post-cluster formation. This is my first time writing a program requiring clusters. All my other programs were simple enough to work without clusters. I have now posted the simplified VI in a later comment.

[CatDoe]

This is as simplified of a VI as I can make. I have attached the two customized error handling VIs as well.

[billko]

What do you mean by "editing"?

[CatDoe]

I need to be able to organize the order of the variables for readability, group some elements into subarrays within a cluster, and ideally add and delete elements as I am building the code. Currently all my variables are grouped in various locations of the block diagram until I finish debugging. Then I will for the arrays, subclusters, etc... and put them all into one macro cluster. 

I would love to have a macro cluster now and work on the individual element level, but I have not found a way to do this without destroying the macro cluster and starting all over. I have over 100 pieces of data to track, so this is not an option.

[billko]

Read Mark's comments on typedefs above.  This is a critical concept to learn - if you haven't learned it already - because you can build your clusters as you see fit, and all instances of the typedef get updated at the same time.  This has the pleasant side effect that you will get broken arrows in all the VIs where LV couldn't figure out how to adapt the modified typedef to the current code.  You can then go to each instance and fix it.  (You'd be surprised at how LV can automatically adapt to a majority of typedef changes.)

I hope this answers your question.

[CatDoe]

Yes, that answers my questions about clusters. I didn't realize there was an edit mode versus customize mode. Back to the original question, do you have any suggestions with regards to the progress bar?

My final option was to update a counter contained in the cluster and queue a message to update the progress bar. However, this seems excessive and very repetitive.