DQMH woes

[drjdpowell]

---

@Olivier-JOURDAN wrote:

---

---

Not sure that arranging dependencies would be something easy or at least possible to do. I'm also wondering how it would behave on a larger diagram like the following one. 

---

One one knows what depends on what, it should be easy to come up with a ranking where a module out ranks everything that it depends on (excepting circular dependencies).

BTW, I think you forgot to attach your "larger diagram".

[Olivier-JOURDAN]

Here is the "larger" diagram 

[drjdpowell]

---

@Olivier-JOURDAN wrote:

---

---

Not sure that arranging dependencies would be something easy or at least possible to do. I'm also wondering how it would behave on a larger diagram like the following one. 

---

---

You could embed Graphviz to do the plotting.  It organizes things this way.

[Olivier-JOURDAN]

---

@Taggart  a écrit :

---

@Olivier-JOURDAN wrote:

Note that after displaying the general overview of module links, the documentation generated with Antidoc lists all modules with a diagram representing links between the module and the rest of the code. Examining that specific diagram should allow detecting circular dependencies.

One question could be, "should Antidoc detect those circular dependencies and generate a kind of architecture analysis report"? I don't know if it would be an interesting feature and how proprietary it would be compared to other features like supporting other public frameworks...
Open question...

---

To your first point, the smaller diagrams that just show an individual module and all its direct dependencies are useful, and would catch some, but not all circular dependencies. If you look at the original diagram here it has some large circular dependencies ie. A depends on B which depends on C which depends on D which depends on A. The smaller more targetted diagram probably wouldn't catch that.

To your second point, I think it could be very useful to alert users to circular dependencies. Although part of me says that someone who couldn't figure out that there are circular dependencies from the diagram probably isn't going to know why a circular dependency is bad or what to do to fix it. In that case, is it useful to point it out to them? I guess having the information is better than not having it. If you knew enough to be able to identify the circular dependency but just missed it, then it might be useful. I think I'm pretty good at picking them out but occasionally I miss something.

This might all just be me projecting because I find it rather trivial to look at one of those diagrams and find the circular dependencies. Maybe it's some skill I've built up over time that not everyone has.

---

It could be a secondary tool or an option in Antidoc to generate a kind of analysis report for those who want it.

[Olivier-JOURDAN]

---

@drjdpowell  a écrit :

---

@Olivier-JOURDAN wrote:

---

---

Not sure that arranging dependencies would be something easy or at least possible to do. I'm also wondering how it would behave on a larger diagram like the following one. 

---

---

You could embed Graphviz to do the plotting.  It organizes things this way.

---

IAntidoc relies on another open-source project to generate the Grapviz string. I need to see if it allows this kind of arrangement. Anyway thanks for pointing to this solution 👍 

[Taggart]

I take back what I said about it being easy to spot circular dependencies. Although I did spot 2 in there rather quickly.  

[Taggart]

---

@Olivier-JOURDAN wrote:

---

It could be a secondary tool or an option in Antidoc to generate a kind of analysis report for those who want it.

---

I think there is certainly a use case.

[ChrisFarmerWIS]

---

I prefer to see my diagrams look like this with the "parents" at the top, and "children" below it.  This seems to make more sense to me than going horizontal.

[LVUser94]

I have an update regarding the original issues in the data file that I was trying to solve. Quick refresher: the issues I found in the data file were a) old data repeated hours later b) new data counted more than once.

On advice from this group, I put an Activity Tracker in the Data Logging DQMH module. This logged every event  that was sent by other DQMH modules (events can be data or other non-data information such as status). I made this a daily file so as to make the file a manageable size.

I also created and installed a second data logger module. I left the original data logger module as is. This is a simple LabVIEW state machine type VI, but still relies on data sent via events from other DQMH modules since there was no other way to get the data. So both old and new data logger modules are logging data independently to separate files.

Good news is I found no issues in the DQMH events Activity Log file. There was no duplication of events or repetition of old events. From a quick look, the time ordering of events seems to be ok (i.e., events arrive in the same order they were created) although this needs further scrutiny as the events were coming in at a rate of 33 per second (total of ~ 2.85 million events were logged per day). I could not really discern  timing differences less than 0.1s. But that is good enough for this application.

But the old data continues to show the same issues - random duplication of old data, double counting of new data. But the new data file does not have these issues. It shows only data found in the Activity Log file, and the final counts tally nicely.

So I can say that DQMH has been exonerated. 

I am still perplexed by the old data logger...but I am going to replace that with the new data logger as I am running out of time to investigate. So I will never know what the bug was.

Thanks every one for helping with this.

[drjdpowell]

Just for interest, I messed around with Graphviz, doing one of my Messenger Library projects.