Jump to content

Leaderboard


Popular Content

Showing content with the highest reputation since 01/23/2014 in all areas

  1. 20 points
    After I made this post I decided to bring the LabVIEW Wiki back online. It was not easy and took several days of server upgrades and hacking. The good news is I was able to bring up all the original pages.. The even better news is I talked with @The Q and @hooovahh and we are all on the same page as to how to move forward. @The Q did a great job of stepping forward and trying to fill the void that the LabVIEW Wiki's absence had left. He's agreed to migrate all the new content he created over to the LabVIEW Wiki, from Fandom and continue to develop new articles and content moving forward on the new site. He will also help in moderating the Wiki and will be promoted to Admin rights on the Wiki. His help is much appreciated. The LabVIEW landing page created here on LAVA is awesome but the forums don't lend themselves to static content creation. Instead @hooovahh has agreed to move the old landing page to here. That will be the new home for the landing page. This will become a valuable resource for the community and I hope all of you start pointing new people in that direction. With many editors, it can only get better and better over time. Where do we go from here: Logging in. - The old accounts are still there. If you're a LAVA old-timer, then you can try to login using your LAVA username. If the password doesn't work then reset it. You can also create a new account here. I'm going to announce a day when new accounts can be created. I'm limiting it for now because of all the spam accounts that can be potentially created. There's an issue with the current Captcha system. if you are super-eager to start creating content now and want to help, send me a direct message on LAVA and I can manually create an account right away. - New account creation is now open. Permitted content: - I'm not going to put restrictions on content at the moment. Obvious vandalism or offensive\illegal content will not be tolerated of course. However, the guidelines will be adjusted as time goes on and new content is created. There's just not enough content right now to be overly concerned about this. We need content. Discussions about the Wiki. - Each article page has an associated discussions page where you can discuss issues related to that article. Please use that mechanism (same etiquette as wikipedia). General Wiki issues\questions and high level discussions can be done here. So now, if you need to add content, you can do it yourself. Feedback as always is welcome.
  2. 16 points
    The content on this page will go away soon. It's currently being migrated. > New Location < Read about the wiki here This thread is intended to be a place for all things LabVIEW to be able to be found. If you have a resource for LabVIEW feel free to reply with your own content. We are interested in things like person blogs, forums, training information, and anything a user of LabVIEW might want. Several links and sections have been lifted from another resource available over on NI labeled the Content and Communities for LabVIEW Application Development. I'm New To LabVIEW and Need Help Basic Training Information NI Learning Center NI Getting Started -Hardware Basics -MyRIO Project Essentials Guide (lots of good simple circuits with links to youtube demonstrations) -LabVEW Basics -DAQ Application Tutorials -cRIO Developer's Guide Learn NI Training Resource Videos 3 Hour LabVIEW Introduction (Alternate Google Drive) 6 Hour LabVIEW Introduction (Google Drive) Self Paced training for students Self Paced training beginner to advanced, SSP Required Rookie Mistakes in LabVIEW by Digilent State Machine Design Pattern Basic Tutorial Wikipedia Article Sixclear Video Event Driven Design by NI Beyond Basic Training These are topics that are useful but not for those new to LabVIEW or software development. Topics may cover things a novice may have a hard time following. Object Oriented Software Design NI FAQ on Object Oriented Programming Creating Classes When Should you Use Classes Abstraction Abstraction Distraction Introduction to Object Oriented Programming and HAL by Elijah Kerry (Video), Plugin Framework JKI Hardware Abstraction Video Actor Framework Community Introduction Framework Basics Error Handling Basics by NI David Maidman’s Blog Post SOLID Error Handling by Dmitry Structured Error Handler Express VI by NI I Have Questions LAVA Forums - Independent community, with less NI oversight, and generally less new users asking basic questions NI Official Forums - NI's official forum, monitored semi-regularly by NI and the best place to find official support LabVIEW on Reddit - Smaller community but has Reddit features like voting on posts and comments causing interesting topics to get more attention LabVIEW on Stack Overflow - Q&A style community I'm Looking to Find Example Code and Toolkits NI Tools Network - Polished released code distributed as VIPM packages. LAVA Code Repository - Place for Verified, and Unverified code allowing for discussions, in addition to hosting NI Code Exchange / Community Documents - Similar to LAVA but NI's site licensing means less flexibility if you are posting code and want a custom license. NI Reference Designs Portal GitHub - Trending LabVIEW Projects, and All LabVIEW Projects GitLab - LabVIEW Projects BitBucket - LAVA Projects on BitBucket I'm Looking for Blogs There are lots of LabVIEW blogs, covering lots of topics. Some blogs go cold after some time, so below is a table of blogs, highlighting the last post made. At the moment this is updated manually so this will need to be updated periodically. NI's Blog NI's official blog, updated very frequently System Automation Solutions 10/24/2018 Sam Taggart's Blog JKI Blog 9/13/2018 Blog often highlighting JKI's activity including VIPM and other LabVIEW tips DMC Blog - 9/10/2018 LabVIEW category of DMC's official blog Steve Watts Random Ramblings on LabVIEW Design - 10/23/2018 Random Ramblings says it all but often good insight into designs and discussions we don't think about but should question why we use them and how Delacor Blog - 9/4/2018 The Daily CLAD - 9/4/2018 Hooovahh's Blog - 8/24/2018 Brian Hoover's blog focusing on LabVIEW and CAN The LabVIEW Lab - 10/22/2018 Eric Maussion's blog Bloomy's Blog - 8/13/2018 LabVIEW category of Bloomy's official blog Ajay Blog - 10/10/2018 Ajayvignesh's LabVIEW blog Wiresmith - 9/25/2018 James McNally's Blog LabVIEW Craftsmen - 7/3/2018 Wineman Technology Blog - 10/10/2018 LabVIEW category of Wineman's official blog MGI Blog - 6/5/2018 Moore Good Ideas blog Eyes on VIs - 5/25/2018 Christina Rogers blog often focusing on LabVIEW's visual design UI's and UX's QControls - 5/15/2018 Blog series on QControls, and open alternative to XControls Walking The Wires - 5/11/2018 Chirs Roebuck's Blog Not a Tame Lion - 5/5/2016 LabVIEW Artisan - 2/5/2015 Darren Nattinger's LabVIEW blog often highlighting lesser known features of LabVIEW Culverson Software's Blog - 9/20/2014 LabVIEW category of Steve Bird's Blog VI Shots - 7/31/2014 LabVIEW video podcast by Michael Aivaliotis Brian Powell - 12/26/2013 I'm Looking for Videos Similar to blogs, video channels can be hit or miss, and content can become dated. But if you are more of a visual learner these channels offer a chance to learn by watching others. NI Week & CLA Conference - Username: LabVIEW_Videos, Password: LabVIEW GDevCon Conference LabVIEW Architects Forum Delacor's Channel System Automation Solutions LLC Dr. James D Powell NI's LabVIEW Channel LabVIEW ADVANTAGE LabVIEW MakerHub Looking For Certification Help Certification Nugget: CLAD - Certified LabVIEW Associate Developer Certification Nugget: CLD - Certified LabVIEW Developer Certification Nugget: CLA - Certified LabVIEW Architect Connecting With Other LabVIEW Developers User Groups Online communities are a great way to connect and contribute. In addition to online there are Local LabVIEW User Groups which meet regularly to present and understand LabVIEW and NI topics. Find one close you you and subscribe or monitor topics. NI often supports local user groups, but they are in most cases ran and organized by the community. NI Week NI Week is another great way to connect with and learn. Hosted in Austin Texas once a year it is a week long conference with training, discussions, keynotes and other activities. Many previous NI Week videos can be found online but no single source is available which aggregates all marketing, keynotes, and technical sessions in one location. The best resource for content is a site setup for video hosting done by Mark Balla over the years. Summits If you hold a CLA or CLD there are specific summits for you that are free. These are often tailored presentations for a specific skill set with the focus on technical discussion and problem solving. There are two CLA summits, one in Austin Texas, and one in Europe both held once a year. CLD summits happen more frequently and locations change from year to year. Consult their specific discussion forums on NI to see when the next one is. Just like NI Week Mark Balla has several videos available here. Needing Professional Help If a project is getting out of hand and is beyond the skill level of your team, NI suggests looking at one of their Alliance Partners. Contact one in your area, and they will help try to best guide you on your project. I Want To Contribute to the Community Developing Code For Others Arguably the most difficult thing about sharing code, and reusing code, is the mind set and considerations associated with other developers using software you wrote. It is a type of mental exercise where you need to put yourself in the mind of the developer using your software. NI's Reference Deign Portal is a good resource for understanding various coding structures, and best practices for designing code for others, and can help with standardizing code for other developers. TBD (Expect this to be a section on various forums, and code repositories that can be added to along with helping out local user groups, and presenting at NI Week and Summits) Other Important Software Topics Source Code Control (SCC) Recommended SCC for LabVIEW Software Configuration by NI Code Management at Center of Excellence VisualSVN - Free SVN Server Software Delacor Blog with SCC Category -SVN Setup for LabVIEW By Delacor (Video) -Git Setup for LabVIEW By Delacor (Video) SOLID Principals Agile Software Development Principles, Patterns, and Practices (book) How Applying Agile Object-Oriented Design Principles Changes Designs and Code by Dmitry SMoReS development Unit Testing NI Unit Test Group VI Analyzer (Automated Code Inspection) The VI Analyzer is a tool by NI that is included with some versions of LabVIEW and allows for automated inspection of LabVIEW software, to check for various conformity or nonconformity to software practices. The VI Analyzer comes with many useful code checking steps but others can be added. Checkout the VI Analyzer Enthusiasts for more community made tests. LabVIEW Style Checklist Center Of Excellence - Learning VI Analyzer LabVIEW Style Guide Rules to Wire By Part 1 Rules to Wire By Part 2 Virtual Machine Usage TBD
  3. 16 points
    Please see the above link to download the videos The NIWeek 2016 Videos are uploaded to the ftp server. Please see this link for information on downloading the videos. https://lavag.org/topic/19154-ni-week-2015-videos/#comment-115444
  4. 13 points
    The NIWeek 2015, 2016, 2017 Videos are compressed and ready for down load from Tecnova's ftp server I would strongly recommend using an ftp client to transfer them to your computer. A web browser may work but if you want to download multiple videos the ftp client makes things much easier. My ftp client of choice is FileZilla and it is free. FileZilla can be downloaded at http://filezilla-project.org/ If you are unfamiliar with FileZilla there is a youtube tutorial video found ftp://frc.tecnova.com login: LabVIEW_Videos pw: LabVIEW login and password is case sensitive. if you are using Filezilla your site manager window will look like this. Please Let me know if you find any issues with the videos
  5. 13 points
    LLBs and LVLibs solve different problems (and create different problems), and are not interchangeable or really related beyond sharing the word "library" in their acronyms. Here are some characteristics and comparisons of the two: LLB provides physical packaging containment of members, and does not address namespacing (nor scoping). LVLIB provides namespace containment of members (and also scoping), and does not address physical packaging. Both LLB and LVLIB impose static linkages that can be incidental and undesirable. These negatively affect load times (IDE and run-time), build times, and compile times. Anecdotally, it's greater than O(n) time complexity, especially when circular linkages exist between multiple such hierarchies, and most especially if the library hierarchy is nested (e.g., LVCLASS within an LVLIB, or nested LVLIBs) An LVLIB can be built into an LVLIBP. An LVLIBP is different from an LLB in that an LLB packs writeable, cross-platform* VIs capable of mutating to future LabVIEW versions, while an LVLIBP is a read-only, platform- and version-specific byte code distributable (which may contain the block diagram for debugging, except still remaining platform- and version-specific). An LLB may be used to pack libraries/plugins for deployment as application plugins, or as reusable libraries in development. An LVLIBP effectively is only used for the former. Neither LVLIBP nor LLB can pack non-LabVIEW-source filetypes as resources. Be mindful to account for both renaming/name-mangling resources, and also changes in relative path. LVLIBs (and LVLIBPs) render nicely in the LVProj tree, while LLB members appear indistinguishable from POVIs (plain ol' VIs). LLBs cannot pack two VIs of the same filename. This prevents packaging multiple LVCLASS hierarchies that use dynamic dispatch methods. This represents a few LabVIEW design limitations: 1) LLB's lack of an internal directory hierarchy for organization and packing of two filenames, and 2) LVCLASS using OS filename as the only unique identifier for method identification in a class (filename represents a good default value, but we need one more degree of indirection as a field within the LVClass XML; it's another discussion why this is so highly desirable to decouple source from OS convention). For actively-developed libraries, LLBs are bad because they exist a monolithic binary file. LVLIBs are bad because there exists no diffing or merging capabilities (this also applies to LVPROJ, LVCLASS, XCTL, XNODE filetypes. This is especially insidious, because popular DVCS clients autodetect the file format as XML and think "Aw yeah dude, I got this!" MERGE FAIL. Corrupted source. Be sure to turn off this autodetection for these filetypes.) LVLIBs can apply icon overlays to members. LVLIBs may be carefully designed to include strategic static linkages, including non-LabVIEW source files. This is one strategy to avoid managing the "Always Include" section of AppBuilder for distributables, especially as a convenience for end-user-developers of re-use libraries. But this fails by default because of the setting "Remove unused members of project libraries". Unchecking that often causes failure to build for non-trivial-sized applications linking to gargantuan LVLIBs shipping in vi.lib and as add-ons. So, the strategy may or may not work (it's coupled to whether or not you're keenly aware of and properly managing all application static dependencies) The reason I want to like LLBs is their ability to provide packaging constructs that provide higher performance on actual hardware. It's faster to load 1 file of size 100 units than 100 files of size 1 unit. It's also a more convenient distribution format -- a single file. (Also, I can't think of another language that effectively enforces a 1:1 relationship between method and physical file. LabVIEW requires substantially more clerical work to develop and refactor, for this reason) The reason I want to like LVLIBs is to enable namespacing and scoping beyond the LVCLASS level. Though, this namespacing always comes with the cost of static linking, which is perhaps the #1 problem for codebases of non-trivial size (do you see busy cursors while editing and wiring? long build times? load times? type prop errors? corruptions from application refactoring? heartache and heartburn generally?) Also, LVLIBP is neat in practice, but so narrowly scoped to specific deployment scenarios where it's acceptable to target version- and platform-specfic targets (version-specificity is definitely the bigger problem. every 12mo, we are afforded the opportunity to choose between obsolecense/migration/revalidation or just-plain-outdatedness). And without arbitrary namespace composition (namespace B and namespace C may both declare using namespace A; with namespace A unaware and none-the-wiser), it's not necessarily a compelling feature to begin with. (Corollary: an LVCLASS's ability to namespace and scope its members is desirable and good; but it becomes less necessary and more-likely-incorrect to continue namespacing and scoping at higher abstraction levels without namespace composition) Do LVLIBs Scale? Using LVLIBs in source on an actively-developed project raises barriers to both team scale and application scale. The cost of not using them is loss of scoping, which is avoided through communication and convention, and easily-detected if any actual problem were to exist. Another cost is loss of namespace, easily avoided through filenaming conventions (which is incidentally an industry standard on the web; prefixing library APIs with library-specific prefixes to avoid collision). Said another way, ROI diminishes and reverses to negative at scale, and opportunity cost has simple workarounds. I choose the opportunity cost. But... LVLIBPs! Another apparent opportunity cost of avoiding LVLIB in source is the inability to have LVLIBP as a distributable. Though, if you treat build/distribution as a second toolchain from the dev toolchain, the dev source can remain unencumbered by LVLIB, which is only added as part of the build process. I have mixed feelings on ROI here, but if LVLIBP makes sense for you, consider this strategy to make your dev experience noticeably more pleasant. Here's a real-world case study. This is from a Wirebird Labs client who gave permission to release this screenshot of a bird's eye view of their application analyzed using Links. What we're looking at in the screenshot below is an application with over 8000 application VIs (not including third-party dependencies). Libraries are identified by labels. Nodes represent a source file (mostly VIs, but also including LVLIB and LVCLASS and CTL), and connections between nodes represent static links as detected by the LabVIEW linker. This is a static screenshot of the application, but while running the physics engine lays out nodes as a force diagram. The strength of the force is based on number of static links existing between nodes, and a negative force is applied to nodes with no static links. This causes nodes to form clusters in space where strong coupling exists. What is the value of analyzing the application like this? Here is a list of issues we needed to solve: It took a long time to build. This made iterating costly, both in time and morale. Oftentimes, the build failed (anecdotally, a fresh warm boot of LabVIEW helped) The IDE was painfully slow during development; the cursor continually was "waiting" during wiring operations. The way we solved both problem was simply by taking a pair of "scissors" and snipping links between nodes. The types of links that we snipped were these incidental links introduced by packaging and namespacing facilities in LabVIEW: removing LVLIBs altogether removing VIs from LLBs calling concrete instances of polymorphic VIs rather than the parent removing public type definitions and utility VIs from LVCLASSes Within a couple days, we went from "kick off a build and go grab lunch" to "kick it off and get a coffee". The application and application framework had not changed to see these improvements; just the logical and physical packaging of dependencies. (In addition to solving the main performance pain points, additional areas for architectural consideration are easily visualized; that's beyond the scope of this conversation) Without LVLIBs, how do I avoid name collisions? I prefer this filenaming convention: Project-Class-Method.vi or Application-Class-Resource-Action.vi ... or generally, LeastSpecificNamespace-...-SpecificThing-...-VerbActingOnASpecificThing.vi For instance, Deploy-UpdateService-CheckForUpdates.vi or FTW-JSON-Deserialize.xnode. The name of the owning class just drops the -Method postfix. Is it ideal? It's neither terrible nor great. Some benefits are that filenames sort nicely, and it's easy to spot anomalous linkages. Semantic naming makes it easier for development tools outside the IDE (SCC client and provider, build toolchains). One downside is that your hand is forced on naming Dynamic Dispatch methods in classes (again, I desire to see this coupling separated by a degree of indirection in future LabVIEW versions). Conclusion? This area of LabVIEW does not have a general solution or general best practice. Be aware of tradeoffs of different strategies, and ensure they map successfully to your application space, stakeholder's needs, and team's sanity. Standing offer: Send me a message if you feel some of the scaling pain points: busy cursor while wiring build times lasting longer than 10min mass compile times lasting longer than 10min LVProj takes longer than 1min to load and within 2hrs of screensharing I reckon we could substantially improve your LV dev experience. I'm interested to further build tribal knowledge and provide feedback to NI on taking LabVIEW applications and teams to scale.
  6. 12 points
    View File Flatline Controls A set of custom controls, following the trend of a more flat UI design. Heavily influenced by Google’s Material Design, though constrained by what can be done with available tools and options in LabVIEW. Uses icons from Google Material Design. — Buttons based on the system booleans (with hover effects). Icons can be added as decals (such as from materialdesignicons.com) — Matched sets of controls for numeric/string/enum/etc., based on Silver controls, but swapping out all ‘chrome’ for simple boxes and lines. — flattened versions of switches/sliders/arrays/graphs etc. Now on the LabVIEW Tools Network Submitter drjdpowell Submitted 06/13/2016 Category User Interface LabVIEW Version  
  7. 12 points
    I had a LabVIEW user group meeting last week talking about embedded platforms and when I got home I saw the Intel Edison collecting dust on my desk: Since it is x86, I thought I would try to deploy a Linux LabVIEW executable to the Edison and run it in the Run Time Environment. Here is what I did: 1) Install Ubilinux, based on Debian Linux, from: https://learn.sparkfun.com/tutorials/loading-debian-ubilinux-on-the-edison 2) Install xvfb, a virtual framebuffer display server (no video on this device), fluxbox display manager and x11vnc: apt-get install xvfb fluxbox x11vnc xterm 3) Install the prereqs for the LabVIEW RTE (this was already installed with the above, but good to check): apt-get install libxinerama1 libgl1-mesa-glx 4) Download the RTE and unzip it, I put it in /home as /root gets pretty full wget http://ftp.ni.com/support/softlib/labview/labview_runtime/2014/Linux/LabVIEW2014RTE_Linux.tgz tar zxvf LabVIEW2014RTE_Linux.tgz 6) the RTE is an rpm and we need deb so get alien: apt-get install alien 7) convert the rpm to deb (this takes a while): alien -k -c labview-2014-rte-14.0.0-1.i386.rpm 8) Install the RTE: dpkg -i labview-2014-rte_14.0.0_1.i386.deb 9) Install some missing fonts: apt-get install xfonts-100dpi xfonts-75dpi xfonts-scalable xfonts-cyrillic ttf-mscorefonts-installer At this point, I compiled the "UDP sender" from the examples using LabVIEW for Linux 2014 with my desktop hardcoded as the destination IP address. I copied the executable over to the Edison, ran it as follows: xvfb-run ./send and a few seconds later on my desktop: I am getting UDP packets from my Edison to my host computer sent from a LabVIEW application! I was pretty excited by this. At this point, I decided that I wanted to see if I could get a GUI running. I started up a virtual display and launched fluxbox using: Xvfb -screen 0 800x600x16 -ac & DISPLAY=:0 fluxbox & And from a linux VM, I created a SSH tunnel and started a VNC connection ssh -l root -L 5900:localhost:5900 192.168.222.90 'x11vnc -localhost -display :0' vncviewer localhost I was greeted with a desktop so I launched a terminal and executed the send program. Here is the result: So there you have it, LabVIEW executables running on a headless Intel Edison with remote desktop support. Oh, and once the VI is running from the remote desktop, you are free to disconnect and reconnect without terminating the running VI. As to resource usage, I show while running everything: root@ubilinux:~# free -h total used free shared buffers cached Mem: 960M 174M 786M 0B 9.0M 100M -/+ buffers/cache: 64M 896M Swap: 0B 0B 0B htop: 1 [##** 9.6%] Tasks: 35, 12 thr; 1 running 2 [##*** 12.7%] Load average: 0.15 0.20 0.11 Mem[|||#**** 65/960MB] Uptime: 00:07:25 Swp[ 0/0MB] PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command 2018 root 20 0 16132 5428 2772 S 5.0 0.6 0:19.94 x11vnc -localhost 2047 root 20 0 4380 1580 1204 R 5.0 0.2 0:00.83 htop 2033 root 20 0 120M 39620 27756 S 5.0 4.0 0:16.89 ./send 1987 root 20 0 52136 14608 5016 S 3.0 1.5 0:17.00 Xvfb -screen 0 80 2016 root 20 0 12540 6300 2436 S 0.0 0.6 0:02.85 sshd: root@notty 1 root 20 0 2200 716 616 S 0.0 0.1 0:00.81 init [2] 202 root 20 0 2540 1108 716 S 0.0 0.1 0:00.28 udevd --daemon 360 root 20 0 2536 816 428 S 0.0 0.1 0:00.01 udevd --daemon 366 root 20 0 2536 820 428 S 0.0 0.1 0:00.00 udevd --daemon 1552 root 20 0 5760 1424 1040 S 0.0 0.1 0:00.14 /sbin/wpa_supplic 1752 root 20 0 27916 1680 1116 S 0.0 0.2 0:00.17 /usr/sbin/rsyslog 1754 root 20 0 27916 1680 1116 S 0.0 0.2 0:00.01 /usr/sbin/rsyslog 1755 root 20 0 27916 1680 1116 S 0.0 0.2 0:00.01 /usr/sbin/rsyslog 1747 root 20 0 27916 1680 1116 S 0.0 0.2 0:00.23 /usr/sbin/rsyslog 1801 root 20 0 2424 608 520 S 0.0 0.1 0:00.00 /usr/sbin/udhcpd 1837 ntp 20 0 5304 2020 1572 S 0.0 0.2 0:00.11 /usr/sbin/ntpd -p F1Help F2Setup F3SearchF4FilterF5Tree F6SortByF7Nice -F8Nice +F9Kill F10Quit The VI is using about 5% CPU as well as 5% on the the VNC server and 3% on the virtual framebuffer. Here is the disk usage: root@ubilinux:~# df -h Filesystem Size Used Avail Use% Mounted on rootfs 1.4G 1.3G 78M 95% / /dev/root 1.4G 1.3G 78M 95% / devtmpfs 480M 0 480M 0% /dev tmpfs 97M 300K 96M 1% /run tmpfs 5.0M 0 5.0M 0% /run/lock tmpfs 193M 0 193M 0% /run/shm tmpfs 481M 12K 481M 1% /tmp /dev/mmcblk0p7 32M 5.3M 27M 17% /boot /dev/mmcblk0p10 1.3G 125M 1.2G 10% /home It's pretty tight, you will definitely run out if you do not do the RTE installation from /home. As to IO, I have not played much with doing anything with the IO ports, that's next on my list. I wanted to share my progress so far and get people's feedback. Thanks Jon
  8. 11 points
    You know how you can change the wire appearance for a class in the class properties? As it turns out, LabVIEW internally allows for more flexibility than that dialog gives you. So I made an advanced wire editing tool...and unlike a lot of stuff I post, you can actually use this for serious projects, because it does not use any private/unsupported LabVIEW functionality! With this tool, you can set wire size without limits (with results similar to this), customize both wire layers with any 8x8 monochrome pattern, and also mess with different draw options. Strangely, a few of these settings seem to have no effect, and many of the options for one of them actually crash LabVIEW. (These ones are disabled in my tool, but you can re-enable them by editing a typedef.) Given that this is actually a documented, supported property that's officially supposed to work, I've reported this as a bug to NI; if any NI engineers see this and feel like investigating, you can refer to service request #7762024. Latest version: Wire Studio 2.zip Old versions: Revision 1
  9. 10 points
    Hello everybody! During a few last years I received multiple appeals to release AES library that I developed in 2011 into open-source. So, I've just done exactly this: https://github.com/IgorTitov/LabVIEW-Advanced-Encryption-Standard I released it under MIT license (which means that there are no restrictions whatsoever). No VI passwords, no uglification. LabVIEWishly Yours, Igor Titov.
  10. 10 points

    Version 1.8.0

    1,525 downloads

    A set of custom controls, following the trend of a more flat UI design. Heavily influenced by Google’s Material Design, though constrained by what can be done with available tools and options in LabVIEW. Uses icons from Google Material Design. — Buttons based on the system booleans (with hover effects). Icons can be added as decals (such as from materialdesignicons.com) — Matched sets of controls for numeric/string/enum/etc., based on Silver controls, but swapping out all ‘chrome’ for simple boxes and lines. — flattened versions of switches/sliders/arrays/graphs etc. Now on the LabVIEW Tools Network
  11. 10 points
    Please see this link for Video downloads The NIWeek 2017 Videos are uploaded to the ftp server. Please see this link for information on downloading the videos. https://lavag.org/topic/19154-ni-week-2015-videos/#comment-115444
  12. 10 points
    Note: G Code Manager is now available at GitHub: https://github.com/veritechpl/gcm G Code Manager GCM is a tool that makes the properties of Project Items in Project Explorer window more accessible, removing unnecessary waiting times and modal windows. In runs in window next to the Project Explorer window and shows the items properties immediately after selecting new item in the explorer. GCM also allows you to create your own plugins to access those Project Items! Requirements The package was built in LabVIEW 2014, it should also run in LabVIEW 2015. How to start In the Project Explorer window click on the Tools menu, then select G Code Manager -> Run GCM… Download IMPORTANT NOTICE This tool was made using some internal LV APIs which are not fully tested and documented It is in very early stage when it comes to stability It may cause LV to crash! I strongly advise using source control - if you're not using one, do not even install this tool! (Above statements are really for your own good - I'm using this tool in my everyday work and I don't have any major issues. However, you might accidentaly clear your VI description or icon, or something like that, so be prepared for it by using source control like SVN or Git to revert the changes). Current Version Version 1.14.0.71 Download: veritech_labview_code_manager-1.14.0.71.vip - Added GCM settings screen - Added option to automatically open GCM with the project Older Versions Verstion 1.13.0.67 Download: veritech_labview_code_manager-1.13.0.68.vip - Interface cosmetics. Smaller window size - GCM remembers last selected plugin for the project item type - Dock button added, which makes GCM window always on front - Added support for build specifications: EXE, Installer, RT Exe, FPGA - Added VI Window Properties plugin (beta) - Added VI Execution Properties plugin (beta) Version 1.11.0.61 veritech_labview_code_manager-1.11.0.61.vip - Icon Editor: Added "Default Font Settings" which sets the font to 8 pt, centered, capitalized. - Fixed the synchronization issue between plugins (icon edited in Icon Editor was not updated in Basic Documentation). - Added new incoming events for plugins to better handle items selection/deselection and plugin activation/deactivation (see the attached documentation) Note: The plugins API was changed in this version. If you've made your plugin in previous versions, please refer to the updated documentation. If you have any problems, just contact me Documentation: GCM.pdf Version 1.10.0.58 veritech_labview_code_manager-1.10.0.58.vip - Added Icon Editor for VIs, which currently allows editing the icon text or clearing the icon completely Documentation: GCM.pdf Version 1.9.0.54 veritech_labview_code_manager-1.9.0.54.vip See this document for more information: GCM.pdf
  13. 10 points
    I want to let LAVA know about a feature of LV 2016 that may not get much press. The In-Place Element structure has a new pair of border nodes to let you access the attributes of a variant without copying them out of the variant. This will VASTLY improve the performance of tools that use variant attributes as lookup tables. I strongly encourage everyone who works on this to look at the shipping example: labview\examples\Performance\Variant Attribute Lookup Table\
  14. 10 points
    Neil, I've found this procedure to fix this problem, and a host of other issues with source/object code asynchronization: Ensure you have no outstanding changes in your working copy; everything is committed to the repo Ensure for multi-developer teams you effectively have a mutex on the entire repo; you're likely about to make a widespread commit that touches lots of source. It's especially imporatant to have no outstanding changes on .lvclass, .ctl, .xctl, .lvlib, .xnode, or .lvproj files, because these cannot be readily diffed or merged in LabVIEW. (Perhaps a good time to do this is on the weekend, where all team members know to have changes committed before then.) Shut down LabVIEW completely Open all classes in XML Editor (on windows, Notepad++ is good, associating lvclass files as XML in the Style Configurator) Find the <Property> tag for "NI.LVClass.Geneology". Delete this entire tag. This removes any stale mutation history. **Careful here!** The entire tag is likely to span 9 lines. Be sure to delete them all. (I've not yet found or developed a reliable API for this operation; lemme know if one exists.) Find the <Property> tag for "NI.Lib.Version" -- reset this to the value 1.0.0.0 Open LabVIEW to the Getting Started Window; "Tools >> Advanced >> Clear Compiled Object Cache ..." then clear the cache for both User and App Builder Shut down LabVIEW completely Open the project and offending VIs to see if this fixes things. Maybe so, but you're not done yet. If you have not done this yet, ensure every single source file is marked as source-only (e.g., not a unifile). Right-click the root node of the project, "Properties" menu item, "Project" config page Ensure "Separate Compiled Code from new project items" is checked "Mark Existing Items..." button, select all items in the tree, then "Mark Selected Items". Wait for the operation to complete, then close this dialog. Open this dialog once more; visually scan the entire list, ensuring all statuses are "marked" Right click on the root node and "Find Missing Items". Resolve these bad linkages, probably by just deleting them from the project. If you have not done this yet, find all diagram disable structures in your project (this is simple if all VIs are in LVClasses -- since all VIs are in memory -- or with the legacy VI Tree hack). One way or another, ensure all VIs are in memory, find all disable structures, and analyze the disabled cases for links to missing VIs. Do that again for Conditional Disable Structures. Mass compile the project (from right click context menu from root node of project tree) Might as well take the opportunity to fix all the errors that are returned by the mass compile. If you have insanities, search the phrase "labview heap peek insane" for instructions how to fix these. If you can't get the keyboard commands for heap peek to work (e.g., if you're developing in a VM), there exists an undocumented VI Server App method to toggle heap peek visibility. Shut down LabVIEW completely Goto Step 7; rinse and repeat until zero errors are returned Ensure the application still runs from source; e.g., you've not accidentally broken something. If this smoke test passes, commit all changes to your local repo. This is your first checkpoint. Goto Step 7, and follow all steps again back to here. If some source files have been modified (e.g., there exist modifications in your working copy), this means will probably benefit from cross-link and circular-link tips below. Especially, if during the mass compile, you see the dialog repeating what appears to be the exact same operation over, and over, and over, and over, and over, and over, and over, and over ... Try implementing the tips below. Goto Step 7 Goto Step 3, and follow all steps again back to here. You should be able to complete this entire process with zero modifications to the codebase. Commit changes to local repo. Goto Step 3, and follow all steps again back to here. If you're happy, push to central repository. Have all developers/contributors clear their compile object caches. No really; witness that operation. It's vital. Have all developers pull the project. Ensure no corruptions exist; ensure the project can be opened and closed immediately with no "dirty dots". If these dots exist, your environments are somehow different (different versions of LabVIEW?), and should probably be resolved. I've tried to codify this procedure accurately above, but drop a line if it doesn't work or correct it with a response to this thread. Tips for the future to avoid these problems (from extensive at-scale experience with LVOOP spanning LV2009-2013SP1f2+): Refactor to avoid all typedef'd clusters in Class Private Data definitions. If they must exist, ensure that if they ever recompile, all LVClasses linking to the type are also saved to disk, especially if it's just one of those 'recompiles' that we've conditioned ourselves to ignoreOne overlooked place that typedef'd clusters can hide is as sub-types to some native labview objects, such as Queues, Events, etc... Avoid type defining primitive types such as strings/numerics/bools (You:"but..." me: "I know, me too. But it is what it is.") If you are using reference types (e.g., .NET) as elements in your class private data, you may run into unique issues that require other resolutions. One resolution is storing the reference as a flattened type, then creating accessors that cast to/fro the desired type. (Avoid even having elements in your class private data. Statelessness and immutability are desirable anyway for a functional style and synchronous dataflow.) When refactoring and changing the scope of types, ensure that both owning library files (lvclass, lvlib, xnode, xctl) are saved to disk. Else, corruption, sometimes tough to detect immediately, and may not even show up until build-time. Usage of LVOOP property nodes voids the warranty of LabVIEW altogether for applications of non-trivial scale. Don't use them in any version up to the time of writing, 2013SP1f2+ (You:"but..." me: "Good luck with that") Avoid circular linkages between classes. It's not uncommon for the type-propper to give up recursing if too many circular linkages exist, sometimes ending in a "VI failed to compile" error.To analyze these linkages, open classes one-by-one in an empty project. Inspect the "Dependencies". Click on classes/libraries and say "Why is this item in Dependencies?" to highlight the static link. Though, on codebases that have hidden corruption, this feature crashes LabVIEW -- instead, "Find Callers", which is slightly less convenient because it may highlight other Dependencies. To fix the dependency vector, refactor. Strictly avoid nesting of lvclasses within lvlibs; consider avoiding lvlibs altogether. The problems they can cause (edit/build/load/run-time performance, accidental corruption) are typically not worth the benefits (scoping/namespacing, common icon, LVProj loading members for API convenience...) (This is one key offender for the "endless" loops while mass compiling, and can drastically degrade edit/build/load/run-time performance.) Avoid polymorphic VIs; these "convenience" wrappers are just overloaded functions that carry static linkages to stuff you don't need to be linked to. (This is one key offender for the "endless" loops while mass compiling.) XNodes are a better alternative, but quite tricky to develop. The moment you or a developer colleague says to the other "i'm not seeing that in my environment", clear both your compiled object caches and re-start whatever you were first talking about. (Mass compiling is not sufficient, since the cache is not always invalidated when it should be, but this has gotten steadily better from 2009-2013) To sum up; avoid static linkages, and ensure dependency vectors between all code modules are unidirectional and don't form cycles. For multi-developer teams and/or codebases of non-trivial size; may the force be with you. And may you have an experienced colleague or consultant periodically auditing and transparently fixing the codebase to keep all productive and healthy and happy. Open offer: if you've ended up on this thread at your wit's end, send me a message and let's screenshare and fix it.
  15. 9 points
    Tecnova has created a new LabVIEW Video site to replace the previous ftp server for downloading NIWeek and CLA Summit videos. Location: https://labviewvideo.tecnova.com Login: LabVIEW_Videos (Not case sensitive) Pw: LabVIEW (case sensitive) Check out the LabVIEW Videos Tecnova site Demo to see all the features of the new site. For comment or feedback please email LabVIEWVideo@tecnova.com Thanks to Tecnova Management for supporting the LabVIEW Community. Note: Testing has shown successful downloads using Chrome, IE and Edge for Windows and Safari for Macs. FireFox however tries to auto play the video and may not work like the other browsers. LabVIEW Video Demo.mp4
  16. 9 points
    Hi, I figured people here may be more interested in this project. I have some cool graph extensions I'm building in an open source project, which make some nice graphical overlays for XY graphs and waveform graphs in LabVIEW. I've got a github page where you can grab the code, support the project or just have a look at some of the same screenshots. Everything updates live in the graph, so you really need to see it, to get how it all works, so here you go: https://github.com/unipsycho/Graph-Extensions-LabVIEW Please star follow the project if you want to see this developed and I'd appreciate any feedback or ideas to extend it further. The markers are very much IN development right now, so no where near finished, but the tools can still be seen working. THANKS!
  17. 9 points
    UPDATE: These first few revisions are more or less broken. The first fully working version can be found here. 8 Years ago the first version of the XNode Manager was posted to the code repository, and it hasn't seen an update since 2009. Being a fan of XNodes, but knowing that the XNode Manager is pretty limiting because of its age, I set out to make a new version with similar functionality. I didn't spend too much time on it, and I don't think it replicates all the XNode Manager functionality, but it does have some major improvements. The XNode Manager had a blank XNode, and blank Abilities that it just made copies of. This is fine but then the abilities and XNode are quite old. There were many new Abilities added since version 8.2 and you can't add them using the XNode Manager. My XNode Editor reads your LabVIEW resource and populates the list of abilities to create from the ones that are possible to create. Then VI server is used to create the XNode, State control, and Abilities. This sets up the connector pane like it should and should work with all future versions of LabVIEW, until NI changes something that breaks it. Be aware this uses several private functions, and several undocumented features that could be potentially bad. I did a decent test to make sure memory leaks weren't a problem and I made several XNodes and Abilities and it seems stable. But at the end of the day if it blows up and crashes, don't be surprised, you've been warned. Saved in 2013, but could probably back save earlier if requested. If I get more time I'll add some features, and add it to the Code Repository. XNode Editor.zip
  18. 9 points
    I put together a series of articles while working on an AF 101 presentation for our local CLD summit. Check them out and let me know what you think or if you have any questions/improvements. Part 1 – The Background Part 2 – The Actor Part 3 – Launching and Communicating Part 4 – Being Productive With Actors Basic Walkthrough – Creating a Logger
  19. 9 points
    Hi LAVA friends, We are pleased to announce that the Delacor Queued Message Handler (DQMH) is now available via the LabVIEW Tools Network: http://sine.ni.com/nips/cds/view/p/lang/en/nid/213286 You can read about the thought process behind DQMH at our blog post: Ours is not better than yours (or YAF=Yet Another Framework) at WalkingTheWires.com The DQMH is based on the NI QMH Project Template. The DQMH expands on the NI QMH by providing safe, event-based message handling and scripting tools to encourage same style between different developers in the same project and improve efficiency. The DQMH is ideal for applications where multiple modules must run in parallel, possibly at different rates, while communicating with each other. The DQMH can also be used for applications that have a single module, where the developer would benefit from having a Tester with the capability of eavesdropping on the different DQMH events and messages. The DQMH integrates with TestStand since all development and troubleshooting can take place under LabVIEW, while calling the public API VIs as individual steps in the TestStand sequence. The tester can eavesdrop during the execution of the TestStand sequence. This is specially useful when the LabVIEW code is written during the research and development or prototyping phase, because the same code can be called by TestStand in production or manufacturing sequences without any changes. The DQMH uses LVOOP for some internal functions, but developers need not be familiar with LVOOP to use or understand this architecture. Try it out and let's us know what you think. Fab and the Delacor team.
  20. 8 points
    This is how I clear errors.
  21. 8 points
    LAVA has won an NI award for LUGnuts at NI Week, the largest independent online user group. Thank you everyone for making the online community something to be proud of.
  22. 8 points
  23. 8 points
    Please see the above link to download the videos The NIWeek 2014 Videos are compressed and ready for down load from Tecnova's ftp server I would strongly recommend using an ftp client to transfer them to your computer. A web browser may work but if you want to download multiple videos the ftp client makes things much easier. My ftp client of choice is FileZilla and it is free. FileZilla can be downloaded at http://filezilla-project.org/ ftp://frc.tecnova.com login: LabVIEW_Videos pw: LabVIEW login and password is case sensitive. if you are using Filezilla your site manager window will look like this. A big thank you to Dan Bosdech for recording the sessions on Thursday as I was attending a private all day session. Enjoy and let me know if there are any issues. Mark
  24. 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
  25. 7 points
    View File Plasmionique Modbus Master This package contains an open source Modbus master library for LabVIEW. It has been developed by Plasmionique Inc. as a replacement for NI Modbus V1.2.1 and provide an open source alternative to the NI Modbus Community API. It supports RTU, ASCII and TCP modes with the following function codes: 0x01 - Read Coils 0x02 - Read Discrete Inputs 0x03 - Read Holding Registers 0x04 - Read Input Registers 0x05 - Write Single Coil 0x06 - Write Single Register 0x07 - Read Exception Status 0x0F - Write Multiple Coils 0x10 - Write Multiple Registers 0x16 - Mask Write Register 0x17 - Read/Write Multiple Registers 0x2B/0x0E - Read Device Identification Additional Features: Built-in resource locking simplifies the sharing of a serial port with multiple Modbus slaves or sharing a Modbus session across multiple threads. Examples are included in "<LabVIEW>\examples\Plasmionique\MB Master\": MB_Master Comm Tester.vi: Demonstrates usage of API to open/close connection and communicate with a Modbus slave device. MB_Master Multiple Sessions.vi: Demonstrates usage of API to open concurrent Modbus sessions. MB_Master Simple Serial.vi: Demonstrates polling of a single input register over serial line. User guide is included in "<LabVIEW>\help\Plasmionique\MB_Master - User Guide.pdf". Modbus COMM tester can be opened from the tools menu under "Tools -> Plasmionique -> Modbus COMM Tester..." Download a copy of the user guide here: MB_Master - User Guide.pdf Note that Version 1.3.4 of this library has been certified compatible with LabVIEW and has been released on the LabVIEW Tools Network: http://sine.ni.com/nips/cds/view/p/lang/en/nid/214230 The most recent version of this library will always be released on LAVA first before going through NI's certification process. ***This project is now available on GitHub: https://github.com/rfporter/Modbus-Master Submitter Porter Submitted 04/01/2016 Category LabVIEW Tools Network Certified LabVIEW Version  
  26. 7 points
    There are a bunch of objects in LabVIEW that aren't exposed in the default palettes, and are normally inaccessible except through scripting. I made a Quick Drop plugin that exposes all of these. Many of these are no longer supported, and others never were supported in the first place. Hidden ones are displayed with an "X" next to them to warn you: as I often say, be careful with these, and don't use them in any code you care about, as they can cause crashes, data corruption, and who knows what else! Download the LLB below and place it in your <LabVIEW install dir>\resource\dialog\QuickDrop\plugins folder. Then press Ctrl+Space, Ctrl+S to open this dialog. Select an item from the list and click OK, and there you go. There's some interesting/strange stuff in here! EDIT: Couple things I forgot to mention. The first time you open this (and whenever you rebuild the list) it uses two private properties on the app reference, to get the list of controls and indicators in the palette. Since this is just a property read, I'm sure the worst that could happen is a crash when you try to open the dialog, but I can't make any guarantees. Also there's some false positives for hidden items, mainly with front panel controls/indicators that come in different styles. Place by Style.llb
  27. 7 points
    This is a weekend project (ok, several weekends now) I've been meaning to share for a while. It's a proof of concept which I'd like to get some feedback on before I invest more time. The idea is to provide a toolkit that uses LabVIEW webservices to serve an interactive HTML5 representation of any application's front panel(s) as an easy way to monitor and control the application (over the internet) without the need for heavy applications or runtime engines. Just a browser. And because not everyone is a also web-developer, the work required to create that website should be done entirely by the toolkit. In my solution it's as easy as dropping a single vi on the block diagram, that registers the VI with the FrontPanelManager which takes care of all the data exchange between the website and the front panel. Here's a screenshot of an example front panel showing all supported elements and its HTML version on chrome: Obviously, there are some cosmetic differences that can be fixed later. Controls on both LabVIEW front panel and HTML site act as controls and are synchronised across the two. By default, the website queries the front panel every 250ms for new data. The refresh rate can be changed with the cog button in the bottom right corner. To run it open the project start the WebService Get the URL of Main.html and point your browser to it start "To Publish/Main.vi" and watch the data appear in the browser As I said this is a proof on concept and it's a long away from being a toolkit. I'm working on functions that appear in the Tools menu to automatically add and configure the webservice and dependencies and many other things. [2014]FPPublisher.zip
  28. 7 points
    Greetings Friends of LAVA, colleagues, cohorts, and Wireworkers Extraordinaire -- it's LAVA BBQ time! Change log for 2018: Prices have been rolled back to a previous, cheaper version New location, see below Date: Tuesday, May 22, 2018 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 May 4th) $30 Regular Admission (through May 20th) $35 At the door (May 21st - 22nd) Meal Options: Expect to enjoy your choice of meats (brisket, turkey, ribs) with sides like mac and cheese, cole slaw, and potato salad. 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. ------------>>------------>> Get LAVA BBQ 2018 Tickets Here <<------------<<------------ The venue is now 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 Exhibit Hall 4, 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 Hope to see you there! Chime in once you buy tickets to let everyone know you're coming.
  29. 7 points
    I just became aware of this thread and I'm not going to go back and comment on all the discussion points that have been made before, except to say: The original code which did not use a shift register was wrong, but happened the work because of a bug in the LabVIEW inplaceness algorithm. Any input tunnel should retain its original value of every iteration of the loop, so it should've stayed not-a-refnum every time, and therefore the dynamic registration should should have been lost where the loop iterated. The issue was that the left dynamic registration terminal (which is always in-place to the right one) was also in-place to the input tunnel, causing its value to be stomped incorrectly. This is clearly a bug and needed to be fixed. It violated dataflow 'rules' for how tunnels are supposed to behave, and could've made some correct programs yield incorrect behavior. This is not a change that would break a correctly written program, so it does not qualify as an "API breaking" change; this usage has always been wrong but happened to work due to a bug. (This is categorically different than changing behavior of correct code or even changing undocumented behavior, which we try strenuously to avoid.)
  30. 7 points
    Greetings Friends of LAVA, colleagues, cohorts, and Wireworkers Extraordinaire -- it's LAVA BBQ time! Date: Tuesday, May 23, 2017 Time: 7:00-10:00 pm Location: Scholz Garten, 1607 San Jacinto Blvd, Austin, TX 78701 (1 mile from Convention Center) Cost: $30 Early Bird (until May 6th) $35 Regular Admission (until May 22nd) $40 At the door (May 22nd - 23rd) Meal Options: Expect to enjoy your choice of meats (ribs, brisket, turkey) with sides like beans, cole slaw, and potato salad. There is always plenty of food. A vegetarian option is available when purchasing tickets. Cash bar, beer and wine. 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 an 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. get tickets on The LAVA BBQ 2017 Event Page Do you want 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. We would prefer a single item donation. If donating more than one item, then multiple identical items is strongly preferred. So we don't spend our time on a flood of refrigerator magnets, please donate something valued at $25 or more. 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. All prizes are acceptable except those listed below (examples from 2015 and 2016): Not recommended: Apparel (hats, t-shirts, underwear etc) Branded trade show booth type giveaways (mouse pads, pens, keychains etc) Software licenses (Toolkits, add-ons, LabVIEW) Jokes or something meant as a gag and not a real prize Hope to see you there! Chime in once you buy tickets to let everyone know you're coming.
  31. 7 points
    Greetings Friends of LAVA, colleagues, cohorts, and Wireworkers Extraordinaire -- it's LAVA BBQ time! Date: Tuesday, August 02, 2016 Time: 7:30-10:00pm (after the NIWeek Block Diagram Party) Location: Scholz Garten, 1607 San Jacinto Blvd, Austin, TX 78701 (1 mile from Convention Center) Cost: $30 Early Bird (until July 15th) $35 Regular Admission (until July 31st) $40 At the door (Aug 1st - 2nd) Meal Options: Standard meal is your choice of brisket, ribs, or chicken, with sides of beans, cole slaw, and potato salad. A vegetarian option is available when purchasing tickets. Cash bar, beer and wine. 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 an outdoor venue in Austin during August. So dress for the weather and comfort. Door Prizes: Towards the end of the event, we will have a raffle to give away prizes. All attendees are eligible and will receive a raffle ticket upon entry. or get tickets on The LAVA BBQ 2016 Event Page Do you want to sponsor a door prize? - Continue Reading: If you or your company want to sponsor a LAVA 2015 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. We would prefer a single item donation. If donating more than one item, then multiple identical items is strongly preferred. So we don't spend our time on a flood of refrigerator magnets, please donate something valued at $25 or more. 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. All prizes are acceptable except those listed below (examples from last year): Not recommended: Apparel (hats, t-shirts, underwear etc) Branded trade show booth type giveaways (mouse pads, pens, keychains etc) Software licenses (Toolkits, add-ons, LabVIEW) Jokes or something meant as a gag and not a real prize. Hope to see you there! Chime in once you buy tickets to let everyone know you're coming.
  32. 7 points
    The best thing about UDP jokes is that I don't care if you get them or not.
  33. 7 points
    Hi all, I'd like to introduce LQ Widgets, a library to bring advanced GUI features to LabVIEW. It is powered by the Qt toolkit plus the Qwt library (Qt Widgets for Technical Applications). This library consists of two major subcomponents that might interest LabVIEW users: A GUI framework that is powerful, flexible, and comprehensive (see demos below). A event-driven, intra-process communications framework. You can establish connections using (i) LabVIEW user events, (ii) callback VIs, or (iii) string specifications. Here it is in action: Why a GUI library? The Idea Exchange has many, many posts about improving LabVIEW's GUI capabilities. However, we likely have to wait several years at least before these wishes are granted (see AristosQueue's post at http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Make-updating-the-GUI-a-priority-in-a-near-term-LabVIEW-release/idc-p/2710511#M26394). The required technologies are actually available right now. In fact, they have been available for many years. All we need is a way to access them easily from LabVIEW. LQ Widgets aims to provide this access. Why yet another communications framework? Providing a comms library wasn't part of my original goal. Nonetheless, the system used by the GUI components can also be used for non-GUI purposes, so it's here for you to try. Where to get it? Downloadable packages: Package for LabVIEW 2014 (recommended; take advantage of the the new web-based documentation) Package for LabVIEW 2013 Quick start guide at https://github.com/JKSH/LQWidgets#usage. The C++ source code is also easily accessible from here, if you're interested. EDIT: Most importantly, you must either extract the package to C:\LQWidgets\, or modify the output of src\LabVIEW\LQ Core\_Internal\Library Path.vi (thanks, mwebster!) Project roadmap See http://github.com/JKSH/LQWidgets/wiki/Roadmap Known Issues This is a pre-alpha release, which means (i) the API will likely change in the near future, (ii) the library is far from feature-complete, (iii) performance is not optimized, and (iv) you might experience crashes. Other issues include: You currently can't free any resources or disconnect signals, except by calling LQCoreEngine.lvclass:Stop Engine.vi QWinThumbnailToolButton cannot be applied to non-Qt windows, such as LabVIEW front panels After you start and stop the engine, QWinThumbnailToolButton no longer emits any signals when you click on it Workaround: Restart LabVIEW There are a few small memory leaks, which will persist until you close LabVIEW. Request for feedback What do you think of the GUI-related API? What do you think of the communications-related API? What is the single most promising aspect of this library? What is the single most frustrating aspect of this library? All comments and critique are most welcome. Thanks for your time!
  34. 7 points
    Hi guys; Check out what we are doing with LabVIEW and Arduinos. http://www.tsxperts.com/arduino-compiler-for-labview/ We created an actual LabVIEW compiler for Arduino targets that allows Arduinos to be programmed in LabVIEW. Figured to share this with the community. Cheers Filipe
  35. 7 points
    I just upgraded the LAVA server, so the response should be even better than the already pretty fast previous server. Enjoy.
  36. 7 points
    Mwuhahahahaha! Three config tokens have escaped your grasp! I modified them specifically for folks like Flarn! They don't appear as plain text anywhere in the EXE (or in any VI for that matter). Do they guard any great secret of LabVIEW? I'm not telling! But you can have fun pouring through the code and looking for interesting bits and trying to figure out what you need to put in your config file. LabVIEW 2013 or later. Good luck.
  37. 7 points
    National Instruments has created a GitHub repository to community source G libraries. This move is intended to be a test of a mechanism to enable customers to create customizations of NI source code and share those customizations with each other and for NI to be able to adopt some of those customizations into its core products to benefit the entire LabVIEW community. We are beginning with just three libraries: The Actor Framework, a library in vi.lib since LV 2012 The NI-GOOP Development Suite, a free toolkit add-on for improving LabVIEW class development The AQ Character Lineator, a library not yet in vi.lib to support serialization/deserialization of LabVIEW classes If this experience working with the community proves fruitful, NI may expand the number of our APIs that are part of this sharing. For more information, including instructions on how to access the GitHub repository, please visit this community: https://decibel.ni.com/content/groups/community-source-of-ni-code For details of how to get access to the GitHub repository and the license agreement covering this project, please visit here: https://decibel.ni.com/content/docs/DOC-37195 I want to make a personal comment on this new development: Opening up LabVIEW to more community participation is something I and a few others have worked on for many years. This is a major advance in that quest. We know that requiring a license agreement for participation is not a typical "open source" arrangement, but this is the best idea we have found to balance the desire of our users to improve LabVIEW while acknowledging that LabVIEW is for-profit software that gets used in sensitive industries. If you have particular objections to the license agreement, please open a discussion thread in the community linked above so we can discuss them. We believe most users will find this arrangement acceptable, but not everyone. I hope, though, that this can be a successful venture, and perhaps will serve as a first step toward more.
  38. 6 points
    I just started down the rabbit hole of making a new XControl recently. Oh man such a pain. Here is a little graph I made complaining about the XControl creation process, and the time needed to make something useful. Any alternative is appreciated.
  39. 6 points
    Hi All, I have implemented Kalman filter using LabVIEW 2016. You can find the codes here: http://kataauralius.com/index_files/Kalman_filter_in_Labview.html. Hopefully this is useful for those who struggle with the implementation of Kalman filter in realtime system. Best, Auralius http://kataauralius.com
  40. 6 points
    What? Been there since pre-8.2? Who's been laughing at us flailing around with locked-down multi-VI XNodes (or multi-multi-VI polymorphics) for years? This seems to answer 99% of my (and everyone elses) requests for a simple type-adapting VI. Looks like a very simple XNode without any type-checking (e.g. wire a Boolean to the Delay input and it generates the code but breaks the calling VI). But if the programmer can be trusted, it looks incredibly useful. I would presume it has the same caveats as using an XNode, but if it's now "released" (thanks jkodosky, who I imagine has some mandate to do so) it would be good to know anything to be aware of. BTW, this is certainly not the same as the buggy, non-supported Generic VI that was dangled in front of us some time ago.
  41. 6 points
    So in a presentation about XNodes I was asked a question about what were the valid "Reply" options for an XNode ability. Some abilities have a reply as a 1D array of string and it appears to work like a QMH where you provide a list of states to go to and it does them one after another. I didn't know the answer but I knew scripting could help. So I scanned a bunch of XNodes for what strings were on the block diagram going to the reply and here are the abilities, along with the reply strings I've seen used. AdaptToInputs UpdateTerms UpdateImageAndBounds GenerateCode ForceAdaptToInputs Copy GenerateCode UpdateTerms UpdateImageAndBounds FailTransaction DoubleClick FailTransaction UpdateTerms UpdateImageAndBounds GenerateCode GenerateCode PreserveUserCodeGUID GetError Message UpdateTerms UpdateImageAndBounds GenerateCode FailTransaction ForceAdaptToInputs OnFontChange UpdateImageAndBounds UpdateTerms OnOperateClick UpdateImageAndBounds GenerateCode OnResize UpdateTerms UpdateImageAndBounds GenerateCode OnDrop UpdateTerms UpdateImageAndBounds GenerateCode OperateClick ShowMenu RefeeChanged GenerateCode UpdateImageAndBounds UpdateTerms RespondToDrop GenerateCode UpdateTerms UpdateImageAndBounds SelectMenu UpdateImageAndBounds UpdateTerms GenerateCode FailTransaction ReplaceSelf Size UpdateImageAndBounds UpdateTerms GenerateCode UpdateState GenerateCode ForceAdaptToInputs IssueWarning UpdateStateWithRef UpdateImageAndBounds UpdateTerms GenerateCode ReplaceSelf So the unique values that I've seen put into the Reply are the following. I am unsure if only some abilities only support some replies. UpdateTerms UpdateImageAndBounds GenerateCode ForceAdaptToInputs FailTransaction PreserverUserCodeGUID GetError ShowMenu ReplaceSelf IssueWarning As for what do these do? Well some are more obvious than others, but here is some text I found in one of the XNodes that helps: FailTransaction: LabVIEW will abort the current transaction. This will avoid putting transactions in the undo list when the user just hit cancel. GenerateCode: This will cause a type propagation if appropriate, and will cause the XNode to GenerateCode when type propagation is run. UpdateImage: LabVIEW will call Image and invalidate the XNode. UpdateImageAndBounds: LabVIEW will call Bounds and Image and resize and invalidate the XNode. It will not call Size. Size is only called if the user resizes the XNode (so that you may update your state and return this reply). Make sure that if your terminals need to change size or location, you also return UpdateTerms. This reply will set the transaction type. UpdateTerms: LabVIEW will call Terms and create, delete, and move terms as necessary. ForceAdaptToInput When mutating an old, unconfigured Express VI, we need to ForceAdaptToInputs before code gets generated. AdaptToInputs used to always get called before GenerateCode. But that is no longer the case in LV2011.
  42. 6 points
    Just twice? So your LabVIEW stability went up? Just kidding.
  43. 6 points
    I'm in I will be sure to record it for those that can't make it this year.
  44. 6 points
    We are announcing a brand-new LabVIEW toolkit, aimed at making publication-quality plots directly from the block diagram. In addition to regular line, scatter, and bar plots, this toolkit also supports advanced features like 2D contours, vector fields, streamlines, alpha transparency, and inline math using LaTeX. You can save plots directly to disk in half a dozen formats, including PDF and PNG. We call it the "Advanced Plotting Toolkit", and it's available at http://www.advancedplotting.com along with example VIs and documentation. The toolkit is in open beta, and distributed as a standard .vip package with no dependencies. If people have the time, we'd love to hear feedback. That doesn't just mean bug reports... this is an amazing community and we'd love feature suggestions as well. Comments are welcome here or by email (contact@advancedplotting.com). I've included some screenshots of our example VIs below to give you an idea of what the output looks like. Btw, there is also a stand-alone demo app (built using Application Builder) that you can use to test-drive the toolkit without installing anything in LabVIEW.
  45. 6 points
    Ok. first off. Windows is not a real time OS so it isn't deterministic. I know that, you know that but your project manager probably doesn't so that was for him. Second. I bet you are so close, that if we can just optimise what we already have a little better, we will be home and dry. Sure. Then in 6 months the spec changes to every 7 ms and the project manager says "you did it before, now do it again - it's only 1ms". So. What is the problem? Ahh. Just poking over the 8 ms in places. Lets see if its what all the girls say that size does matter and bigger is better. Ah yes. No problem with under 8ms. The girls are half wrong and half right. Size does matter but smaller is better. (In fact it is linear. 400,000 will yeild about 3 ms, 200,000 about 1.5 ms etc). Easy answer 1. Reduce the data size in the global. But why so slow? Is it the array disassembling? Is it the reading from the global? Does it need more coffee? Oooh. Microseconds. My spidy sense tells me its the global. Easy answer 2: Don't use a global for big arrays if you're time constrained. That about wraps it up for reading. In the next issue we will cover: Oh my god. It all falls to crap when I write data.
  46. 6 points
    Hi Guys, I have an idea, I want to try and promote the various open source communities and highlight top projects as well as guide people on how to work/publish open source code. It's my belief that if we can promote this form of collaboration we can end up with better tools and libraries to build better software. Examples like the JSON library here really make me believe this. As such I've set up a group to try and find likeminded folk on the darkside. If you interested in helping then head over to https://decibel.ni.com/content/groups/open-source-labview and we can start to get some ideas together. Cheers, James
  47. 6 points
    The Project Provider Framework is an API provided by LabVIEW that has minimal support from NI. This API can be used to create new types of project items, add new menu items, and other stuff like that. They only share documentation about the API with those who apply to be partners, however, and there is a signature mechanism to enforce this. Well I've figured out how that signature is generated, so hopefully the LAVA community can do some cool stuff with this! I haven't really played around with it at all, but I plan to. Each plugin is defined by an INI file, located in resource\Framework\Providers\GProviders. Each INI file has a Signature key, which is required to be valid in order for LabVIEW to load the plugin. To generate this signature, first you need to concatenate all the values (not the keys) in the INI file. Only string values though, not numeric or Boolean ones. I'll use GOOP_MyComputer.ini from OpenGDS as an example: [Provider] SupportedType={CEFE1B10-1732-4678-A70A-299293455410} IsPrimary=0 ItemInterfaceVI=..\Open_GDS\GOOP_MyComputer_Item_Interface.vi CreateNewWizardInterfaceVI=..\Open_GDS\GOOP_MyComputer_CreateNewWizard_Interface.vi CreateNewWizardHost=Source LicenseName=None InterfaceVersion=1.0 Signature=KS5CBT93T9SSJK3SNWB239RLN95WTC9W Ignore the Signature line as well, of course. The concatenated string here will be "{CEFE1B10-1732-4678-A70A-299293455410}..\Open_GDS\GOOP_MyComputer_Item_Interface.vi..\Open_GDS\GOOP_MyComputer_CreateNewWizard_Interface.viSourceNone1.0". Take the MD5 hash of this string. In this case, the hash is "8423091770884C816AF971DB7A632067". The next step is to apply a simple substitution cipher to the MD5 hash: 0123456789ABCDEF T3C5K7W9SBNRJLX2 Just replace the character on the top with the one under it. So the new string will be "SKC5TB399TSSKJS3WN2B93LR9NW5CTW9". One more step! For each pair of characters, i.e. "SK", "C5", "TB", ..., switch the two characters. In this case you'll have "KS5CBT93T9SSJK3SNWB239RLN95WTC9W". And look! That's the signature in the INI file! I've attached a VI that does this for you, minus the step of concatenating the INI values. Just pass the VI a string and it will output the signature. Enjoy, but keep in mind the usual warning about using unreleased features of LabVIEW: don't use it for anything too high-stakes. Generate PPF Signature.vi EDIT: To make this process easier, I have also written a C# program that will automatically sign an INI file for you. Just drag and drop the INI file onto the EXE, or use the command line to specify an output filename as well. Both the source code and EXE are included here. SignPPFPlugin.zip Also, here's some palette files for the PPF's API VI's. Since they won't all fit on one page, I did some very simple categorization, simply creating separate menus for "Get" functions, "Set" functions, and one for all the others. Extract the ZIP file to menus\Categories\Addons, and then just put it in your palette from the palette editor. PPF Menus.zip Finally, here's a tool that will automatically generate the interface VI's for you. I found it annoying to always have to update them. Basically they're just VI's that output a cluster with a bunch of paths to "method VI's", which are basically the PPF equivalent to XNode ability VI's. So this will just search for method VI's in the same folder, and generate an interface VI for you through scripting. I called it "PPF Assistant" in case I ever decide to add stuff to it for other PPF-related tasks. This requires OpenG, as well as gb119's Scripting Tools. PPF Assistant.zip EDIT2: Looks like the PPF was recently officially made public (though still not supported) including NI's official INI signing tool. Glad my thread here could be of assistance to the people having trouble with that tool!
  48. 6 points
    enableSecretPopups - I put this token into LabVIEW 2011 for Silver control development, as a quick-and-dirty way to make low-level control edits. I've been giving it out to people on a very limited basis, but I guess since it's out here I'll widen the audience. I show a screenshot of the new menu items in https://decibel.ni.com/content/docs/DOC-17431 Once this token is enabled, you'll be able to see the settings on parts of the Silver controls to get an idea what they do. eg "Left Move" means the part will move left when its "master" part changes size via moving its left edge. "Left Grow" means the part will scale in that situation. Setting both the left and right move options will make the part stay centered. There are clearly combinations that don't make any sense and I suspect LabVIEW will behave badly if you use them. I recommend that you disable the token when you're not using the Control Editor, because it also enables other menu items that are not ready for prime time and you might use them later without realizing they're only there because of this INI token.
  49. 6 points
    Guys, guys, I for one am delighted at the increasingly barren "new features" list for each LV release. I've been using LV for many years and have grown to love hate accept many of its idiosyncracies as being de-facto standards. Bugfixes are cool, new features = new bugs. I don't like bugs and as much as I'd love Interfaces for LVOOP and a host of other things, at the moment, bugs and stability issues are my main source of pain with LabVIEW at the moment. Daily crashes, huge delays when editing VIs in projects used on multiple targets simultaneously.... LV needs major repair work. We would all most likely agree on that. The 20+ year old code base is no longer an adolescent and really needs to get its act together. There are certain kinds of petulant and stubborn behaviour which may be acceptable for a teenager, but at the tender age of 28, its time we raised our expectations. Minor rumblings from NI (and quite possibly some optimistic pattern recognition on my part) have led me to have some hope that this process of repair or self-improvement is already underway. I for one look forward to the day where all of the fixing in the background can finally be accelerated because a lot of the old crap (there's no other word for it) has been cleaned out and the source code for LV is finally in better shape. As someone who has been crying for better stability for years, I am delighted to see shorter and shorter "new feature" lists because I'm optimistic and believe the time spent NOT implementing new features has been used for a much more valuable long-term goal. So my message is, have faith. PS Yeah, I wrote behaviour with a "u". I won't give in to the LAVA spell-checker. I won't..
  50. 6 points
    I needed this for a project a while back...in my case, it was an array of pictures with zero borders (and no array element borders either). Here's a VI containing the array of borderless pictures, saved in LabVIEW 2013. Array of borderless pictures.vi


×
×
  • Create New...

Important Information

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