Jump to content

joerghampel

Members
  • Content Count

    39
  • Joined

  • Last visited

  • Days Won

    4

joerghampel last won the day on March 12

joerghampel had the most liked content!

Community Reputation

18

1 Follower

About joerghampel

  • Rank
    More Active
  • Birthday July 7

Profile Information

  • Gender
    Male
  • Location
    Würzburg, Germany

Contact Methods

LabVIEW Information

  • Version
    LabVIEW 2020
  • Since
    2007

Recent Profile Visitors

1,830 profile views
  1. @The Q started such a thing on the LabVIEW Wiki: https://labviewwiki.org/wiki/Text-Based_terminology
  2. 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 chec
  3. 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
  4. 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 loo
  5. Yes, sorry, and thanks for pointing that out. It seems the editor thought the dot would make a nice addition to the URL, and I didn't catch it. I just fixed.
  6. ...and for what it's worth, we use G-CLI, which sets the "App.UnattendedMode" property. That seems to be all it needs. G-CLI also allows to kill the LabVIEW process after some timeout in case it should hang.
  7. I don't disagree. I've been working on our tools for ~ 10 years now, maybe 5 years running them automatically on a server. Some kinks could be ironed out, others worked around. It's definitely still a pain sometimes (add to the LabVIEW woes some other troubles like VMs losing network connectivity etc.). All in all, the whole experience has taught us so much process-wise. And of course, once you got used something, you don't want to do without it anymore. I believe that's the actual USP of our tools for our customers: The process we teach while integrating our tools into their environ
  8. Have you seen Sam Sharp's presentation on Test Complete?
  9. Answering the question in this post's title: Yes! We're very happy with our solution, we can apply .vipc's, validate DQMH modules, run VI Analyzer and Unit Tests, create documentation from source code, execute build specifications, create .vip's, package results into zip archives and deploy (move the result files somewhere). We have also created plugins for our dokuwiki which will automatically compile a release list with links to the artefacts. At the moment, we're working on adding FPGA compilation to the list of features. It's a commercial product, but you might get some inspirat
  10. I've only seen/used TOML for GitLab CI's gitlab-runner configuration (i.e. not in LabVIEW)...
  11. 1. What type of source control software you are using? Git on GitLab with Git Fork or Git Tower 2. You love it, or hate it? LOVE it!! 3. Are you forced to use this source control because it's the method used in your company, but you would rather use something else We get to choose, and git is the scc system of our choice. 4. Pro's and Con's of the source control you are using? Pro: Decentralised, very popular (i.e. many teams use it), very flexible, very fast, feature branches, tagging, ... Con: Complicated to set up if using SSH, Exotic use cases/situatio
  12. I wrote a blog post about separating compiled code a while ago, it might be interesting for you: https://www.hampel-soft.com/blog/separate-compiled-code-from-source/
  13. For those of you interested in exploring CI/CD with git (and especially with GitLab), please take 5 minutes to visit our Release Automation Tools for LabVIEW website. At the very least, you'll get an impression of (and maybe some inspiration through) what we've been doing for ourselves and for some of our customers for quite some time now. A ready-made solution might save you a lot of development time. If you want more details, I can share recordings of webinars we did a while back. I'd also be happy to show you around myself, too. Spoiler(?) alert: This is a commercial tool.
  14. +1 for allowing GitHub as a GPM repo (and GitLab, too). I watched Derek's CLA Summit presentation on What's new in GPM and was intrigued by the local/private repositories! Don't get me wrong, we already share our own libs and might also do so via GPM, but this makes it probably viable to use it for our customer projects. I will definitely have a play with it in the holidays (and am looking forward to it 🙂 )
  15. Yes, I was quite excited about that! But last time I checked, there was no way for private or local repositories. Is that still the case? Thanks for rephrasing. Yes, I think this is what I'm saying.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.