Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation since 02/19/2024 in Posts

  1. There's also a little known feature in the top method where you can right click the Wait On Asynchronous Call and can set a timeout. This will then wait some amount of time for the VI to finish and will generate an error if it isn't completed yet. There are better ways to handle knowing when the VI is done, but it is good for a quick and dirty solution to wait a few ms for it to finish, and if it isn't done, go service something like the UI and come back again later. I submitted that as an idea on the Idea Exchange, then AQ said why it was a bad idea. Only for years later it to be implemented anyway.
    2 points
  2. I would actually suggest to implement it properly by extending the File Dialog Node. A double NULL terminated string array that is simply passed to a Windows API function is hardly a safe and proper LabVIEW datatype! 😁 And of course you saw it already coming, add support for that on Linux too 😁
    1 point
  3. The multiple patterns nugget was broken in LabVIEW 2023 Q1, but it works in LabVIEW 2023 Q3 and later.
    1 point
  4. I emailed the site admin to see if there is something broken. Welcome back.
    1 point
  5. I use User Events as the transport mechanism between asynchronous processes. As a result I wish there were a feature where there was an event generated when a reference goes invalid. I made an Idea on the Idea Exchange here. Similarly the work around is to have a timeout where the reference is checked to be invalid. A better solution is to send a stop command as some kind of global user event, or in your case enqueue. But as you've seen there can be edge cases where things stop unexpectedly and I just want all the running children to go through their cleanup process. Stopping on the error, or invalid user event reference, is a fairly simple way to do that.
    1 point
  6. The variant attribute cannot have duplicates. If you set it, it overwrites the previous values. With the "array with tag" you can have duplicates.
    1 point
  7. For your own long-term sanity, I do not recommend replacing any existing wires you have with a variant+attributes. Maybe I am misunderstanding your use case though...
    1 point
  8. FYI, there is a new feature in LabVIEW 2024Q1 where can wire the reference to the VI Path input on the Open VI Reference. You do also need to wire up the Type Specifier if you need the strict type. NI has stated the need for the type specifier as a bug per this thread on the dark side: New Open VI Reference Functionality
    1 point
  9. One small correction. The Open VI Reference will block on UI Rootloop even in the first (top) one. The Run Asynchronous method will however not incur a rootloop round trip.
    1 point
  10. The top one, the SAC, will run even if the root loop is busy, AND allows you to set the inputs. This function was not available in LabVIEW until version 2011 or so. It is especially useful if you need your application to spawn VI clones to handle various events (TCP session handlers for example) regardless of what the user is doing in the GUI... The two bottom ones will be blocked if the root loop is busy, e.g. if the user happens to be viewing the time picker of a time control it will halt until the user closes the time picker. Before the SAC was introduced in LabVIEW you had to use the run method (bottom one) if you wanted to avoid having to wait for the dynamically launched VI to complete (it has the Wait until done input). The Call by reference node on the other hand had the advantage over the run method of offering control inputs to the call whereas the run method would require you to use set control invoke nodes for that. Here is a long thread about the root loop issue from before the SAC was introduced: https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Calendar-control-that-does-not-block-the-GUI/idi-p/1417794?search-action-id=359039184054&search-result-uid=1417794
    1 point
  11. Is there a reason you are doing this, instead of having a type def'd cluster? Then you can use the Bundle/Unbundle by name to get and set values within a single wire? Then probing is easier, and adding or updating data types can be done by updating that one cluster. Typically Variant Attributes are used in places where an architecture wants to abstract away some transport layer that can't be known at runtime. In your case we know the data type of all the individual elements. If you were doing some kind of flatten to a Variant, then sending over TCP, you'd want some standard way to unwrap everything once it got back. I've also seen it used where a single User Event handles many different events, by using the Variant as the data type. Then each specific User Event will have a Variant to Data to convert back to whatever that specific event wants. There isn't anything wrong with what you are doing, I'm just unsure if it is necessary.
    1 point
  12. Top: Start Asynchronous Call - Loads a VI, starts running the VI, and then waits for it to complete. The SAC returns as soon as the VI has started to run. The Wait On Asynchronous Call is what waits for the VI to complete and return its outputs. Middle: Call By Reference - Loads a VI and runs it. The CBR will not return until the called VI is complete. Bottom: Run VI Invoke Node - Loads a VI and runs it. If you wire FALSE to the Wait Until Done input, the VI runs asynchronously. If you wire a TRUE to the Wait Until Done input, the invoke node will not return until the VI is complete. You do not have a direct way of getting the results once the VI is complete.
    1 point
  13. Yes, at some point I intend to make an interface that has "to JSON" and "from JSON" methods, that one can inherit from. But at the moment JSONtext is based in LabVIEW 2017.
    1 point
  14. hooovahh, we have been giving feedback for > 5 years. Nobody with any authority to direct change seems to be interested. The thing I cannot understand is this... the engineers intimately familiar with LabVIEW today are the engineering managers of tomorrow. NI is pissing off the engineers of today who are the ones signing the purchase orders of tomorrow. I never intended for this post to descend into a rant session, I am just disappointed that after so much investment by NI this is the product that has been laid on the table. There was no need to revisit change every single decision in current gen, most of the paradigms worked really well. I would literally hold captive anyone even remotely interested in LabVIEW and gush wildly over its amazingness, like a parent gushing over their favourite child. Now when people ask me about NXG I sort of blink and stare into the distance and change the conversation.
    1 point
  15. Skimming thru this thread... try this: From C, call `PostLVUserEvent()`. Then, in LabVIEW, rather than registering that event reference into a `Register for Events` node, register the event reference with a `Register Event Callback` node. Here's the game-changer -- `PostLVUserEvent()` in C will behave differently depending on how the associated event reference is registered in LabVIEW. When a listener is bound to the event using `Register for Events`, `PostLVUserEvent()` is asynchronous and non-blocking, and does not wait for the consumption of the event. It "blocks" only long enough to copy data reliably into the queue shared by its message-reference-counting registrants, then moves along. On the other hand, `PostLVUserEvent()` will synchronously block until the Callback VI handler has finished executing. This means, your library can `Post` some pointers/handles into LabVIEW, LabVIEW can fill them in the Callback VI, and downstream logic from the `PostLVUserEvent()` needs no further gymnastics to synchronize/mutex.
    1 point
×
×
  • Create New...

Important Information

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