Hi Joerg.hampel
Sorry for the delay in replying to your questions. I will try to answer some of them
first of all I'm sorry for your struggles with the software you inherited. I'd also be interested to hear why would not have gone with DQMH. It seems like a good fit from what you've described here so far?
I am an old timer, and I have developed actively in LabVIEW since version 2.0. I am also a certified LabVIEW Developer since NI first started certifications in early 2000s. So I love LabVIEW and love creating software with it. I am also somewhat set in my ways and have certain opinions on what constitutes good programming. It needs to be simple, elegant, and some what to the point. Fancy architectures are fine but if they just overwhelm the project then they are just getting in the way. Case in point, this project I have inherited is no more complex than many projects I have done in the past. Some have been more complex such as 16 station engine test stand with independent and parallel long term testing of small engines. Yet this project contains over 2000 VIs, has no clear architecture and just a huge mess to maintain. It takes a full minute to get going on launch and another minute to stop. Some times parts of it won't stop and I have to kill LabVIEW and restart even though I can't see what is running. It is not that I am new to Queued Message Handling or Dynamic Events. I have used these many times before but on a limited need only basis. So it frustrates me to see this much code to do something that can be done more efficiently by a fraction of the code. I don't want to turn this into a rant against DQMH, but I have seen enough of it to decide I don't want to use it.
Without the actual source code, or a complete description of your application (at least a back-of-the-napkin sketch of which modules there are, and how they communicate), it is hard for us to be of much help. The only thing we can claim is what drjdpowell already stated: It's highly unlikely that the problems you're facing are rooted in DQMH itself or in the events/queue functions of LabVIEW.
I have posted a overall architecture picture created with AntiDoc in one of my earlier replies. This picture shows all the DQMH modules and their connections. As I said, this project contains over 2000 VIs, and I am sure no one wants to go through that on this forum! Usually bugs can be localized to one or two VIs then sent to the forum like this, but the weird bugs that I am seeing (random duplication of old data, different data elements arriving out of order etc) cannot be reproduced without running the full project.
I'd be happy to try and help figure this out, but from what you've described here so far, I'm not sure I understand correctly how the modules work together:
- How are the modules connect? I.e. which module uses which requests of others, which modules are registered for other modules' broadcasts?
-
- You're mentioning 15 modules (8x DUT, 1x DAQ, 1x Logger, ...?)
- You mention 8x 16 channels in one place, but only 1 counter channel per DUT (8 in total) coming from a cDAQ counter module in another place
The AntiDoc picture I posted in my previous post shows the DQMH modules. The 8 DUTs are all cloned from a single module called "Unit Display". Beyond that, there are several additional DQMH modules. My initial count of 15 was incorrect. It is closer to 20, counting the Unit Display as 1 module.
There are approximately 16 data channels per DUT, but they are mix of different types of signals. Some Analogs (Voltage, Current, Temperature), some LIN, some Bluetooth, some angle measurements. But the two operating events per cycle that I mentioned are detected by a Counter channel. So although there is only 1 counter channel per DUT, it has other types of Channels of data associated with it. All these different data have to be assembled into one record for each operating event. Hence my estimation of 8 DUTs x 16 channels.
4) I was dreading this approach. Just the suggestion of an Activity Tracker contradicts the supposed robustness of the underlying DQMH architecture!
I find this statement interesting, as I'm of the exact opposite opinion. The very first thing we put in place whenever starting a new project is our HSE Logger (a small, free, open-source logging tool, designed after the Python logging library), which out-of-the-box can log to files or user events.
Since l last posted, I have created and installed an Activity Logger on one of the Modules (Data Formatting Module). This logger records all events received by the Module to a file with timestamp. As I feared it is collecting huge amounts of data (>120MB per day). I have set the logger to start a new file every day. On Monday, I will have the customer send me the log files so I can look through them. I am not new to debugging by any means and I have done my share of logging activity before but that is for capturing hardware or system faults, not for a perceived software fault. Such faults are usually revealed by simulation testing, and conventional debugging methods.
It is quite common - and probably even recommended best practice in most cases - to design your modules in a way that they don't (statically) depend on each other. One way to do that is to design a tree-like structure for how modules communicate. I think that's often mentioned when talking about Actor-based design. Messages sent from one module to another will travel from the sender up the "tree" to a common node, then back down to the recipient.
At first look, the fact that data is routed through a module (or modules) adds complexity to your application. On second look, it also reduces complexity by cutting down on the number of direct connections between all your modules (and thus, helping with cohesion and coupling). There are various methods that can help with adding more transparency to the communication. Logging, as mentioned above, is one method that I feel is definitely worth a look.
Again, if you're able to share more information, we (both the Consortium and the community) would be happy to look into it and try to help solve your issue.
Like I said before, I have been Certified LabVIEW Developer for 15 years. You might wonder why I did not become a CLA. It is because I have very definite notions on software architecture, and my thinking is somewhat counter to what NI expects of CLAs. But in reality I have always been an architect and a developer. To me simplicity, maintainability, performance, robustness come first. Some vague understanding of future expansion needs and designing the software for that, to the point of becoming a huge overwhelming architecture comes a distant second.
Sorry for the long reply. I will keep you posted on what I find. As you said it is probably unlikely to be a DQMH bug, but the architecture is definitely getting in the way of debugging this.
Certified LabVIEW Developer (since 2005)
LabVIEW Developer since Version 2.0
