LabVIEW
Synchronous Messaging with User Events
Solved!
@Ben wrote:
unless there is some clear documentation. Imagine 15 or more parallel loops all talking on the same bus....
So if you use that approach and there is slight chance that Ben may be looking at the code, please document the intended connection and spare me the gray grey hair.
Ben
That is why I wrote/added a logger debugger. It outputs to file that looks like this
Time VI Command
0.000098 Main.vi_Ind Macro: Initialize
0.000107 Main.vi Macro: Initialize
0.000124 Main.vi_Ind Data: Initialize
0.000134 Main.vi_Ind Idle
0.000201 InstrumentLoop.vi Idle
0.000206 DataLoop.vi Idle
0.000332 UILoop.vi Idle
0.109935 Main.vi Data: Initialize
....
mcduff
Here is snap shot of my template. Each process is independent, but all connected to each. That way you can message anywhere and anytime to anyplace.
mcduff
@mcduff wrote:
Here is snap shot of my template. Each process is independent, but all connected to each. That way you can message anywhere and anytime to anyplace.
mcduff
While the logger looks to be helpful when debugging a running system, does it help when reviewing the code?
I would love to see a chart in the diagrams that indicates for each type of message (enum value) what is the source(s) and destination(s).
I am coming off of two project that I did at the end of last year. IN one case I was working to rewrite code that had used that approach but had become too complicated for my customers to follow and was a pain to enhance. I re-used one of the loops and tossed the rest.
The other one was again too complicated for the customer to support and they are asking for fixed price quote to rewrite it.
Now if the developers had included crass-matrix... I may not have been able to earn that money.
Ben
While the logger looks to be helpful when debugging a running system, does it help when reviewing the code?
Yes. When having multiple loops talking to each other, it is good to see when the message was sent, and when it was processed. It also helped when I was repeating states that was not needed. The logger includes the Main/SubVI processing loop that contains the JKI SM. All States and transitions are recorded. I use the high precision relative seconds to record time differences since the millisecond counter does not have the precision, that is, a lot states look like they executed at the same time. However, I added the Event logger to my debugger in order to record FP Events and User Events. Unfortunately, the Event Logger use the millisecond timer and my states are not always in order due to the loss of precision. My logger uses a named queue to log the states, queues are perfect for many to one.
I would love to see a chart in the diagrams that indicates for each type of message (enum value) what is the source(s) and destination(s).
My programs are usually small to mid-sized, 100s of VIs. I usually have simple loop names like InstrumentLoop, DataLoop, UILoop, WatchdogLoop, GPSLoop, etc. So my enum basically matches the loop name, ie, Instrument, Data, etc, along with an Exit enum, that specifically starts the stop procedure.
One key when doing this type of messaging is making sure all the loops and User Event Structures are up and running before sending any messages to them. (I found this bug in my program with the logger.) If they are not running, the message is lost. This is where the forums are extremely helpful. I modified a VI by Brian Hoover that gives a list of all of the VIs running Event loops. Before sending any messages, I check the names of the VIs with the Event loops to be sure that they are running.
This is what it looks like. And yes, it has a sequence structure. 😉
mcduff
