Jump to content


Popular Content

Showing content with the highest reputation since 10/18/2019 in all areas

  1. 4 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.
  2. 3 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.
  3. 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/)
  4. 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.
  5. 2 points
    Where can I sign the petition to hand over NI's social media accounts to you?
  6. 2 points
    Well there could be two that apply! "Killing me softly" and "Ready or Not, here I come you can't hide" 😀
  7. 2 points
    As a package creator I would like to be able to see how many people have downloaded my package.
  8. 2 points
    The only correct, intended, non-hack ways to get a reference to an existing clone VI is to use the "This VI Reference" node on the clone VI's own block diagram and have the clone send that reference to someone else as part of its own execution. Any other mechanism was never intended to work and is generally unstable outside of very specific use patterns. There is one mechanism available, and I requested that R&D leave it working even though it can be unstable, and that is the Open VI Reference node when you pass a string. You can pass the qualified name of the original VI followed by a colon followed by an integer to get a reference to that specific clone. The big big big caveat is that you need to close that reference before the clone is disposed. This technique is used by the LV Task Manager, and that tool is the only reason that this feature remains instead of being fixed as a bug. Unfortunately, it really isn't possible to make this feature stable without a significant performance hit on calls to clone VIs. It wasn't intended to work, which is why there's no official way to do it, just the devs forgot to close Open VI Reference loophole. Even if you do get a reference to one clone, any properties you set on that clone while running will be set only on that clone. Likewise, anything you set on the original VI ref will only be set on the original VI (with exception of breakpoints). LV has intentionally never created a "me and all my clones" ref (the reasons why are a topic for a different discussion thread). If you make changes to the original VI BEFORE the clones are replicated, then the clones will have any changes you make. That generally means never calling the original VI as a subVI and instead always calling it through Call By Reference node.
  9. 2 points
    It depends what you want to do with the memory and how but in principle it is pretty easy. This function will simply return error 2 when the allocation was not successful. The challenge is to use this allocated buffer with built in LabVIEW functions. Depending on what functions you may want to use this with, you could for instance pass in the buffer in a VI in which you read the binary file in chunks and copy each chunck into this buffer with the Array Replace Subset function. Memory management is a bitch and you have to often choose between preallocating memory and passing it all the way down a call chain hierarchy to use it there or to let the low level functions attempt to do it and pass the result up through the Call Chain. LabVIEW chooses for the latter and that has good reasons. The first is a lot more complicated to implement and use and has generally less performance since you tend to copy data twice or more (when using streams for instance which at each data direction inversion will usually involve a data copy). Allocate Array Buffer.vi
  10. 2 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".
  11. 1 point
    Merry Xmas:Symlink.llb
  12. 1 point
    Turns out there is a way to do it from within the IDE without mucking about with copying files etc (100% not obvious though). I stumbled on this totally epic write up/demo by Matthias Baudot. https://www.studiobods.com/en/niweek2019-ts170/
  13. 1 point
    I'm favouring just freeze the name, as that is simplest for the User to understand, given that it is difficult to diagnose, let alone fix, any problem if the name adaption goes wrong.
  14. 1 point
  15. 1 point
    Well, in case you ever consider going that way, I'll recommend you start by looking at the LinkIdentity parts of the code Another vector for information could also be to look at the codestreams in the "Ned, the friendly debugger" interface. While I haven't peeked much at Flarn's later progress, I do know that NED will let you switch the format of some VI resources into XML (Heap Save Format) - dunno if Flarn is utilizing that?! (be warned though - this will most likely certainly cause LabVIEW to crash if trying to load the VI afterwards) Also, for quick low-level access to the Resource Fork of LabVIEW VI's and a lot of other NI resource files -from inside LabVIEW- I suggest using the REdLoadResFile/REdSaveResFile (interface)functions found in LabVIEW.exe. That at least cut away one level of abstraction for me, back when I had the time to immerse myself in this kind of 'research'. Now off to figure out the "Keep code streams for heap peek" option..
  16. 1 point
    You are calling Open VI Reference using a path that points to your hard drive (D:\DEBUG\debug\vi_01.vi). That VI is not inside your executable. It is possible to make this work, but your executable will break if you move the VI on your hard drive. It is safer to open a strictly-typed Static VI Reference. This loads a copy of Vi_01.vi is stored inside the executable itself: For more info, see https://forums.ni.com/t5/LabVIEW/Static-VI-Reference/td-p/3334006 http://zone.ni.com/reference/en-XX/help/372614J-01/glang/static_vi_ref/
  17. 1 point
    I love it when old posts come up and I simply can't remember writing them, but my name is on it, so it must have been me..... No, no tricks. Haven't done that in years. It was for simply LVLibs, no classes, no hierarchies. LLBs don't play well with classes (no sub-folders, no ability to store multiple VIs with the same name). I suppose the PPL is the proper replacement for this now, although that's not source code....
  18. 1 point
    As a contributor to other packages I would like acknowledgement for those contributions. This was from our user group and the general idea was that package owners can build a self-brand of sorts by being attached to popular packages but if someone makes significant contributions to many successful packages there should be some sort of recognition. I think the OpenG libraries are a good example where there may only be one owner but I'm sure there were some large contributions from several people that led to the overall success of the project. I don't know the best way to do this but the simplest might be to have a list of projects that you are a major or minor contributor to. You might be regarded as a minor contributor for any packages which you submit any meaningful code (some bug fix or new feature) while being a major contributor might be an acknowledgement from the package owner. In my mind a package may have a field for major contributors and the package owner could curate that list and link to other users.
  19. 1 point
    In general you are working here with non released, non documented features in LabVIEW. You should read the Rusty Nails in Attics thread sometimes. Basically LabVIEW has various areas that are like an attic. There exist experimental parts, non finished features and other things in LabVIEW that were never meant for public consumptions, either because they are not finished and tested, an aborted experiment or a quick and dirty hack for a tool required for NI internal use. There are ways to access some of them, and the means to it have been published many times. NI does not forbid anyone to use them although they do not advertize it. Their stance with them is: If you want to use it, then do but don't come to us screaming because you stepped on a rusty nail in that attic! The fact that the node has a dirty brown header is one indication that it is a dirty feature.
  20. 1 point
    So I'm upgrading from LV2016 to LV2019. Or attempting to, anyway. I have to use the offline version, and it keeps bailing at something like "ni-opc-support", and giving me a very unhelpful, "check your internet connection" message. Hello, this is supposed to be an offline installation?!? My other complaint is that I've installed every version of LV since 2.5 in a "LabVIEW" folder -- no version number added -- and I can't figure out how to make the NI Package Manager let me do that. So I've ended up with 3 or 4 different LabVIEWxxxx directories (depending on how far things get before the install crashes). And if I completely uninstall all NI software, NI Package Manger still thinks it's installed and won't reinstall, but since it's not really there, there's no way to fix it. I'm on my third hard drive copy. Hmm. Sorry, I didn't mean to turn this into a b!tch session. 🙄 My question is whether or not I should uninstall just LabVIEW 2016 (leave everything else on there) before attempting to upgrade? I'm not sure how much I have to take off to get a "clean" enough install, but not too "clean". If that's even the problem. And on a "funny" note, I just saw that LV2019 SP1 was released last week (I've been using 2019 f1). I'm downloading the offline version at the moment. My screaming fast work network is telling me I only have 3 days until the download is complete... Cat
  21. 1 point
    It really depends on what you are trying to do so I get that. For me even just setting the VI file to read-only would be enough, but I ran into a few times when a mass compile would want to overwrite the VI despite it having separate compile code, but that was years ago. For me the purpose was that a developer would be drilling into the code and not realize they were in a reuse function and would start messing around with it and changing things that will now make the program behave differently on one developers machine, than the others. A gentle reminder to not mess with something was all we needed. But I get your points.
  22. 1 point
    Oh yeah I forgot about that. This is the Salt that gets applied to the MD5 of the password. Starting in 2012 NI started salting the block diagram passwords. The salt that gets applied is something like the number of all String, Path, and Numeric controls connected to terminals. I think this does go into clusters and arrays so the work actually needs to be recursive. This ends up being a 12 byte salt, but I think 9 bytes are always 0. Of course you don't need to do all of this, to figure out what the salt is. I mean all you need to do is guess three numbers, all of which are the number of controls on a terminal so you know that the value will probably be small. So when I wanted to figure out what the salt was I would just keep guessing until a match was found. It was easier than trying to look into the VCTP block to find all objects, and then all terminals, and blah blah blah. If you have a VI that is passworded correctly then the only unknown in the equation is the salt. I mean lets use this example equation (note that the actual one is different): Result = MD5(Hash 1 + Hash 2 + Hash 3 + Salt) In a valid passworded VI I can pull out each of the variables from the VI other than the salt. So I just made a VI that sets salt to 0,0,0, then 0,0,1, then 0,0,2, etc, until the equation matches. Fun story: Years ago we were in a meeting with a few LabVIEW champions and LabVIEW R&D and the discussion of protecting intellectual property came up. Someone was asking NI about ways they could tighten up their security. I made a suggestion of encrypting the password with the number of string terminals in a VI, knowing that this was something NI already was doing. Another LabVIEW Champion said that was a bad idea since that could be figured out by simply opening the VI and looking at it. I had to inform them that I said that knowing that that scheme was actually used by NI, and I put that out there to subtly let R&D know we know about it.
  23. 1 point
    What's the reason for moving to Github? I was using Kiln to host my code, which used Mercurial. I switched to Bitbucket with Git. I had to migrate many projects from Mercurial to Git. I did the migration using the HG-GIT extension: https://hg-git.github.io The main problem I encountered was using the "large files" Mercurial extension. The automatic import tools provided by GitHub and others don't like that extension and barf. Otherwise you can use the web migration tool provided by GitHub. My workaround to the large files problem was to accept the fact that I will lose the revision history on those files. Not a huge deal, since most large files I had were installers and binaries that didn't have revisions per say. So after the migration I did a diff on the project folder, identified the large files, which were missing from the new Git project and just copied them over and pushed them up to the Git repo. Don't forget that the core GIT functionality is the same regardless of service provider. So let's say you found a way to import your repo to GitHub, you can easily turn-around and move it to GitLab, bitbucket or whatever. You're not locked-in. But it might be an issue if you are using an extension that only one service provider supports. The future is GIT. I made the jump over a year ago and haven't looked back. The service provider you choose should give you the tools you need to do your job. The reason I picked Bitbucket was because I liked and used all the other products that Atlassian provides, JIRA, Confluence etc. The tools from Github are a bit weak for my business. I also like companies that continuously improve and invest in their products, among other things. Github seems to be the popular choice for open-source, since that's how it got started. Now that Microsoft owns them, perhaps they don't have to worry about generating revenue (don't know if it's good or bad). But I don't see features that compare to what Atlassian offers.
  24. 1 point
    Thanks for the heads up, this completely went by me. Here is the official blog post from Bitbucket if anyone is interested: https://bitbucket.org/blog/sunsetting-mercurial-support-in-bitbucket
  25. 1 point
    You should post a topic on LAVA sometime explaining how you use Teststand and Messenger Library. I have not had the pleasure (or is it torment?) of seriously using Teststand.
  26. 1 point
    If that doesn't work you may have to separate the TestStandAPI calls out. Are you using your TestStand Actor as a GUI or user interface? If so you may have to create another Actor to separate out the TestStand API calls that are causing the log jam into a new Actor....That new actor should not have any property/invoke nodes which would force its VI into the UI thread.
  27. 1 point
    By default, subVI are set to "Same as Caller" execution system, but they can be a specific system instead. I suspect it might be just the subVI that does the TestStand call that needs to be in a different Execution System, not the calling Actor.vi itself. So try just changing the subVI.
  28. 1 point
    If you grew up on Fortran I would have hoped they had let you retire by now. No rest for the wicked?
  29. 1 point
    Sssssht! My first version was without that sequence structure and I was for a brief moment wondering if maybe my ability to do the pointer juggling had failed me. After looking over it once more I figured the problem must be elsewhere and then it struck me that the control assignment was happening right after the NumericArrayResize() call. LabVIEW has a preference to do terminal assignments always as soon as possible.
  30. 1 point
    Sounds like a good idea if your goal is to get other programmers to hate you.
  31. 1 point
    Did this today (and any other day I write C). for (int i=0; i < len; i++){ The big question is .. should it have been "a" instead of "i"?
  32. 1 point
    Right, VI Analyzer Toolkit 2016 was the first version to officially support 64-bit LabVIEW. For unofficial support in previous versions, we have this resource: https://forums.ni.com/t5/VI-Analyzer-Enthusiasts/Using-the-VI-Analyzer-Toolkit-with-64-bit-LabVIEW/ta-p/3494395
  33. 1 point
    Yes, it's a LabVIEW Toolkit, which means you have to install it separately for each LabVIEW you have. Here's the download page where you can get whichever version (and bitness) toolkit installer(s) you need: https://www.ni.com/en-us/support/downloads/software-products/download.labview-vi-analyzer-toolkit.html
  34. 1 point
    A framework's artificial complexity is only from the things that the framework forces on your code, not the options that it enables if you choose to buy into it. AF and DQMH without priority queuing are no more or less complex than AF and DQMH with priority queuing. The priority queuing only becomes a part of the complexity computations if "priority" were a required input and you had to send some messages at a non-normal priority. Because you can use both frameworks entirely without ever using priority, it isn't part of the computation. It is an option that you can choose to exercise in your code or not. "If you buy it, you pay for it" features don't add complexity. "Comes with the territory" features add complexity. The requirement to create a class per message: that is complexity of the AF. The ability to send high-priority messages is not.
  35. 1 point
    That is a weird, though undeniably literal, interpretation of the words priority queue. You must get into a lot of arguements at the supermarket checkout.
  36. 1 point
    Hi Rolf That's good feedback. The current UI \ UX is just a proof of concept. Once we start designing the actual UI \ UX we hope it'll be efficient to use and pleasant to look at. One other note: the indexer is open source. Please feel free to suggest adjustments by joining the dev team on GCentral's git repo. Keep in mind GCentral.org is in its infancy so we're choosing to sacrifice aesthetics for functionality to avoid bikeshedding. Glad to hear you think GCentral is a good initiative and thanks for your thoughts!
  37. 1 point
    Here is a beta version, 1.11.0, with changes to TCP Messengers to support the various TCP options about ports and the like. Also adds a Keep-alive to detect half-open connections. Bitbucket Issues 26, 27, 33. I have not had time to do more than a basic test; it would be a help if someone could give it a try. Note that I've replaced some of the creation VIs for TCP Messengers in the pallette (originals should still work, but I wanted to change VI names). drjdpowell_lib_messenging-1_11.0_116.vip
  38. 1 point
    KJK@GPower reports on the NI Forums (link unavailable without tech preview, but posting here because largely unrelated to tech preview and so perhaps not covered by non-disclosure?) that: "I know that the GCentral will be the place to go for finding reuse code what I'm not sure about is if there will be an active forum where [users] can get help and support from the G-Community." So perhaps: As a user of GCentral, I (might, if I were KJK@GPower, or the person they responded to) want to discuss using a package with the creator of that package (and/or other users) via a discussion page or forum system.
  39. 1 point
    I would imagine the string (or u32 Net Address 2130706433)
  40. 1 point
    Relating to this, as a developer who might use open source code, I would like to be able to avoid installing (potentially obscure) test frameworks and similar to test code that I for whatever reason (author, company, etc) implicitly trust. I suspect this has a lot more to do with the packaging chosen though, and may not be easily manipulated by GCentral...
  41. 1 point
    As a developer that works in development environment that is not internet connected I would like to be able to download packages and put them in a local repository.
  42. 1 point
    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
  43. 1 point
    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.
  44. 1 point
    Obligatory Bobby Tables reference
  45. 1 point

    Version 1.10.6


    An extensive library for passing messages between parallel processes. Generalizes the communication method, allowing the message sender to use the method provided by the receiver. Supported communication methods include wrappings of simple queues, user events, and notifiers, as well a more complex channels such as a TCP server and client. In addition, one can configure simple forwarding addresses (“Observers"), which can send messages to multiple destinations, optionally with modifications such as adding a prefix to the message label, relabelling, or substituting a different message. Communication patterns supported include request-reply (asynchronous or synchronous), where the reply is sent to a "reply address" attached to the request, and register-notify, where one process sends a registration message to another in order to subscribe to a series of updates. Also supports scatter-gather, the gathering of replies from multiple senders into an array of messages. An option framework for dynamically-launched VI "actors" is also provided, including example templates, which can be accessed via the Tools menu (from an open Project, select Tools>>Messenger Library>>Create Actor from Template..). An "Actor Manager" debug tool is also installed under the Tools menu. Please note that this package has nothing directly to do with the NI Actor Framework (other than both packages are influenced by the Actor Model). ***Introductory Videos are on a YouTube channel.*** ***A great summary of many Messenger Library sources, provided by Bob W Edwards*** Original conversation on this work is here. Now hosted on the LabVIEW Tools Network (but note that the latest version will often be on LAVA) ***NOTE: latest versions require VIPM 2017 or later to install.***
  46. 1 point
    Overview In order to quickly and efficiently prepare source for distribution, a build system was necessary to abstract away the conversion of source into the different types of deliverables (VIPackages, Executables, dlls, ect) as well as abstract away the build order of our software hierarchy. Many have undertaken to solve this problem. I don't claim to have created a silver bullet. But I do hope that the system I've put together (and am releasing as open source) will act as a starting point for you to extend and customize to meet your needs. I've endeavored to employ good software development principles including separation of concerns, and the SMoRES principles. I'll be the first to volunteer that it isn't perfect and as always, our best software is constantly a work in progress. However, I believe the build system is at a stage to be at least moderately helpful to a handful of people in our community. Description The Application's UI The UI is designed to guide someone through the build process, allowing them to select what components or exports they would like to build, if and how they would like to be notified about the build, auto submission options, and source code control. I've attached a small video titled "Build UI Demo.mp4" below. UML and APIs All UML and API documentation are included in the Word document per released zip file Software Requirements LabVIEW 2017 NI Application Builder VI Package Manager Pro Other dependencies are listed in the Instructions per zip file. UML Overview As of 1.4.0-58 the UML looks like: Build UI Demo.mp4 Release Notes 1.4.0-123 (Component Builder 1.4.0-123.zip) Added new NI Package Manager API Added new NI Package Manager BuildSpec Utils Added procedure and documentation for the component template and its anatomy 1.4.0-113 (Component Builder 1.4.0-113.zip) Added documentation for the SCC API 1.4.0-111 (Component Builder 1.4.0-111.zip) 1.4.0-99 (Component Builder 1.4.0-99.zip) Added a few new P4 API functions allowing the creation of a session if a user is already logged it. Added Log in and log out tests to the test suite. Adding new function to tag all p4 paths in a label with the label. Resolving the input path to a p4 depot path Adding quotes around p4 paths. 1.4.0-91 (Component Builder 1.4.0-91.zip) The refactor of the LabVIEW SCC API is complete and the build process is linked to the new install location. The LabVIEW SCC API can now be used independently of the Component Build process. I've included a test suite for the P4 implementation of the SCC API. It assumes that you have checked in the two files in the "Build Instructions\LabVIEW SCC API\Test Suite\Tests\Test Dir" into perforce. 1.4.0-85 (Component Builder 1.4.0-85.zip) This is a major refactor in the SCC API. I've modeled the p4 label with a new api. This release is primarily as an intermediary release. I intend on breaking SCC out of the component builder into its own separate component in the next release. 1.4.0-81 (Component Builder 1.4.0-81.zip) Created a "proxy" api for VI Package manager interactions. Sometimes the VI Package manager api would hang. So I now call by reference and will kill and restart VIPM if it doesn't respond in time. 1.4.0-75 (Component Builder 1.4.0-75.zip ) Fixed reference counting for executable builds. 1.4.0-73 (Component Builder 1.4.0-73.zip) In the case where a user has specifically unchecked "auto increment", the build process will auto increment the build. Builds must be auto incremented. I've released a new build of the container that has a minor bug fix. Added file utility tools to aid with using "net use" to move and copy files across the network. 1.4.0-59 (Component Builder 1.4.0-59.zip) Minor spelling error in component template: "componet". Added documentation for the Custom Install Step Launcher. Added build instructions for Custom Install Step Launcher. 1.4.0-58 (Component_Builder_1.4.0-58.zip) Added the ability to export NI-Source Distributions, NI-Executables, NI-Insatllers, and NSIS Installers Released a template component that exports an NI Package and VI Package including step by step instructions Released "Custom Install Step Launcher" to execute VIs as pre install, post install and post install all actions for NI Packages. Released comprehensive documentation included in the zip file. Component_Builder_5_31_2018.zip Component_Builder_10_11_2018.zip
  47. 1 point
    There is still no way through scripting to replace the decals on buttons to use a different image. But using some known LabVIEW calls we can extract the image and replace it, then save it with a new file name. This has been done several times replacing the PNG image data in the CTL file. The problem I have with this is PNG images don't scale well. If I have a PNG that is 16x16 pixels on a small button, and I happen to want to make this button for a larger touch screen UI, I can but the image will look poor. LabVIEW does support some vector images mainly the EMF and WMF file formats. So using an external program Inkscape, I wrote some code that will take an SVG file (which is vector based) convert it to an EMF, and replace the decals of buttons, as well as give the CTL a PNG icon, label, and boolean text. I recently re-discovered a website that has all kinds of useful flat icons, and makes them available as SVGs. So all that is needed is to download Inkscape, download an SVG, and run a VI that I've attached. In the zip is some Example Controls I've generated using the SVGs from the Essential Collection which make controls based on 6 different templates. The JKI Flat Dark/Light, the Flatline Dark/Light, and the System Vertical and Horizontal controls. The main VI is in Replace Button Decals\Create Control from SVG.vi. I could see this being used on a repository of SVGs at some central location like a network drive, and then call something like Tools>>Generate Controls which shows a database of icons, and control types, and then generates them, rather than generating tons of controls that might never be used. Oh and I did find this pretty handy program that allows for viewing SVG images in Windows Explorer. It really helps to be able to see the icons and organize them before generating controls. Vector SVG Controls.zip
  48. 1 point



    There it is... finaly... Because the code given in the FTDI web page is not convenient, not working and haven't been developed by real LABview programmer, I decided to create a library for the I2C. a version for SPI will come soon. This library is free to use. If FTDI want's it in ther site, I do not allow you to publish it since you didn't help any of your customer with LABview. but of course feel free to publish this link.
  49. 1 point
    I have created a new package with an updated version of the OpenG ZIP library. The VI interface should have remained the same with the previous versions. The bigger changes are under the hood. I updated the C code for the shared library to use the latest zlib sources version 1.2.8 and made a few other changes to the way the refnums are handled in order to support 64 bit targets. Another significant change is the added support for NI Realtime Targets. This was already sort of present for Pharlap and VxWorks targets but in this version all current NI Realtime targets should be supported. When the OpenG package is installed to a LabVIEW 32 bit for Windows installation, an additional setup program is started during the installation to copy the shared libraries for the different targets to the realtime image folder. This setup will normally cause a password prompt for an administrative account even if the current account already has local administrator rights, although in that case it may be just a prompt if you really want to allow the program to make changes to the system, without requiring a password. This setup program is only started when the target is a 32 bit LabVIEW installation since so far only 32 bit LabVIEW supports realtime development. After the installation has finished it should be possible to go in MAX to the actual target and select to install new software. Select the option "Custom software installation" and in the resulting utility find "OpenG ZIP Tools 4.1.0" and let it install the necessary shared library to your target. This is a prelimenary package and I have not been able to test everything. What should work: Development System: LabVIEW for Windows 32 bit and 64 Bit, LabVIEW for Linux 32 Bit and 64 Bit Realtime Target: NI Pharlap ETS, NI VxWorks and NI Linux Realtime targets From these I haven't been able to test the Linux 64 Bit at all, as well as the NI Pharlap and NI Linux RT for x86 (cRIO 903x) targets If you happen to install it on any of these systems I would be glad if you could report any success. If there are any problems I would like to hear them too. Todo: In a following version I want to try to add support for character translation of filenames and comments inside the archive if they contain other characters than the ASCII 7 bit characters. Currently characters outside that range are all getting messed up. Edit (4/10/2015): Replaced package with B2 revision which fixes a bug in the installation files for the cRIO-903x targets. oglib_lvzip-4.1.0-b2.ogp
  50. 1 point
    I've made a recent entry on the Idea Exchange about this. Here’s the VI I’m experimenting with, referred to in that link: Array of Variants to Cluster of Variants.vi It converts arrays (up to size 50) into clusters of variants, which can be then converted to clusters.

  • Create New...

Important Information

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