joerghampel

Hey Thomas, feel free to contact us via our website. We have CPIs on our team and offer both NI courses and customised training, consulting and workshops (see https://www.hampel-soft.com/services/). If we're not the right match, I'm sure I can forward your request to other consultants.

Dear community and network, at HSE, we are big believers in Inner Source (https://en.wikipedia.org/wiki/Inner_source) and apply it to our customer projects. By opening up our code as open source to the public and sharing it for free we make sure we stay on top of the tools and processes needed for that, and we pay back to the awesome LabVIEW community. You can browse our Open Source offerings at https://code.hampel-soft.com. We constantly work to give back to the community and widen our offerings. But we need your help! Please let us know how you use our open source LabVIEW and DQMH code, by taking this quick (promise!) survey: https://bit.ly/HSE-OS-Survey-2022 This survey is targeted at those of you who use our tools. But even if you don't use any HSE offerings, we have some questions for you. We want to hear your feedback so we can keep improving our offerings and our logistics. Thank you in advance!! Joerg PS: This has been posted on the dark side, too.

Oh man I really really miss that!!

Hey Neil, can you share the CAR number for this (LV not releasing closed projects from memory)?

I can confirm this trend, I had very good experience in the last year or so.

Generally, once the project is setup, it usually doesn't change much for us. If you're using .lvlib's and/or LVOOP to organise your code, ongoing development will not touch the .lvproj file much. Yet another option... Have two .lvproj files: One for the developer, and another one for the installer.

I'd have happily helped you along those steps 😍 so you can get to the actual work! But seeing as git is integral to our way of working, that's an important piece of information for me.

For the last few candidates I interviewed, I had prepared the following process: a ~1-hour conversation to get a feeling of the person (in person until the pandemic hit, then via MS Teams), chatting about their past experience, current work, personal interests, involvement in the community etc. a sample project to work on, which they had to clone from GitLab (via git), get the problem statement (requirements) from the readme, and describe in words how to solve the problem another short conversation about their reply and suggested solution implement part of the requirements in the sample project and submit the solution via GitLab (git) another conversation about how they solved it, why, etc. Regarding certifications, I recently posted to LinkedIn about my opinion on them. Edit: The project mentioned above is an actual project of ours, where we had to implement some small changes to a very badly written piece of legacy code with no encapsulation, documentation, etc.

So you're saying that because a customer pays for a solution they get, they buy the rights to the people who worked on it? I don't agree with that notion. Also, while people can't be kept from switching jobs, and companies can't be kept from advertising their vacancies, "poaching" your local integrator's employees doesn't sound like the right thing to do to me. Good thing my employees are in Germany and thus not local to you.

Tom McQuillan offers a tool that helps with updating VI descriptions and icons: https://github.com/TomsLabVIEWExtensions/Documentation-Tool AntiDoc by wovalab (Olivier Jourdan) generates very nice and extensive documentation for DQMH modules, LV classes and .lvlibs. Here's an example PDF of our open-source application template.

Unser nächstes Meeting findet am Donnerstag 29. Juli von 17:00 - 20:00 statt: Ich freue mich, Euch zumindest virtuell bald wieder zu sehen!! LG Jörg Wann: Donnerstag, 29. Juli, 17:00 Uhr CEST Wo: Virtuell via Microsoft Teams (Link via Eventbrite) Vorab gibt's wie immer ein Test-Meeting, so dass alle Teilnehmer die Technik testen können. Ein bisschen Hilfe zu virtuellen Meetings und zu MS Teams gibt's in unserem Dokuwiki. Bitte vergesst nicht, Euch via Eventbrite anzumelden! Agenda: NI Schulungen und Zertifizierungen Überblick (Adrienn Nagy) Ev.: Certification Details (NI-Team USA, in English) Tipps, Tricks und Einblicke in Zertifizierungsprüfungen (Andreas Kreiseder) Prüfungsbeispiele, offene Diskussion Anmeldung: https://wuelug13.eventbrite.de

@The Q started such a thing on the LabVIEW Wiki: https://labviewwiki.org/wiki/Text-Based_terminology

Another reason for git (not LabVIEW!) reporting changes where there don't seem to be any is file permission. If your repository is on a filesystem where executable bits are unreliable (like FAT), git should be configured to ignore differences in file modes recorded in the index and the file mode on the filesystem if they differ only on executable bit: git config --local core.filemode false and/or git config --global core.filemode false And while we're at configuring git for Windows: Due to a Windows API limitation of file paths having 260 or fewer characters, Git checkouts fail on Windows with “Filename too long error: unable to create file” errors if a path is longer than the 260 characters. To resolve this issue, run the following command from GitBash or the Git CMD prompt: git config --system core.longpaths true (Taken from our public Dokuwiki)

Exactly, what you say here is correct. I was confused by your suggestion to "use the MHL timeout" - but I realise now you actually meant to change the timeout setting for reading from the message queue in Delacor_lib_QMH_Dequeue Message.vi, right? That could be done by implementing your own child class for the default DQMH Message Queue class and overriding that method. While there definitely are proper use cases for implementing your own child class of the Message Queue, I don't think this is one. I would advise against going down that rather unusual road when there are simpler solutions available. You can make your helper loop private (then the only way to control it from outside the module is to go through EHL and MHL, just as you describe). Or, you can design your helper loop to contain an event structure, and make it publicly available by registering for (some of the) DQMH module's request events directly in the helper loop's event structure. This is the design we describe in our blog post on helper loops.

Hey Matt, great that you're looking into using DQMH! Regarding your first question, I think you're using the term MHL (Message Handling Loop, the one in the bottom with the case structure) to describe the EHL (Event Handling Loop, the one on top with the event structure). You're saying that "by having my helper loop broadcast, I feel like I'm taking away from the main design that the MHL is supposed to broadcast". I don't think that by design only the MHL or EHL should do broadcasting. I would most definitely go with a helper loop. If you haven't seen it yet, feel free to take a look at our blog post on helper loops. It shows how to create helper loops that can be enabled/disabled. Regarding your second issue, many people advocate to structure your modules like a tree, for exactly those reasons you already mentioned. You will find that as you remove the static dependencies, reusability of Modules B and C will pay for a little "cumbersomeness". Here's a graph illustrating that tree structure (I created it for another thread some time ago, so please excuse that the naming is different to yours) : Let me know if this helps!