LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

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

Background:

-LabVIEW 2021

-Queued Message Handler

-Cannot share code directly due to IP constraints

-Screenshot shows message handling loop

-Array size is the number of messages generated by a user event in the event handling loop (this was the easy part)

 

Problem:

-Cannot determine how to log the number of handled messages. The i in the while loop has an outrageous number and causes my program to stall when run.

-Tried a 0 constant outside all loops with shift registers on the while loop, incrementing inside each message specific case  - counter did not count. I would have thought this would have worked. This slowed down my program significantly, but it did run.

-Last attempt that makes no sense, but was worth a try is shown in the screenshot. This clearly should not have worked and it did not.

 

I am trying to create a progress bar to show how many messages have been "handled" in comparison to the total number of messages. How can I create a counter to track the number of handled messages? OR how else can I create a progress bar.

 

 

CatDoe_0-1660159259616.png

 

0 Kudos
Message 1 of 18
(3,438 Views)

Hello, Some thoughts 

 

- you might need a shift register to keep track of the handled message and only update the count when you handle one

- you should only run the case when you dequeue a valid message not each time in the loop. I think the dequeue VI has either a timeout or you can set it to wait for a message. 

- kind of hard to tell what is going on from the pic, part of the VI is cut off. 

______________________________________________________________
Have a pleasant day and be sure to learn Python for success and prosperity.
0 Kudos
Message 2 of 18
(3,433 Views)

Jay,

 

 

- As I said in the message, shift registers did not count correctly -- my counter remained a steady 0.

- Yes, I need to only count when I dequeue a message. I attempted to do this and no method I came up with worked.

- All the relevant information for the question is included in the screenshot. IP sensitive information was moved out of sight.

 

Do you have a more specific recommendation?

0 Kudos
Message 3 of 18
(3,429 Views)

@CatDoe wrote:

Jay,

 

 

- As I said in the message, shift registers did not count correctly -- my counter remained a steady 0.

- Yes, I need to only count when I dequeue a message. I attempted to do this and no method I came up with worked.

- All the relevant information for the question is included in the screenshot. IP sensitive information was moved out of sight.

 

Do you have a more specific recommendation?


Well looking at the picture all I can do is agree that it will not work the way it is shown. The shift register needs to be connected to the loop. 

______________________________________________________________
Have a pleasant day and be sure to learn Python for success and prosperity.
0 Kudos
Message 4 of 18
(3,418 Views)

Putting the increment inside the individual messages already accounts for the need to check for dequeuing a valid message. Theoretically the shift register should work here from my previous understanding of while loops, but it does not.

CatDoe_0-1660163540527.png

I also tried varying the location for the progress bar. With all initial constant configurations.

CatDoe_3-1660163935756.png

 

CatDoe_4-1660163956699.png

 

 

 

In this case, i gave an arbitrarily large number and did not count properly when checked by hand. It seems to count with a computer integrated clock rather than any relation to messages.

CatDoe_1-1660163642173.png

 

 

I also thought to use a feedback node, however I could never get a feedback node to work in any combination of including or excluding loops.

0 Kudos
Message 5 of 18
(3,401 Views)

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.



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
0 Kudos
Message 6 of 18
(3,399 Views)

Hello Mark,

 

The 0 is a place holder for the size of they array -- yes, when this constant is 0 the progress bar will not work. In my actual trials this was wired to my size array, sizing my string array. I cannot show that link due to IP restrictions hence the comment notation next to the constant.

 

The code is in progress and variables are placed in groups to cluster at a later time. This code is in the middle of development and has not been organized into the final left to right formation, clusters, etc...

 

My message count is taken from my initial string array which is sent to the queue message VI. This count is not dynamic, it is static - this count is not the issue. Nothing outside of my event handling loop and my message handler can queue messages.

 

I am looking to count the number of dequeued messages -- i.e. the messages dequeued and handled by the message handler case structure.

 

Also, I do not see any of my wires changing data type in these screenshots-- can you please point them out to me?

0 Kudos
Message 7 of 18
(3,393 Views)

I understand that you cannot post the Vi due to IP but you can create a very simple test vi which you can post which will just include the basics of what you want to do with your progress bar. It is impossible to adequately debug pictures.

 

In terms of the code is a "work in progress" which is why it is messy is not a great answer for why it is messy. Get in the habit of creating the code as clean as possible from the start. The code will always be more readable. You will not fall into the trap of not going back to clean it up because of schedule constraints. It is very easy to say you will do cleanup in the future and then never actually do it.



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
0 Kudos
Message 8 of 18
(3,384 Views)

I will spend tomorrow morning building a simple VI and post it here. I ran out of time to build one today.

 

I agree, clean code from the start is the ultimate goal. How can you edit clusters after they are created? I have not been able to edit the individual elements of a cluster (i.e. add, reorganize, delete) after it is created. I need to organize over 100 variables into sections, subclusters, subarrays etc... If I knew how to edit a cluster, my code would be very clean.

0 Kudos
Message 9 of 18
(3,382 Views)

Most of the issues look like they are caused by not having the loop terminal connected correctly. The shift registers need to be connected on both sides of the loop or they do nothing. 

 

I would be worried about any case statements that have the use default if unwired indicator on the output wire, if one of those cases runs and it is connected to a shift register you will set the register to the default which may not be what you want. 

 

The other issue looks like the code is outside the loop. That code will only run when the loop exits and it is hard to tell what the loop exit logic is. 

______________________________________________________________
Have a pleasant day and be sure to learn Python for success and prosperity.
0 Kudos
Message 10 of 18
(3,380 Views)