How to wait for hardware at initialization?

[MaxScz]

Hey Guys,

often I have applications where I have some measurement devices that need some time for start or initialization.

The initialization is done at the start of the module. While the module initializes I want the caller to wait for the module to finish the initialization. If an error happens while initialization, I want to know it too.

For me this sounds like a wait for replay or round trip event, but the start is always a request + broadcast and there is no error feedback.

I know, that there is a possibility to create my own DQMH Template. But I can't imagine, that I am the only one with this problem/question, so I want to discuss it in public.

So here are my questions:
1. How do you handle this problem?
2. Wouldn't it be better to make the module start a round trip event?

Thanks for your replies and ideas,

Max

PS: If something is unclear, pls ask. I have not written English for a while...

[joerg.hampel · Accepted solution]

Short answer: We don't do anything custom in the "Initialize" case of a DQMH module.

Long(ish) answer: The way we see/use it, the "Initialize" relates to the module itself, not to whatever the module manages. It might be that multiple modules need to start before we can configure an individual one because of dependencies. Hence, we want to have control over when the module itself initializes and when the thing that the module manages is configured/initialized.

All our modules have a default "Configure" request which is the place where configuration files are read etc (and initialization of hardware might happen at the earliest). For Windows applications, the Configure request is called automatically through our application template (it's available for free in a public GitLab repository). For RT applications, we call the Configure request manually at the appropriate place.

Not knowing the specifics of your use case, here's what I would do:
- if the time you need to wait is rather short, I'd create a new Request with Reply to initialize your hardware (not reuse the default "Initialize" case)

- if the time you need to wait is very long or unknown at run-time, I'd create a new Roundtrip  to initialize your hardware (not reuse the default "Initialize" case) and register the caller for that corresponding broadcast. 

Seeing as this advice is highly subjective, I'm looking forward to opinions and criticism 😉

[Ozfarmboy · Accepted solution]

We have a similar approach at Wired-in Software to Jeorg's post above. We don't re-use the "Initialize" case of the Message Handling Loop (MHL).

For all of our "device" modules, which we have created a template for, is a default request called "Initialise Settings".  In our case it is only a request, but could just as easily be a request and wait for reply.

Initialise settings is a request where the calling code can pass down to the module specific configuration details as required.  This could include a device id, a com port, or an ip address, etc. This request might trigger further messages in the MHL to complete the setup of the device (ie it might "home" a motion system, connect to a serial device and check that we get a response to confirm comms, or it might setup DAQmx tasks - just depends on the device).

[MaxScz]

Hey Guys,

thanks for your replies. I think your solution will work for me, but I also think we should line this out in the documentation or in an article.

Some more questions about DQMH and working with hardware:
1. Where do you release the HW references? In "Stop" or in another extra release case?
2. Do you check if the HW is configured? If the HW isn´t configured and you send some messages, you can get some odd errors which don´t point out, that the HW is not configured.

Thank you very much for your ideas.

Max

[ryan_sheppard]

---

@MaxScz wrote:

Hey Guys,

thanks for your replies. I think your solution will work for me, but I also think we should line this out in the documentation or in an article.

Some more questions about DQMH and working with hardware:
1. Where do you release the HW references? In "Stop" or in another extra release case?
2. Do you check if the HW is configured? If the HW isn´t configured and you send some messages, you can get some odd errors which don´t point out, that the HW is not configured.

Thank you very much for your ideas.

Max

---

It's too application specific to put into the documentation.

For the first question, that is also application specific. Do you want the user of your API to be able to control the release of HW references? Maybe for your application once you create the reference you will never close it until the application is closed.

For question 2, it depends on the hardware. Can you ping the hardware, and expect a certain response? If you do not get that response, you can handle the connection.

[Ozfarmboy · Accepted solution]

Some more questions about DQMH and working with hardware:
1. Where do you release the HW references? In "Stop" or in another extra release case?
2. Do you check if the HW is configured? If the HW isn´t configured and you send some messages, you can get some odd errors which don´t point out, that the HW is not configured.

---

1 - We have either have a separate case for releasing the HW reference, or we might have a "Connect" case that is dual purpose.  ie. For a COM Port, we may want the ability to connect/disconnect/reconnect etc, so we have a connect case that also handles the disconnect

2 - We have a Boolean flag in the Internal data cluster called "Connected".  This is FALSE by default, and gets set to TRUE once we have connected to the device.  Then for all other MHL cases that act on a request, we check if the device is connected first and throw an error if not.  This error will get sent back to the caller if it was a request and wait for reply, but an error will also get broadcast (as is standard with DQMH modules).

[MaxScz]

---

@ryan_sheppard wrote:

---

---

It's too application specific to put into the documentation.

For the first question, that is also application specific. Do you want the user of your API to be able to control the release of HW references? Maybe for your application once you create the reference you will never close it until the application is closed.

For question 2, it depends on the hardware. Can you ping the hardware, and expect a certain response? If you do not get that response, you can handle the connection.

---

I dont think, that´s application specific. If I can (theoretical) configure/reserve the HW to any time, also should be able to release the HW to any time. Even if you don't use it, I think the best Idea is to keep working with HW straight is the best way.

Question 2 was maybe not that good formulated. My Idea was the solution from Ozfarmboy , but I wanted to know how others avoid erros from not connected/configured HW

@Christopher:

Thank you very much for you approach. My Ideas were in the same direction.

Max