Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation since 02/28/2024 in all areas

  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 don't know exactly how your collection looks like and in what the NI Web Server as it is fills in, but as for linux and serving http I have been positively impressed by this: https://github.com/illuminated-g/lv-http-server In fact I did some preliminary evaluation of it some time ago, and I was planning to build on it for a project which has been delayed. If you look into, I'd be interested in hearing your opinion as well.
    1 point
  3. Oh! I got it, thanks a lot. Actually I know about I/O node, but I didnt realise that I should manually add these triggers to the IO(thinking about FIFOs ,registers),now I can receive these triggers and try synchronizing my cards.
    1 point
  4. they're called hash marks and indicate where LabVIEW compiler will optimize and fold it into constant code. you hide these by changing your LabVIEW settings in the 'block diagram' page see online help : https://www.ni.com/docs/en-US/bundle/labview/page/block-diagram-objects.html bonus link : https://forums.ni.com/t5/The-Daily-CLAD/LabVIEW-Compiler-Optimizations/ba-p/3482600
    1 point
  5. As far as I know, a .NET dll in LV is loaded on the 1st call to one of its functions, usually a constructor.
    1 point
  6. 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
  7. for what it is worth, we do this... I have a shallow-ish hierachacy somthing like ths: actor <-- device <-- type_of_device <-- concrete_implementation We have some scipting code to help us make a new instance of type_of_device <-- concrete_implementation I have a template with the last two in a .lvlib, and we clone them as needed to two brand new classes. To further complicate, our stuff is in PPLs.
    1 point
  8. Hi Richard, I was referring to the Save a Copy on a LVLIB that contains classes A and A1, instead of saving individual classes sequentially. You'd start with Template.lvlib:A.lvclass * Template.lvlib:A1.lvclass, and end up with Clone.lvlib:A.lvclass & Clone.lvlib:A1.lvclass Your new clone lvlib will maintain the linkage within its own namespace. It then becomes a renaming operation for the Clone.lvlib:AX.lvclass to Clone.lvlib:BX.lvclass This only work if your template has all dependent classes in the same lvlib, hence why I called that a "special case". Your solution is more generic. Even when I don't want the classes to end up in the same lvlib, I prefer to extract them after they have been cloned...
    1 point
  9. The multiple patterns nugget was broken in LabVIEW 2023 Q1, but it works in LabVIEW 2023 Q3 and later.
    1 point
  10. I emailed the site admin to see if there is something broken. Welcome back.
    1 point
  11. 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
  12. 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
  13. 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
  14. 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
  15. 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
  16. 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
  17. 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
  18. 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
  19. 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
  20. 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
  21. Version 1.0.0

    406 downloads

    There it is. The complete library for the MCP2221A. I2c adapter, I/O in a single IC. I love that one. Let me know if any bug is found. I try to make that library as much convenient as possible to use. Two version available 32 bit and 64 bit. little note: to open by serial number, the enumeration need to be activated on the device first. (open by index, enable the enumeration) It needs to be done only once in the life time of the device. PLEASE do not take ownership of this work since it is not yours. You have it for free, but the credit is still mine... I spent many hours of my life to make it works.
    1 point
  22. 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
  23. Ok, this is really weird. Yes it is. And I never set that. But what is really strange is it is grayed out and I cannot figure out why or how to unselect it. ------------------------------------- Ok, sorted it out. If you accidentally select "Top level application window" and then customize it, you will get the the "Show front panel when loaded" checked and grayed out. If you instead select "Dialog" or "Default" first and then customize, you will get the "Show front panel when loaded" unchecked but still grayed out. Seems like there is no option that lets you control this manually. That could be a bug. I don't recall this being always grayed out in the past. As for the 66 VI that always want to be saved, that looks like an unrelated problem with this project.
    1 point
×
×
  • Create New...

Important Information

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