From 04:00 PM CDT – 08:00 PM CDT (09:00 PM UTC – 01:00 AM UTC) Tuesday, April 16, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

DQMH Consortium Toolkits Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Adding a CML/helper loop module to standard DQMH project

Solved!
Go to solution

Thanks again for clarifying Joerg.


@joerg.hampel wrote:
1. It is perfectly possible to use helper loops in current versions of DQMH, no need to fear any bugs or other side effects (if implemented correctly, that is)

My bold.  and therein lies the risk for me.  I don't trust myself to do it properly.

 

Both your points are very valid.

 

S/W and product V&V testing at my company continue for 12-18 months of a typical 3 year development cycle. This results in a very reliable product.   So I highly value debugged code.  Couple that with my low risk and reluctance to implement and debug a helper loop myself, and already having something in place that I understand and works for me, I am fine to wait for the formally released debugged version of helper loops. 

 

Thanks for being a helper human for helper loops !

Peter
Message 21 of 32
(1,039 Views)

@Peter_B  a écrit :

I am fine to wait for the formally released debugged version of helper loops. 

 


Hi @Peter_B ,

I'm not a native English speaker. I can misunderstand you, but I don't get why you are still saying you are waiting for a debugged version of helper loops. They are NOT bugged.


Olivier Jourdan

Wovalab founder | DQMH Consortium board member | LinkedIn |

Stop writing your LabVIEW code documentation, use Antidoc!
Message 22 of 32
(1,028 Views)

@Olivier-JOURDAN wrote:
I don't get why you are still saying you are waiting for a debugged version of helper loops. They are NOT bugged.

Ah, the meaning of words in any language can be ambiguous and downright funny in some cases !!

 

The basis of writing any S/W is that it is seldom perfect after the first attempt and requires the programmer to find and fix errors (bugs) in it.   That process of fixing errors is called debugging (verb).  The resultant code is known as debugged code (noun).  Perhaps a clearer description of the released code could be "fully tested" rather than "debugged", although the two terms as usually synonymous for an English speaker, I think.

Peter
0 Kudos
Message 23 of 32
(1,008 Views)

OK, so we are on the same page about the meaning of the words, and I still do not understand what you're expecting from the DQMH Consortium when you say, "I am fine to wait for the formally released debugged version of helper loops."

Helper loops have been used for ages by developers using the DQMH framework. You must understand how they work to use them efficiently and correctly (like any other pattern). But again, there's nothing to "debug" on the Helper loop itself on the framework side.

 

Anyhow, I hope you'll try the DQMH 7.0 (and the helper loop automated creation) when it is available.


Olivier Jourdan

Wovalab founder | DQMH Consortium board member | LinkedIn |

Stop writing your LabVIEW code documentation, use Antidoc!
0 Kudos
Message 24 of 32
(996 Views)

ah, thanks for clarifying.  Until DQMH 7.0 is released using tested automated helper loop generation and integration into a project,  "debugging" for me must happen in two main areas:

  1. My proper understanding and replication of the definitive guide to helper loops here https://dqmh.org/dqmh-actors/  (my possible misunderstanding or faulty replication from the article are sources of bugs for me), and
  2. The consortium's debugging of the auto scripted generation of helper loops in DQMH

 

Peter
0 Kudos
Message 25 of 32
(967 Views)

Ok, thanks for the clarification, too 😉

 

Concerning #2, I'm pretty confident it'll be free of bugs when released

Concerning #1, even if the creation is automated, you'll need to have an understanding of how a helper loop works to use it (the same way you understand how the EHL and MHL work). If you have any questions regarding that topic, feel free to create a new thread in the forum. The community of DQMH users is always keen to help 😊


Olivier Jourdan

Wovalab founder | DQMH Consortium board member | LinkedIn |

Stop writing your LabVIEW code documentation, use Antidoc!
Message 26 of 32
(953 Views)

@Peter_B I'm getting back to you here about Helper Loop usage.

 

I recently released a VIP to help LabVIEW developers implement Helper Loop.

 

The package is available on VIPM --> https://www.vipm.io/package/wovalab_lib_utilities/

 

If you have time to install it, I encourage you to glance at the examples in the palette.

 

If you don't have that time, just check out the documentation page related to the Helper Loop --> https://wovalab.gitlab.io/open-source/docs/utilities-toolkit/latest/helper-loop-timing.html

 

I hope you'll find this interesting.

 

 

 


Olivier Jourdan

Wovalab founder | DQMH Consortium board member | LinkedIn |

Stop writing your LabVIEW code documentation, use Antidoc!
0 Kudos
Message 27 of 32
(765 Views)

Thank you Olivier, I appreciate the heads-up.  I read through the help article you linked to.    I have some questions:

  1. Is this VIP helper loop implementation an independent implementation to the helper loop to be released in DQMH v7.0 ?
  2. A large majority of the help article concerns timing issues (jitter, run late etc).  Are those issues inherent to all helper loops and thus need understanding and mitigating regardless of whether the helper loop generation happens using the VIP or DQMH 7.0 ?

Your answers will guide me on which auto generated helper loop implementation I will try out.

Peter
0 Kudos
Message 28 of 32
(759 Views)

@Peter_B  a écrit :
  1. Is this VIP helper loop implementation an independent implementation to the helper loop to be released in DQMH v7.0 ?

This API can be used with any "Helper Loop" implementation according to the definition given in this section of the API documentation.

This API is not a tool to create a "Helper Loop" automatically.

It's totally independent of the DQMH framework.

 


@Peter_B  a écrit :
  1. A large majority of the help article concerns timing issues (jitter, run late etc).  Are those issues inherent to all helper loops and thus need understanding and mitigating regardless of whether the helper loop generation happens using the VIP or DQMH 7.0 ?

Running code with a steady period could be challenging even if you are not using a "Helper Loop" based on an event structure.

If you want to have a steady period execution (that's not always needed) with that kind of helper loop, you need to take care of the Timeout value. This is what the API helps you with.

I did it for ages and so lots of LabVIEW developers. I just try to make it easier to implement.

 


@Peter_B  a écrit :

Your answers will guide me on which auto generated helper loop implementation I will try out.


You don't have to choose. The API is complementary to what the DQMH framework is offering.

 

I hope it clarifies things 🤞


Olivier Jourdan

Wovalab founder | DQMH Consortium board member | LinkedIn |

Stop writing your LabVIEW code documentation, use Antidoc!
Message 29 of 32
(747 Views)

I took the opportunity to update our blog post on Helper Loops :
- add comments about Olivier's new timing tool

- add more comments about timing

- clarify our take on self-messaging

- improve the readability

- mention DQMH 7

- link to our new public repository for DQMH example code

 

Once DQMH 7.0 is officially released, I will update the screenshots and example code accordingly.

 

As always, I'd love some feedback on where and how to improve the article!

 

https://www.hampel-soft.com/blog/dqmh-actors-self-messaging-or-helper-loops/




DSH Pragmatic Software Development Workshops (Fab, Steve, Brian and me)
Release Automation Tools for LabVIEW (CI/CD integration with LabVIEW)
HSE Discord Server (Discuss our free and commercial tools and services)
DQMH® (The Future of Team-Based LabVIEW Development)


Message 30 of 32
(735 Views)