Jump to content

Leaderboard


Popular Content

Showing content with the highest reputation since 04/05/2019 in all areas

  1. 9 points
    So I wasn't there but there was a public announcement at GDevCon about a new edition of LabVIEW called Community Edition which is the LabVIEW Professional version (I read that as application builder included), and completely free with no watermarks for non-commercial use. NI hasn't made any post about timelines, or other details yet but I hear those are in the works. This is obviously a huge thing for LabVIEW as any monetary barrier to entry will discourage new developers from experimenting with LabVIEW. And then there is the fact that those that are familiar with LabVIEW, can keep up with the newest version outside of their company, or when they are between jobs.
  2. 9 points
    Hey folks. this year we're trying something new. All Videos for NIWeek 2019 can be found here: https://labviewwiki.org/wiki/NIWeek_2019 Feedback welcome. Thanks to @Mark Balla and other volunteers for recording the videos. Edit: We're starting to add the back catalog to YouTube. NIWeek 2018 videos are also up.
  3. 7 points
    I've exported the OpenG sources from Sourceforge SVN to Github. It's located here: https://github.com/Open-G I'm hoping this will encourage collaboration and modernization of the OpenG project. Pull requests are a thing with Git, so contributions can be encouraged and actually used instead of dying on the vine.
  4. 7 points
    Greetings Friends of LAVA, colleagues, cohorts, and Wireworkers Extraordinaire -- it's LAVA BBQ time! Date: Tuesday, May 21, 2019 Time: 7:30-10:00 pm Location: Uncle Billy's Brewery and Smokehouse, 1530 Barton Springs Rd, Austin, TX 78704 (1.5 miles from Convention Center) Cost: $25 Early Bird (through April 30th) $30 Regular Admission (through May 20th) $35 Door Price (May 21st) Meal Options: Expect to enjoy your choice of meats (brisket, turkey, ribs) with sides like street corn, cole slaw, and bbq beans. A vegetarian option is available when purchasing tickets. Cash beer bar. Who: Everyone is welcome, including spouses traveling with you. Even if it's your first time, expect to recognize many faces/names from the forums and NI R&D. What to wear: It's a covered, outdoor venue in Austin during Spring, so dress for the weather and comfort. Door Prizes: We will have a drawing to give away prizes. All attendees are eligible and will receive a door prize ticket upon entry. See below about sponsoring a door prize yourself to share the love. Hope to see you there! Chime in once you buy tickets to let everyone know you're coming. ------------>>------------>> Get LAVA BBQ 2019 Tickets Here <<------------<<------------ The venue is a 30 minute walk from the convention center, or a $6 Uber. Get together and carpool, people are typically gathering at Challenge the Champions in the Expo Hall, which is great fun. There is a free parking garage behind the building. We'd love for you to sponsor a door prize - Continue Reading: If you or your company want to sponsor a LAVA BBQ door prize, please post a reply below. You can also include a small blurb about your company and a link to your website in the post below. By donating a prize you and your company will receive a small announcement of your choosing, during the event. We will ask you to write the announcement on a post-it note and will attach it to the prize to be read before awarding it. We love the door prizes, but we love time for socializing too. Here are some guidelines to keep our event balanced and streamlined. Single item donations work best. If donating more than one item, then multiple identical items is strongly preferred. If donating non-tangible items or something that is not physically with you, then please bring a card with your contact info and instructions on how to collect the prize. This will be given to the winner. Donations are typically $25-$200 in value. Not recommended: Apparel (hats, t-shirts, underwear, etc.) - never the right size Software licenses (Toolkits, add-ons, LabVIEW) Branded trade show booth type giveaways (mouse pads, pens, keychains, etc.) Jokes or something meant as a gag and not a real prize
  5. 7 points
    We'll grow into it eventually ๐Ÿ˜‹
  6. 6 points
    The New Data Value Ref and Delete Data Value Ref nodes will be able to be in inline VIs (and thus malleable VIs) in LV 2020.
  7. 6 points
    View File Hooovahh's Tremendous TDMS Toolkit This toolkit combines a variety of TDMS functions and tools into a single package. The initial release has a variety of features: - Classes for Circular, Periodic, Size, and Time of Day TDMS generation with examples of using each - Reading and Writing Clusters into TDMS Channels - XLSX Conversion example - File operations for combining files, renaming, moving, and saving in memory to zip - Basic function for splitting TDMS file into segments (useful for corrupt files) - Reorder TDMS Channel with Demo There is plenty of room for improvements but I wanted to get this out there and gauge interests. The variety of classes for doing things, along with VIMs, and class adaptation makes for using them easier. If I get time I plan on making some blog posts explaining some of the benefits of TDMS, along with best practices. Submitter hooovahh Submitted 12/12/2019 Category *Uncertified* LabVIEW Version 2018 License Type BSD (Most common)  
  8. 6 points
    All of the presentations are now on the LabVIEW Wiki. You can find them at: https://labviewwiki.org/wiki/Americas_CLA_Summit_2019 Thanks Kevin Shirey and Mark Balla for producing the videos and all those that volunteered to run the cameras. This is an awesome resource to be able to go re-watch and review these great presentations again or for those that couldn't join us in person to be able to view them as well.
  9. 6 points
    @Jim Kring, it seems to me that the export of the code has gotten a positive response from the community. However I may be wrong. If anyone has any opinion either way, please come forward. As you can see in this thread, it appears the community has rallied around this effort. This is why I emailed you to come here and share your thoughts. In the past, OpenG was a great venue to showcase how a bunch of passionate LabVIEW users can come together and collaborate on something useful. The passion is clearly still there, as shown by the numerous discussions here. The general coding community has moved to Git with GiHub being the hub. This seems like the logical next step. Who knows what this initiative will lead to. However, Iโ€™m expecting that placing OpenG in a neutral GitHub repo will provide the spark and the tools to facilitate open collaboration, then the community can drive the future. The community is full of smart people who have a desire for clean tested code. And if issues come up, LAVA discussions (or GitHub issues) are there to hash things out. When LAVA offered to host all OpenG discussions back in 2011. it was clear that the community wanted to help. When @jgcode put his standards together for how code should be discussed at that time, It was an exciting time. Since then, many people have come forward with offers to add new code into OpenG and fix bugs. For example @drjdpowell first offered to include his awesome SQLite toolkit for inclusion into OpenG. He got no response either way. Itโ€™s a shame to have a platform and forums to allow people to post and discuss OpenG code and then ignore it. If you have ideas on what the future of OpenG is. Iโ€™m hoping itโ€™s to be more transparent and inclusive. Providing the tools, resources and some safety checks along the way, is the best way to facilitate passionate individuals to dive in. Do you think keeping the status quo of the past 10 years makes sense? It seems to me that the community disagrees. What do you think?
  10. 6 points
    You people are so laid back and forgiving. Iโ€™m an editor on multiple wikis across cyberspace, and none of the others are anything less than draconian. Capitalization whatever?! Wow. Iโ€™m going to need to wear my oversized Hawaiian shirt and cargo shorts when Iโ€™m editing, just to get in the right state of mind! ๐Ÿ™‚
  11. 5 points
    Found a fix for this. It should be fixed in LV 2020. The bug ONLY affects copying from a 1-element cluster of variant to a variant. Or a cluster of cluster of variant to a variant. Or... you get the idea... "any number of cluster-shells all containing 1 element, culminating in a variant" being copied to a variant. This was a fun bug... consider this: The memory layout for an byte-size integer is { 8 bits } The memory layout for a cluster of 1 byte-size integer is { 8 bits } They are identical. "Cluster" doesn't add any bits to the data. That's just the type descriptor for the data in that location. This is true for any 1-element cluster: the memory layout of the cluster is the same as the memory layout for the element by itself. This is true even if the 1 element is a complex type such as a nested cluster of many elements or an array. When a VI is compiling, if data needs to copy (say, when a wire forks), LabVIEW generates a copy procedure in assembly code. For trivial types such as integers, the copy is just a MOV instruction in assembly code. But for compound types, we may need to generate a whole block of code. At some point, the complexity is such that we would rather generate the copy procedure once and have the wire fork call that procedure. We want to generate as few of those as we have to -- keeps the code segment small, which minimizes page faults, among other advantages. We also generate copy procedures for compound coercions (like copying a cluster of 5 doubles into a cluster of 5 integers). Given all that, LabVIEW has some code that says, "I assume that type propagation has done its job and is only asking me to generate valid copy procs. So if I am asked to copy X to Y, I will remove all the 1-element shells from X and all the 1-element shells from Y, and then I will check to see if I have an existing copy proc." Nowhere in LabVIEW will we ever allow you to wire a 1-element cluster of an int32 directly to an int32. So the generator code never gets that case. In fact, the only time that we allow a 1-element cluster of X to coerce directly to X is... variant. The bug was that we were asking for a copy proc for this coercion, and the code was saying, "Oh, I have one of those already... just re-use copy-variant-to-variant." That will never crash, but it is also definitely not the right result! We had to add a check to handle variant special because variant can eat all the other types. So if the destination is variant, we have to be more precise about the copy proc re-use. I thought this was a neat corner case.
  12. 5 points
    At the 2019 Americas Certified LabVIEW Architect Summit, GCentral was introduced to the LabVIEW Community. GCentral is a non profit organization (incorporated September 2019) composed of G community leaders creating a platform for programmers to find/use, contribute, and co-develop G code packages and collaboration resources. While GCentral is leading the charge to solve these problems, we will closely align with the community's needs. This forum is designed to connect GCentral's efforts with the community's needs. Some links to be aware of: GCentral.org LabVIEW Wiki Twitter (@GCentralOrg) LinkedIn Instagram (gcentralorg) Facebook Website GitHub Repo
  13. 4 points
    The main difference between LabVIEW and a C compiled file is that the compiled code of each VI is contained in that VI and then the LabVIEW Runtime links together these code junks when it loads the VIs. In C the code junks are per C source file, put into object files, and all those object files are then linked together when building the final LIB, DLL or EXE. Such an executable image still has relocation tables that the loader will have to adjust when the code is loaded into a different memory address than what its prefered memory address was defined to be at link time. But that is a pretty simple step. The LabVIEW runtime linker has to do a bit more of work, that the linker part of the C compiler has mostly already done. For the rest the LabVIEW execution of code is much more like a C compiled executable than any Virtual Machine language like Java or .Net's IL bytecode, as the compiled code in the VIs is fully native machine code. Also the bytecode is by nature address independent defined while machine code while possible to use location independent addresses, usually has some absolute addresses in there. It's very easy to jump to conclusions from looking at a bit of assembly code in the LabVIEW runtime engine but that does not usually mean that those conclusions are correct. In this case the code junks in each VI are real compiled machine code directly targetted for the CPU. In the past this was done through a proprietary compiler engine that created in several stages the final machine code. It already included the seperation where the diagram was first translated into a directed graph that then was optimized in several steps and the final result was then put through a target specific compiler stage that created the actual machine code. This was however done in such a way that it wasn't to easy to switch the target specific compiler stage on the fly initially so that cross compiling wasn't very easy to add when they developed the Real-Time addition to LabVIEW. They eventually improved that with an unified API to the compiler stages so that they could be switched on the fly to allow cross compilation for the real-time targets which eventually appeared in LabVIEW 7. LabVIEW 2009 finally introduced the DFIR (Dataflow Intermediate Representation) by formalizing the directed graph representation further so that more optimizations could be performed on it and it could eventually be used for LabVIEW 2010 as an input to the LLVM (Low-Level Virtual Machine) compiler infrastructure. While this would theoreticaly allow to leave the code in an intermediate language form that only is evaluated on the actual target at runtime, this is not what NI choose to do in LabVIEW for several reason. The LLVM creates fully compiled machine code for the target which is then stored (in the VI for a build executable or if code seperation is not enabled, otherwise in the compile cache). When you load a VI hierarchy into memory all the code junks for each VI are loaded into memory and based on linker information created at compile time and also stored in the VI, the linker in the LabVIEW runtime makes several modifications to the code junk to make it executable at the location it is loaded and calling into the correct other code junks that each VI consists of. This is indeed a bit more than what the PE loader in Windows needs to do when loading an EXE or DLL, but it isn't really very much different. The only real difference is that the linking of the COFF object modules into one bigger image has already been done by the C compiler when compiling the executable image and that LabVIEW isn't really using COFF or OMF to store its executables as it does all the loading and linking of the compiled code itself and doesn't need to rely on an OS specific binary image loader.
  14. 4 points
    I found this tonight while working on a project: https://remixicon.com/ Really good icon library with modern-looking icons where you can customize the color and size of the icons, then download them as PNG files. I then import them into a LabVIEW pict ring and it's off to the races.
  15. 4 points
    It is not a bug. It should break for any unsigned integers because that's how the "negate" method works.
  16. 4 points
    I'm working on a personal project (more information will be shared about this later) that needs Message Queue Telemetry Transport (MQTT). While searching for LabVIEW libraries for MQTT I found 1 on VIPM, 2 in the NI Forums, and 1 through Goggle on GitHub, as follows: WireQueue-MQTT Driver for LabVIEW by WireFlow AB (this one costs $550) MQTT Client API in native LabVIEW by Peter - daq.io (also on GitHub as LVMQTT) MQTT-LabVIEW by Michal Radziwon Quaxo MQTT LabVIEW by Stefan May This is not unusual for just about anything you might be looking for. In fact searching on GitHub there are 13 results for LabVIEW+MQTT. What was weird is that two of them were almost completely the same, yet neither attribute the other. I don't know which came first. I ended up forking from one of them but I guess I'll attribute both to be safe if I end up using it. However, talking about code confidence, I just found this one: LV-MQTT-Broker by @Francois Normandin. I know Francois, he is a LabVIEW Champion. He has included unit tests. It has full documentation as well as an NIWeek presentation by him and Sarah Zalusky, both of whom are Certified LabVIEW Architects (CLAs). From GitHub I can see he has been actively contributing to it and its open source (which most of them were). Honestly, I wish I had found this one first. Just some words for thought...
  17. 4 points
    Here you go. Set Icon.vi Use it like this: To get back to the original icon just call it with an empty path.
  18. 4 points
  19. 4 points
    I assume you meant this video? There is this older video of Dr. T and Jeff K. introducing a LabVIEW Basics Interactive CD-ROM (~LabVIEW 4), but it's not as exciting as the LabVIEW 5 promo.
  20. 4 points
    Add SuperSecretListboxStuff=True to your labview.ini , reload LabVIEW new menu items will show up when you right click on MLC control. Read this thread
  21. 4 points
    As someone contributing code on LAVA, I would like to see the certified LAVA repository packages made available through the GCentral package search tool.
  22. 4 points
    As a company that uses LabVIEW and has it's own existing internal repository for reuse code, I would like a way for my developers to discover packages in G Central and in our private reuse repository, all from a single portal.
  23. 4 points
    You can extract the labels from the type descriptor, once you know where to find them in the array. I added support for it in this open source DataManipulation library. Check out the OpenDescriptor palette. You can install the latest release (1.1.0.5) from here: https://github.com/LabVIEW-Open-Source/DataManipulation/releases/tag/1.1.0.5 (download VIP file and install with VIPM). Once installed, you'll find the "List Element Names" method under Addons>DataManipulation>OpenDescriptor palette. (It can list enums and cluster elements as well, although those are natively supported under the Variant Utilities palette.)
  24. 4 points
  25. 3 points
    MAX That is all.
  26. 3 points
    [Update: NI Bug 974336] There seems to be a bug in the coercion of data to variant when a cluster contains a single element that is a variant. (original post here). Note: This bug appears to be very old, going as far back as LV2012. This has been reported to NI in the LV2020 Beta forum. I don't have a Bug ID / CAR yet. Coerce to Variant Fail (LV2019).vi Note that adding another element to the outer cluster causes the problem to go away.
  27. 3 points
    @The Q My library is not complete by any means, but what works really works... I've followed a TDD approach. So far I've covered only 79 requirements out of 141, and I haven't started any branches to support MQTT 5.0 yet... So it covers the basic needs such as shown in the presentation you're referring to, but nothing fancy like QoS 1 and 2 and the likes. (or TLS for that matter). If you want something more complete, I'd check Wireflow's implementation first. Now, I'd really like to get other folks to contribute to my Open Source Project. It would give me a moral boost to continue pushing it further. In the meantime, thanks for the advertisement!!!
  28. 3 points
    No Classic LabVIEW doesn't and it never will. It assumes a string to be in whatever encoding the current user session has. That's for most LabVIEW installations out there codepage 1252 (over 90% of LabVIEW installations run on Windows and most of them on Western Windows installations). When LabVIEW classic was developed (around end of the 80ies of the last century codepages was the best thing out there that could be used for different installations and Unicode didn't even exist. The first Unicode proposal is from 1988 and proposed a 16 bit Unicode alphabet. Microsoft was in fact an early adaptor and implemented it for its Windows NT system as 16 bit encoding based on this standard. Only in 1996 was Unicode 2.0 released which extended the Unicode character space to 21 bits. LabVIEW does support so called multibyte character encodings as used for many Asian codepages and on systems like Linux where nowadays UTF-8 (in principle also simply a multibyte encoding) is the standard user encoding it supports that too as this is transparent in the underlaying C runtime. Windows doesn't let you set your ANSI codepage to UTF-8 however, otherwise LabVIEW would use that too (although I would expect that there could be some artefacts somewhere from assumptions LabVIEW does when calling certain Windows APIs that might not match how Microsoft would have implemented the UTF-8 emulation for its ANSI codepage. By the time the Unicode standard was mature and the various implementations on the different platforms were more or less working LabVIEW's 8-bit character encoding based on the standard encoding was so deeply engrained that full support for Unicode had turned into a major project of its own. There were several internal projects to work towards that which eventually turned into a normally hidden Unicode feature that can be turned on through an INI token. The big problem with that was that the necessary changes touched just about every code in LabVIEW somehow and hence this Unicode feature is not always producing consistent results for every code path. Also there are many unsolved issues where the internal LabVIEW strings need to connect to external interfaces. Most instruments for instance won't understand UTF-8 in any way although that problem is one of the smaller ones as the used character set is usually strictly limited to ASCII 7-bit and there the UTF-8 standard is basically byte for byte compatible. So you can dig up the INI key and turn Unicode in LabVIEW on. It will give extra properties for all control elements to set them to use Unicode text interpretation for almost all text (sub)elements instead but the support doesn't for instance extend to paths and many other internal facilities unless the underlaying encoding is already set to UTF-8. Also strings in VIs while stored as UTF-8 are not flagged as such as non Unicode enabled LabVIEW versions couldn't read them, creating the same problem you have with VIs stored on a non Western codepage system and then trying to read them on a system with a different encoding. If Unicode support is an important feature for you, you will want to start to use LabVIEW NXG. And exactly because of the existence of LabVIEW NXG there will be no effort put in LabVIEW Classic to improve its Unicode support. To make it really work you would have to rewrite large parts of the LabVIEW code base substantially and that is exactly what one of the tasks for LabVIEW NXG was about.
  29. 3 points
    I am very excited about the potential for a platform that encourages opensource collaboration on LabVIEW code. My main experience of non LabVIEW package managers is with NPM for Node.js. NPM is an organisation which provides two things - a tool which is the mechanism for managing what packages are used in a project and a registry that allows for anyone to publish their packages to. I believe that NPM supports private packages for enterprise customers but open source packages are generally hosted on github and when a package is uploaded to the NPM registry it simply pulls in the README to provide the package documentation. The github link is also provided on the NPM page so that users can easily see where the library comes from and if they want to open issues or submit fixes then they do that on github. I have not had much of a chance to look at it but it appears like GPM would/does follow similar mechanics to NPM and compared to VIPM and NIPM I am certainly most excited about the GPM model. I see GCentral as a organisation that could provide the registry for packages and ideally be the one place for opensource LabVIEW code (including NI-community page hosted code) with clear signposts as to where to find the source for issue raising and forking. One issue that many text based languages don't have is that users with older versions of labVIEW cannot even open code made with newer versions of LabVIEW, let alone run it - so maybe GCentral could provide some computing power (and licences) to automatically convert VIs to older versions - even if they didn't run, at least a user could open them.
  30. 3 points
  31. 3 points
    Due to bitbucket discontinuing support for Mercurial in 2020, I have migrated the source code to Github. From now on, if there is any development on this project, it will be in the LabVIEW Open Source project: https://github.com/LabVIEW-Open-Source/ui-tools You can use both LAVAG or Github's issue tracking to report any issue you might encounter with this package. (previous repo: https://bitbucket.org/normandinf/ui-tools/)
  32. 3 points
    I already have that superpower I once used lots of letters so that if you read the for loops top to bottom the letters spelt out my name and a message. I also once heard that wether you use "a" or "i" depends on if you came from a mathematical or engineering background. What's really stange (for me) is in C and PHP; I use "i". But in Pascal, and Python ; I use "a". I know that to a certain extent it is muscle memory since if I use "i" in Pascal, I nearly always leave out the colon before the equal sign. Maybe it's a coping mechanism because I switch between languages so much.
  33. 3 points
    Thought I'd show an example of "complexity" of a framework, according to my way of thinking, by comparing the priority messages of the NI Actor Framework and the DQMH: Looks the same from an API level (they even use similar icons). Let's look inside; here is the relevant code section for priority messages for the AF: Yikes! And here is the same for DQMH: Ah, much simpler. Now we can see which framework involves more complexity: the DQMH. Wait, what, you say? Isn't the obvious complexity of the AF implementation mean the AF involves more complexity? Well, no, because I, as User of a framework, care nothing about the implementation, I care about application I am building with these APIs. So let's consider the task of sending three high-priority messages, A then B then C. In what order will the three messages be received and acted on? With the Actor Framework the order will be A, then B, then C, ABC, always. With the DQMH we have: 1) if the receiver can execute them faster than they are sent, the order will be ABC 2) if the receiver is handling another message the order will be CBA (as we place on the front of the queue) 3) if the receiver is idle, but executing A takes time (allowing C to get before B), the order will be ACB 4) if busy but finishes after B is sent but before C is sent, the order is BCA 5) as (4) but B is finished executing before C sent, ther order is BAC Thus with the DQMH there are 5 possible orderings of execution, with the probability of the various orderings highly dependant on timing of not-directly-related bits of code (other messages being sent). At best, this is counter-intuitive and potentially confusing during debugging. At worst, one combination is a rare race condition that doesn't show up during testing and causes near-impossible-to-debug errors in deployed code. So that is an example of complexity, and it is certainly accidental, as the DQMH designers did not intend unpredictability of message-handling order when they used enque-in-front as message "priority".
  34. 3 points
    As a developer working on multiple machines, I'd like to be able to save a (personal) configuration file of "IDE-improvement" style packages to install on every machine.
  35. 3 points
    It is good to finally see some movement in OpenG. Git and GitHub are also the right choices (Bitbucket would probably also work). Even novice programmers will be able to participate this way. ๐Ÿ‘ That said, the current repository has a few problems: No tags No branches All projects in one repository Changed commit messages (the links in the commit messages are non-functional) It is possible to transform an SVN repository into a Git repository while maintaining all tags and branches and updating the committers (because Git uses email addresses and SVN doesn't). Here are some instructions I used in the past for such jobs (instructions are for Linux of course): https://epicserve-docs.readthedocs.io/en/latest/git/svn_to_git.html For OpenG this process is a bit more complex because of the way the repository is structured (i.e. tags inside folders for each project), so the scripts must be adjusted to take this into account. I also suggest splitting the project into multiple repositories during this process to improve maintainability (unless there is a reason why it needs to be one repository). I could prepare the scripts to automate this process if you are interested.
  36. 3 points
    As a package consumer I would like to be able to subscribe to packages so that I get notified when a new version is available.
  37. 3 points
    We use a variety of frameworks/templates/patterns for our architecture: The Actor Framework is used for asynchronous UI operations and long-running data processing tasks. Queued Message Handlers (not using DQMH or QMH template) handle simple asynchronous tasks. Action Engines encapsulate privately shared data for our translation and general I/O libraries. (Queued) State Machines ensure that everything runs in order. The proxy pattern is used to interface most customer libraries. We have our own frameworks for the test execution engine and test libraries (message based). I find the publicly available frameworks and templates (DQMH, Messanger Library, NI templates, etc...) very valuable for learning and to get things started quickly. More advanced projects, however, require a deeper understanding of the underlying patterns in order to develop your own architecture (which may or may not utilize these frameworks/templates). In your case these are synonymous ๐Ÿ˜‹ "Any sufficiently advanced technology is indistinguishable from magic." (Arthur C. Clarke) For some reason that just popped into my mind... If your entire architecture and thought process is fundamentally based on actors, any small project will of course have to depend on it as well. That is, unless you are willing to rethink (and probably reimplement) the fundamental architecture. Then again, why reinvent the wheel?
  38. 3 points
    Version 1.2.0.6 released. https://github.com/LabVIEW-Open-Source/DataManipulation/releases/tag/1.2.0.6 Added support to return a list of Event reference types (class of event) for Event Registration Refnums Controls, Panes, Splitters, VI References and Application References. Array is empty for all other datatypes. ** Please note that this does not drill into clusters of Event Registration Refnums. This is only one-level deep. I have not tried, but I assume that getting the cluster elements and then looping on those should work...
  39. 3 points
    My first ever meme prompted from this post
  40. 3 points
    Maps in LabVIEW 2019?
  41. 3 points
    Have the topics been converted to the lava forum with the same topic id? If so, you can just enter the topic-id in the url and add a - with anything behind it https://lavag.org/topic/1524-anything-you-want works just fine
  42. 3 points
    NI is bringing 2 NI myRIO devices for Door Prizes.
  43. 3 points
    am I doing this right?
  44. 2 points
    Did you enable foreign key constraints? You need to set PRAGMA foreign_keys = ON Otherwise foreign key constrains are ignored. https://www.sqlite.org/pragma.html#pr>agma_foreign_keys
  45. 2 points
    I thought this was an interesting exercise so here is my attempt. OpenG has some image tools and one of them is the ability to open a GIF, but for some reason it crapped out and died with your GIF even after resaving it to something much smaller. I did find some other GIF API over on the dark side and instead used that. Attached is a zip, extract it and run Demo Saving Button. It will show the first image. Then when you click the image it cycles through the first half of the GIF and waits for the simulated save process to complete. Once it is complete it rotates through the second half of the images, and then after a few seconds returns back to the first. Parsing of the GIF takes time so I put in the GIF images as a constant, along with the code to parse the GIF. I also set the pane to be the color of the (0,0) pixel in the hopes it will blend in better. Honestly this could be turned into a QControl and be made very seemless. Demo Saving Button Gif.zip
  46. 2 points
    The simplest way is to add "@users.noreply.sourceforge.net" to make them valid addresses that don't collide with any existing GitHub user (GitHub and SF both support these). It should be sufficient for this task. Here is my version: https://gist.github.com/LogMANOriginal/c4109873a5d524387d3fb46f5b83aa0a I agree. From what I can tell the reason it didn't work correctly is because each project has its own branch/tag subfolder. None of the standard systems support these (including git-svn). Find below a solution that can handle them. Done, see below. Sorry, my explanation wasn't very clear. My point is, that the original commit message actually doesn't have these URLs inside (see SF vs. GitHub). It was probably added during the Atlassian conversion process. Here you go: https://gist.github.com/LogMANOriginal/fa1e59703c41e27758bcb935f15bea21 The script must be placed in an empty folder next to 'authors-transform.txt'. It must be marked as executable (runs in bash, not sh). svn and git must be installed of course. Then start the script via './openg_import.sh' and it should work (unless it breaks of course). It does a few things: Lookup all projects, branches and tags Import all projects into dedicated Git repositories Cleanup the Git repository (i.e. tags are imported as branches, so they need to be fixed) The output are 39 bare git repositories, one for each project with full history, branches, tags and commits. Enjoy ๐Ÿ˜‰
  47. 2 points
    The introduction of parallel, read-only access for DVRs in LabVIEW 2017 adds a great deal of flexibility to using DVRs to monitor values in parallel executions of code. Fo\The downside of this, of course, is the necessity of using the In Place Element (IPE) throughout your code simply to read the value. Having IPEs throughout your code just to read a value both takes up block diagram real estate and also takes more clicks than desirable to insert. Similarly, though less frequently, there are times when you only need to update the value within a DVR without actually performing any logic inside of the IPE. This situation is less frequent, at least for me, as I am usually using arrays or classes with DVRs such that I actually need to modify the existing data rather than simply replacing it. A more preferable solution to the above situations would be to have Read/Get and Write/Set VIs for the DVRs to simplify the process of working with them. This way, and IPE on the block diagram would only be needed when you were actually modifying the existing data within the DVR, rather than simply overwriting or returning the current value. Thanks to the power of malleable VIs and the type specialization structure that is now officially released in LabVIEW 2018, a better solution is now available. Iโ€™ve created two malleable VIs, Read DVR Value (Parallel) and Write DVR Value that allow you to perform a write and a parallel read on any DVR data type. Now, you can use a single VI that you can insert via Quick Drop to read or to write DVR values. Download the attached ZIP file to access the two malleable VIs and example code, and please let me know your thoughts in the comments! DVR Read and Write VIs 1.0.0.zip
  48. 2 points
    Screwdrivers are $29.99 though, that's how they get you.
  49. 2 points
    I just post something along the lines of "can't find it right now" and usually someone with better organisation than me finds the link. Damn. giving away all my secrets.
  50. 2 points
    Start with a control in your template. Get a reference to that control and cast it to VIRefNum. Then call the 'Make Strict Reference' method using a VI reference to the desired VI. Finally, get the Terminal reference of the VIRefNum and invoke the method 'Change to Constant'. The constant winds up in a different location, if you are OCD like I am then read the position of the control terminal before and write that position to the constant after. It is pretty common to have more scripting versatility with a control or indicator than the corresponding constant.


×
×
  • Create New...

Important Information

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