Using the Time-Out of a Request and Wait for Reply in the called module itself

[ngblume]

Hey everyone,

I'm looking for the most convenient way to use the specified time-out of a Request and Wait for Reply in the DQMH module it is sent to.

As far as I can see, this information is only used "locally" in the public API VI on the calling side as the time-out of the response notifier.

In my use case, I would like to take the calling-side specified time-out as the time-out (or maybe a little less) for the communication with a device as well.

So far, my solution looks like this:

I would probably have to add time-out information to the Argument payload and then also use this value as the time-out in the public API VI.

Doable, but tedious...

Is there a reason why that time-out info is not sent along with the message? Are other thinking along these lines as well?

It looks to me as if an checkbox-option in the Event creation diaglog, which does this, if requested by the event creator, would be helpful.

Thanks!

Cheers

Niels

[joerg.hampel]

My wild guess is that the local timeout is exactly that - local. It does define what the module internally deems a proper general maximum time to wait for an answer. 

> Is there a reason why that time-out info is not sent along with the message?

My guess here is that as it's already a private VI, the information would be redundant.

Overall, the Module Timeout constant defines the module's timeout behaviour. Its name does not imply that it defines a communication timeout. Personally, I would probably prefer to see the communication timeout explicitly defined somewhere in the code, not mixed up with the module-internal general timeout value.

One way would be to configure that communication timeout (eg via a request) and store it on the module's data cluster (that's what we do most often). The module timeout needs to be bigger than that value, obviously. If that timeout is very long, we'd go with an asynchronous broadcast instead of the synchronous reply.

Another way would be to add the communication timeout as a parameter of the request and modify the request VI manually to use this value instead of the module timeout. I would probably not advocate for this way as it deviates from the standard design principles of DQMH and might be confusing the others looking at the code(?).

[ngblume]

Hey Jörg,

thank you for the reply.

---

@joerg.hampel wrote:

My wild guess is that the local timeout is exactly that - local. It does define what the module internally deems a proper general maximum time to wait for an answer. 

---

That's where I got confused, since this doesn't even happen "in" the module, but in the caller (or the calling VI), so the module has no influence on this at all (which could be good or bad, depending on the situation).

---

@joerg.hampel wrote:

> Is there a reason why that time-out info is not sent along with the message?

My guess here is that as it's already a private VI, the information would be redundant.

---

It is a private VI, but there is no run-time knowledge availabe for the module of the actually set timeout at the sender side of things.

---

@joerg.hampel wrote:

Overall, the Module Timeout constant defines the module's timeout behaviour. Its name does not imply that it defines a communication timeout. Personally, I would probably prefer to see the communication timeout explicitly defined somewhere in the code, not mixed up with the module-internal general timeout value.

---

That's where I disagree, because the module for example cannot force a premature timeout, since this happens only on the client-side.

For me this time-out is kind of a "communication-with-module" timeout.. or simplier said: "When do I not care about an answer from the module anymore?" So it's, again, not really related to what happens inside the module. 

---

@joerg.hampel wrote:

One way would be to configure that communication timeout (eg via a request) and store it on the module's data cluster (that's what we do most often). The module timeout needs to be bigger than that value, obviously. If that timeout is very long, we'd go with an asynchronous broadcast instead of the synchronous reply.

---

This works great, as long as you don't have different time-out for different tasks / commands / messages to the device.

That's why I was advocating a per-event-based approach.

---

@joerg.hampel wrote:

Another way would be to add the communication timeout as a parameter of the request and modify the request VI manually to use this value instead of the module timeout. I would probably not advocate for this way as it deviates from the standard design principles of DQMH and might be confusing the others looking at the code(?).

---

Exactly.. but also the reason in my opinion to make this maybe selectable, so that you can decide between handling this only on the client side, or on both sides as well...

Also, from a purely code standpoint, is it correct, that when the timeout occurs on the client-side, the module can still try to send the response "too late" on a notifier, that is destroyed?

Thanks!

Cheers

Niels 

[joerg.hampel]

That's the nice thing about software design - with knowledge of your requirements, and knowledge of the caveats of the different implementation options, you can build the solution just to your liking 🙂

So why not just go ahead and rework the Request VIs so that they function as you see fit for your current task? Seeing as DQMH offers a great templating engine, it's also very simple to reuse that modified module once you're happy with it. And it's both easier and quicker than going through a feature request 😉

Also, I'm only giving my opinion here, hopefully many others will add theirs, too, so that all of us can take something away.

Spoiler

And with that being said, here's more of my thinking:

• A request VI, though public, is still part of the module, not part of the calling code. So any information that's used inside this request VI (eg the timeout) is information internal to the module.
• If you want to expose the module's timeout, i.e. let the rest of the world know about it, you could create a request "Get Module Timeout" so the calling code can adjust to it.
• If the calling code needs to decide by itself when it actually wants to stop waiting for a reply from the module (even if it might come later on), I'm still thinking this should not be a request w/ reply but an asynchronous broadcast.

• "Also, from a purely code standpoint, is it correct, that when the timeout occurs on the client-side, the module can still try to send the response "too late" on a notifier, that is destroyed?"
  
  Yes, absolutely! By default, the error output is not wired, indicating that this very error is not of interest. But: The module could react on it if it wanted... The module also knows about its own timeout setting, so it can take action if need be.
  
  Generally, a module should be oblivious of the caller and his situation. That's why Delacor named it a request and not a command. Again, I'm thinking that this should be a broadcast...

But I think we're already deep inside the rabbit hole here...

[ChrisFarmerWIS]

I agree with much of what Joerg said.

Here is the way I see it:
1) The module timeout is by default used by ALL request and wait for reply events.  However quite often we need to use a unique timeout value for some events.  So you have a default value to start with.  But simply change it either globally, or on a case by case basis.
2) The timeout is not a communications timeout.  It is a backup plan in case something goes wrong with the module.  Let's say the modules is inundated with another request, or multiple requests - by the time its finally gets up to our request, the time's already gone.  So I see it as a warning sign - something else is fishy in how we are using that module. It's more than likely a design issue.
3) For device communication - for instance a serial port connection.  Like Joerg said - setup your Rx timeout as part of an initialisation request early on.  If you set this to say 2 seconds. And then your device will use this Rx Timeout, and the Req+Wait4Rep timeout (let's say you set this to 5secs) is merely a backup.  999 times out of 1000, you should get an Rx timeout error coming back in your reply if there is something wrong, rather than the request vi timing out. If the request VI times out, then you've probably got a design issue, rather than a device issue.

[joerg.hampel]

---

@ChrisFarmerWIS wrote:

If the request VI times out, then you've probably got a design issue, rather than a device issue.

---

This! I wish I'd have put it so eloquently 🙂

[FabiolaDelaCueva]

Hi Niels,

I agree with what Joerg and Chris have already replied. In our internal projects we have had the need of changing the timeout for specific requests.

For example, there is a module that has a request and wait for reply that takes care of the login. We cannot make this asynchronous because truly nothing else should run until we know we have the appropriate person logged in.

However, the logging in cannot timeout because we don't know how long the person is going to take to enter their credentials.

We opted for a -1 timeout, yes, wait forever. We had to add an event structure within the code that handles the request inside the module to make sure it would exit in the case the Stop Module is sent. Two things can return the reply: the end user entered their credentials successfully or they decided to cancel the login and stop the application all together.

This required us modifying the Request and Wait for Reply that DQMH scripted for us and that is fine. The template works for 99% of the times that we need it, in this case it doesn't fit our needs.

In the case of serial communications, we have done what Joerg suggested  of having a communication timeout. We have also done it as you suggested, have the timeout be part of the argument and we remove the module timeout that works 99% of the time and instead wire the input.

If you still think that the timeout should be an input to the Request and Wait for Reply, please add it as a feature request (there may already be one request in the old feature requests document) in our new DQMH Feature Requests idea exchange.

I hope this helps,

happy wiring,

Fab

[ngblume · Accepted solution]

Hey everyone,

thanks for the answers!

@Jörg and @Cristopher:
"The timeout is not a communications timeout.  It is a backup plan in case something goes wrong with the module.  Let's say the modules is inundated with another request, or multiple requests - by the time its finally gets up to our request, the time's already gone. "

That's where I see a potential for serious problems, since this could mean that the module is very busy, but eventually gets to the request (while the client-side timeout already occured). The module still performs the request and sends a reply (maybe even handles the send notification error).

But: the client does not get informed of the execution, since it killed the notifier and the client hopefully also reacts to the time-out... Whatever reaction that might be (resend command, etc.).

For me, such a request and reply pattern requires some kind of sanity check, if a request is still valid / open to be processed when the module gets to it (i.e. timestamp of send time + time-out alongside the reply notifier so the module can perform sanity checks itself). My concern comes mostly from what a novice programmer at DQMH expects to happen. My experience tells me, that the expectation would be, that such a time-out on an operation is "created" be the module, not the caller. But, sas Jörg said, rabbit hole and design decisions....

Maybe a hint in the docs might already be enough to avoid such situations...

And regarding "If the request VI times out, then you've probably got a design issue, rather than a device issue.":

I totally agree that Request and separate Broadcast "Replies" are probably the best way to handle long processing times, etc.

Most of my modules are currently used in TestStand, so using Broadcast events (to my understanding) would require "more" work on the TestStand side of things.

In my use cases, the TestStand sequence could be blocking, so I will probabyl increase event time-out and use a separate communications time-out in the messages itself.

Feature Request created: https://forums.ni.com/t5/DQMH-Feature-Requests/Incorporate-clientside-time-out-infos-into-requests-w...

Thanks !

Cheers

Niels

P.S.: Green NI still irritates me like hell... 😉