Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


thols last won the day on March 17 2014

thols had the most liked content!

Profile Information

  • Gender

LabVIEW Information

  • Version
    LabVIEW 2019
  • Since

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

thols's Achievements


Rookie (2/14)

  • Reacting Well Rare
  • Dedicated Rare
  • First Post Rare
  • Collaborator Rare
  • Week One Done Rare

Recent Badges



  1. There were some minor changes in the TSS in that VI between LabVIEW-versions. I just replaced the old TSS in that VI with the new and now it worked. So no broken wires when changing anything in that VI.
  2. For me it has improved but is not quite fixed. I still get broken wires on the calling VI when changing anything in some vims. In fact, I have a VI which I copied from the Debug Log.lvlib:Debug Write.vim in vi.lib and made some changes to. My version breaks when I change anything in it, but the VI.lib-one does not. I have force-recompiled and am now trying to make my VI work like the one in vi.lib, but mine still breaks. I just might recreate it and see where/if it breaks then. I don't know if I am unlucky or if that might happen for others too. When the wires do break, it seems like they auto-heal better than before, when I had to rewire at every broken place, but now its enough to just do something that triggers a compile (I think).
  3. I would suggest using tdms to save the data. Then you don't have to reinvent the wheel, and you can save data for each point and just forget about how it works. The "Save" function you have can instead be an Export-function that exports the tdms-data to a text file. Just some quick thoughts to get you in the right direction. I'm sure you will get more thorough responses soon, but have a look at tdms in the meantime.
  4. Remember when Adobe started with SaaS? Everyone hated it. But since there was no real competitor to Photoshop, many accepted the subscription model in the end. The big difference to LabVIEW is that there ARE real alternatives, FREE alternatives. If NI had successfully taken LabVIEW into a modern era, they would have earned trust. Now, they instead throw this at us after NXG is scrapped and no hope is given to us that any real progress into the future will be made with LabVIEW, and they expect us to pay. (By no hope, I refer to the corporate one-liners about NXG and LabVIEW that scares me and that silence has reigned since). Maybe it is an intended strategy: to start implementing real progress in LabVIEW when we have to subscribe to get it. I really hope not. I hope they listen to the concerns in this thread, since that mirrors the concerns of most of the LabVIEW user base.
  5. Number of VIs means nothing. Design and following SOLID principles is everything. Then you will never have too many or too few VIs or have a hard time finding "the code".
  6. Its just ridiculous and I feel sorry for you. Is it only the manager that demands this button or are there others in the review. A requirement needs a reason to exist. If the manager anyone wants something, ask him them to make a user story of it. A Suggestion: "As a manager, I demand a stop button to close the application, because ... I'm the manager!" or "As a user of the application, I need a button named STOP to close the application, because the X is so hard to find". When you have to describe a reason for it, it will either show how ridiculous it is or a real reason for it will emerge. Anyway, you will get it documented and you can blame others for the bad design :).
  7. But we could have stayed with sexadecimal: HAL 9000 and Sexadecimal: Old School Math
  8. And also, its not silent. Creating a file or writing to a file with too long path name will give you error 6.
  9. Nice! Now make it infinite pac-man style scrolling like in that video
  10. crossposted: https://forums.ni.com/t5/LabVIEW/Print-a-PDF-File/m-p/4158140#M1200089
  11. NXG was terminated, with a few corporate BS sentences, and NI then said they would add all the great stuff to LabVIEW in 2021(+), but nothing of that is in LV2021. I can guess that it is due to a time of turmoil until the resources can be aligned to focus on LabVIEW. But, if NI does not very clearly present the roadmap at the NI Connect event, I will be more concerned. However, I do not agree that no real developments have been made to LV in 10 years. Heck, 10 years ago we didn't even have conditional tunnels. I think the biggest new thing is interfaces, which is a crucial part of the language that has been missing. But then we also have things like channel wires, malleable VIs, and much more. But many other things about LabVIEW feel old, and that's where NXG was supposed to come in... About NI services I don't know since it has been years since I bought hardware or had anything else to do with them. I cannot see any competitor to the productivity that is possible with LabVIEW compared to any other language. And the visual representation of parallel programming. So I hope NI makes the right decisions for LabVIEW.
  12. I used to use EyeStudio some years back. It worked quite well for finding buttons, clicking, entering text, evaluating visual results. https://eyeautomate.com/eyestudio/. At the time, it was free, but now its not, and quite expensive. So I have no idea if it is worth it now or how the product has evolved. Perhaps its great now or perhaps its an old unmaintained product they are trying to sell. But I wish I had this type of product now.
  13. How could I miss that... I'm sorry for that.
  • Create New...

Important Information

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