Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 03/20/2023 in all areas

  1. Break down your complex and complicated data types into a complex and complicated architecture. FTFY
    2 points
  2. The best approach would be to take that code and make your own shared library from it. Export functions to Open the device, Grab Images and Close the device. Basically you do not want an executable with a main function but instead you want a shared library that seperates those indvidual functions out. Why not call the underlying library directly through the Call Library Node you may ask. Because you have a callback function in there! It may be possible otherwise but that callback really is a no go for direct LabVIEW interfacing.
    1 point
  3. Not like this Because that is the goal; break down your complex and complicated data types into simple and uncomplicated ones. For configuration data you could maintain the path to the storage location and load the data as needed.
    1 point
  4. Thanks for sharing! I guess I'm just trying to stay positive. Every time the future of LabVIEW is brought up here things goes so gloomy so fast! And I'm trying to wrap my head around what is true and what is nothing but mindset. It's ironic though: last months there has been so much hype around AI being used for programming, especially Googles AlphaCode ranking top 54% in competetive programming (https://www.deepmind.com/blog/competitive-programming-with-alphacode). Writing code from natural text input. So we're heading towards a future where classic "coding" could fast be obsolete, leaving the mundane tasks to the AI. And still, there already is a tool that could help you with that, a tools that has been around for 30 years, a graphical programming tool. So how, how, could LabVIEW not fit in this future?
    1 point
×
×
  • Create New...

Important Information

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