Jump to content

smithd

Members
  • Content Count

    688
  • Joined

  • Last visited

  • Days Won

    40

smithd last won the day on February 7

smithd had the most liked content!

Community Reputation

142

About smithd

  • Rank
    The 500 club

Profile Information

  • Gender
    Not Telling

LabVIEW Information

  • Version
    LabVIEW 2013
  • Since
    2011

Recent Profile Visitors

2,455 profile views
  1. Similar issue in nxg: https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Malleable-control-labels/idi-p/3782013/page/6#comments In this case its not the openg functions but is instead the built-in variant parsing functionality that has changed, but its all the same sort of general "metaprogramming" category.
  2. smithd

    LabVIEW Memes

    I'm not bothered by the size of that guy, I'm bothered that everything is serially executing
  3. i think those variant functions should be a tiny meaningless fraction of the overall execution time. Have you profiled it?
  4. In the compiler doc here (https://www.ni.com/tutorial/11472/en/) theres mention of a yieldIfNeeded block which is inserted into loops which allows for coordination with the rest of the runtime. If you just have the one while loop, you are still having to check against the runtime engine if you should keep running or if you need to pause and let other code run. Its not just a simple jump. tl;dr I dont think there is any way to do this with a regular loop. A timed loop may work. The overhead should be minimal compared to any actual code you wish to run in the loop, and if that isn't true labview is probably not the tool for the job.
  5. You're also what?! Make sure your lavag email is not @ni.com and then pm Michael. He can fixit.
  6. Before or after you tell those darn kids to get off your lawn?
  7. 2019 is almost certainly done already. Since its integrating an addon, it could come in SP1, but I'd bet 2020 if it happens.
  8. isn't that...an xcontrol? anywho, voted up
  9. My vague understanding is that labview exes are basically special zip files with an executable header tacked on with the instruction to load the labview runtime. The runtime then takes over and loads the code. This obviously changes with the fast file format, but the general concept is probably about the same. Point being, the exe is still a separate OS process, it just happens to immediately load up a copy of the lvruntime dll which can be shared.
  10. I don't know the exact details, but it looks like you could use a system-wide mutex: https://docs.microsoft.com/en-us/windows/desktop/api/synchapi/nf-synchapi-createmutexa I'm assuming linux has something similar. Or since its long-running, another option would be to do whole thing where you make a "blah.lock" file somewhere, like what git does. But thats clearly iffy.
  11. That much is definite -- processes can't share anything
  12. I don't know for sure (maybe @Rolf Kalbermatter does) but looking at this KB (https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019L5JSAU&l=en-US) indicates that its basically calling win32 LoadLibrary, and the help for that (https://docs.microsoft.com/en-us/windows/desktop/api/libloaderapi/nf-libloaderapi-loadlibrarya) seems to indicate there can only be one (per process):
  13. Coincidentally I just wrote a couple as well. I agree they seem OK for simple things, but the whole question of when and how they wake up makes them less usable. The main reason I want an Xcontrol is that a lot of things are combined controls+indicators. For example I have an indicator with the current value and the setpoint and some other stuff, and a control for the setpoint -- but you can't bind to user events, so you have to pick a proper 'direction' for the control and use a property for the other way and you end up having to marshal data around anyway. I don't hate them as much as I once did, but I don't like them. I think the q guy had it right, basically just grouping control references together and using standard functions to manipulate the group as one: https://sine.ni.com/nips/cds/view/p/lang/en/nid/214228
×
×
  • Create New...

Important Information

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