Migrate from QMH to DQMH

[IPach]

Hello everyone,

I have a legacy application based in QMH template, although is not the same as NI official template.This is the structure of the modules, a library containing these folders. The public api has functions to enqueue messages of the module and the private VIs are functions used in the module.

There isn't documentation at all, I'm stepping into the program to discover al the functionalities. The program basically is a SCADA that interacts with a cDAQ and some PLCs using modbus comms.When the program doesn't have access to one of the elements of the system (e.g. no access to modbus server, cDAQ, etc.) it gives an error and you can't develop the other modules separately. The software is running in the system, that's the reason I don't have access to the system, because if I want to develop something new I have to stop the system.

I'm new to DQMH, but as far as I now you can create tests for each module to evaluate them separately. This is something I don't have right now and adding new functionalities to the code is becoming a nightmare.

I'm wondering how much time will it take making the switch to DQMH and if it will be worth it. People with more experience on the field could give me some advice?

Thank you in advance!

[Ozfarmboy]

How many "modules" do you think this system has?  ie. One (or more?) for PLC, one for cDAQ, one for Database, one for main gui.  Anything else?

[Enrique.Noe]

Hi, I'm so glad you are considering migrating to DQMH. It will make your life much easier in the long run, trust me. I have some experience with QMH and I know how frustrating it can be to deal with QMH issues. For instance, in QMH you need to create and manage the queues yourself, which can be tricky and error-prone. If you mess up the message format or the data type, you will run into trouble. Modifying or deleting messages is also a hassle.

But with DQMH, you don't have to worry about any of that. DQMH has scripting tools that automate everything for you. You also get API testers for each module, which are very useful for debugging and testing your system components. DQMH also has validation tools that check your module quality and compliance. And one more thing, DQMH supports clonable modules, which are awesome. For example, if your system uses one PLC now, but you need to add more PLCs later, you can do that easily with DQMH. You can have a clonable module called PLC and create as many instances as you need, even dynamically at runtime.

So yeah, DQMH is totally worth it. I hope this helps you make your decision.

[IPach]

The modules are (following the same structure as Database):

• Database
• Error Handler
• Manager
• Modbus Master (PLC)
• System Resources
• Template
• UI
• Initialize
• Watchdog

[Ozfarmboy · Accepted solution]

I am with Enrique, but a program re-write shouldn't be underestimated.  Sam could chime in to this I'm sure - he has heaps of ideas about this.  I've done a couple of re-writes before.  They both ended up successful, and were the right choice looking back, but they were a huge amount of work, and took much longer than anyone thought.  We certainly didn't make a profit!  But we've also looked at legacy code and decided that a re-write is just too risky and there is no way the customer would consider paying for it.

So here's how you could asses it:

1. Firstly you'll need to work through the existing code to work out exactly what it needs to do.  A bit of reverse engineering - perhaps you could put together a requirements spec from this effort. This is the most important step, and could take a long time if the application is quite involved.  You don't want to miss anything.  Let's say 2 weeks.
2. Then you'll need to work out what of the existing code can be reused.  Hopefully there are some "meatballs within the spaghetti" as Fab would say!  Some of this code may need to be improved - documented, VI descriptions, block diagram cleaned up, VI analyser runs, etc.  Let's say another 2 weeks.
3. Then you'll need to set a project design.  How are you going to structure your application, and what is each module going to need to do, and how will they interface with the rest of the application. 1 week
4. Then you'll need to develop it. You've identified about 9 modules there - some modules won't take long at all, but some will take some effort to get right.  Maybe you could say nominally one week to write each module, so 9 weeks.
5. Integration and testing could be split into several stages - ensure each module works via the Tester and perhaps with simulated hardware.  Then build up to running all modules together, still with simulated hardware. Always hard to predict - depends on the complexity of the application, and how well you've done the earlier steps. Let's say 2 weeks
6. Then integrating with the real hardware.   Let's say 2 weeks, but possibly could blow out.
7. Then signing off against your requirements and release to production, tidy up documentation. 1 week

So you're looking at 19 weeks.  Which seems massive, but if this is a complex, relied upon application, and you've got to take a step back before making steps forward, it's going to take some effort.  But at the end of that process, you'll have a far more modular application, that will hopefully be more reliable.  And when new changes are requested, they will be so much easier to carry out.

[Taggart]

A complete rewrite is generally too risky. The big risk is you spend a ton of time on it and run out of money halfway through (because it always takes longer than you think it will). Then what you have either doesn't work or doesn't have nearly the feature set that is need to replace the existing machine and you end up left with a worthless pile of very pretty well-written code. 

I recommend rewrite by parts. It's much less risky. At each step you still have running working software. If you run out of time/money, what you have still works and runs and is better than what you started with.

The first step is to come up with same validation test. You need some way to verify that as you replace each module, the system still functions.

I would take each existing module one at a time and in parallel to it write a DQMH module that does the exact same thing. Even reuse some of the subvis from the exsting module if needed for complex calculations or logic. Get the DMQH module running and tested standalone. Then in rip the old module out and drop the DQMH in. Get it working. Test everything. Then move onto the next module. 

Even if you dislike the current division of responsibilities and want to change them, I would probably (unless its really bad) just convert each module to a DQMH module as is. Test the entire system once it has been converted to DQMH.  Then do the refactoring to move messages around and fix the coupling/dependencies and responsibility issues.

[Taggart]

To avoid repeating myself too much:
https://blog.sasworkshops.com/thoughts-on-rewrite-vs-refactor/

https://blog.sasworkshops.com/dont-rewrite-reinvent/

You might find this tool useful for creating some tests for your existing code.
https://blog.sasworkshops.com/approval-tests/

If you want a quick demo, just reach out. I'm happy to show you how it works.

[Taggart]

The last thought I will leave you with is (from one of my articles) - I know I said I didn't want to repeat myself.

Every Legacy Code Base Deserves a Good Refactoring Attempt

The last thing I would say is that before you rewrite, every code base deserves a good refactoring attempt. My only exception might be if the code never worked at all. In that case, I might just skip directly to a rewrite. Definitely timebox this refactoring attempt so you don't go too far down the rabbit hole.

One reason every legacy code base deserves a good refactoring attempt is that it just might work. You might find that it's not as hard to refactor as you thought. Even if the codebase is beyond saving and you determine that you need to do a rewrite, it's not a wasted effort. While you are refactoring, you are learning about the code and what it does. That has value and will make the effort of rewriting it a lot easier.

[Taggart]

One more interesting article.
https://blog.sasworkshops.com/legacy-code-testing-and-requirements/

[IPach]

Hello everyone!!

First of all, I want to thank all the people that give their insights on the matter.

I will gather all the advice and try to do the best with this legacy program.

If you want to build a house, the foundations must be good!! 🙂