Jump to content

Leaderboard


Popular Content

Showing content with the highest reputation since 09/15/2019 in all areas

  1. 7 points
    I've exported the OpenG sources from Sourceforge SVN to Github. It's located here: https://github.com/Open-G I'm hoping this will encourage collaboration and modernization of the OpenG project. Pull requests are a thing with Git, so contributions can be encouraged and actually used instead of dying on the vine.
  2. 5 points
    @Jim Kring, it seems to me that the export of the code has gotten a positive response from the community. However I may be wrong. If anyone has any opinion either way, please come forward. As you can see in this thread, it appears the community has rallied around this effort. This is why I emailed you to come here and share your thoughts. In the past, OpenG was a great venue to showcase how a bunch of passionate LabVIEW users can come together and collaborate on something useful. The passion is clearly still there, as shown by the numerous discussions here. The general coding community has moved to Git with GiHub being the hub. This seems like the logical next step. Who knows what this initiative will lead to. However, I’m expecting that placing OpenG in a neutral GitHub repo will provide the spark and the tools to facilitate open collaboration, then the community can drive the future. The community is full of smart people who have a desire for clean tested code. And if issues come up, LAVA discussions (or GitHub issues) are there to hash things out. When LAVA offered to host all OpenG discussions back in 2011. it was clear that the community wanted to help. When @jgcode put his standards together for how code should be discussed at that time, It was an exciting time. Since then, many people have come forward with offers to add new code into OpenG and fix bugs. For example @drjdpowell first offered to include his awesome SQLite toolkit for inclusion into OpenG. He got no response either way. It’s a shame to have a platform and forums to allow people to post and discuss OpenG code and then ignore it. If you have ideas on what the future of OpenG is. I’m hoping it’s to be more transparent and inclusive. Providing the tools, resources and some safety checks along the way, is the best way to facilitate passionate individuals to dive in. Do you think keeping the status quo of the past 10 years makes sense? It seems to me that the community disagrees. What do you think?
  3. 4 points
    As someone contributing code on LAVA, I would like to see the certified LAVA repository packages made available through the GCentral package search tool.
  4. 3 points
    It is good to finally see some movement in OpenG. Git and GitHub are also the right choices (Bitbucket would probably also work). Even novice programmers will be able to participate this way. 👍 That said, the current repository has a few problems: No tags No branches All projects in one repository Changed commit messages (the links in the commit messages are non-functional) It is possible to transform an SVN repository into a Git repository while maintaining all tags and branches and updating the committers (because Git uses email addresses and SVN doesn't). Here are some instructions I used in the past for such jobs (instructions are for Linux of course): https://epicserve-docs.readthedocs.io/en/latest/git/svn_to_git.html For OpenG this process is a bit more complex because of the way the repository is structured (i.e. tags inside folders for each project), so the scripts must be adjusted to take this into account. I also suggest splitting the project into multiple repositories during this process to improve maintainability (unless there is a reason why it needs to be one repository). I could prepare the scripts to automate this process if you are interested.
  5. 3 points
    As a company that uses LabVIEW and has it's own existing internal repository for reuse code, I would like a way for my developers to discover packages in G Central and in our private reuse repository, all from a single portal.
  6. 3 points
    We use a variety of frameworks/templates/patterns for our architecture: The Actor Framework is used for asynchronous UI operations and long-running data processing tasks. Queued Message Handlers (not using DQMH or QMH template) handle simple asynchronous tasks. Action Engines encapsulate privately shared data for our translation and general I/O libraries. (Queued) State Machines ensure that everything runs in order. The proxy pattern is used to interface most customer libraries. We have our own frameworks for the test execution engine and test libraries (message based). I find the publicly available frameworks and templates (DQMH, Messanger Library, NI templates, etc...) very valuable for learning and to get things started quickly. More advanced projects, however, require a deeper understanding of the underlying patterns in order to develop your own architecture (which may or may not utilize these frameworks/templates). In your case these are synonymous 😋 "Any sufficiently advanced technology is indistinguishable from magic." (Arthur C. Clarke) For some reason that just popped into my mind... If your entire architecture and thought process is fundamentally based on actors, any small project will of course have to depend on it as well. That is, unless you are willing to rethink (and probably reimplement) the fundamental architecture. Then again, why reinvent the wheel?
  7. 2 points
    According to the activity log @Rolf Kalbermatter is the only active user for at least the past 6 years (log ends there): https://sourceforge.net/p/opengtoolkit/activity/?page=1&limit=100 @jgcode compiled a nice list some time ago. Not sure if all of these are done yet: Here are some ideas that come to mind: Allow the community to participate in the project (create and maintain tasks/issues/features, add maintainers, add admins, etc...) Bring back openg.org (could be a different domain) and allow the community to contribute to the site via pull requests Split the monolithic repository into separate repositories for each project for best practice (and to prevent linking between projects) Convert the SVN repository to Git to allow offline branching, pull requests, etc... Use tags when releasing new versions, this allows everyone to use a prior version if needed. Add documentation for how to deploy new versions (the building process). Add documentation about which LV versions to use and what tests to perform before opening a pull request. Use a single license for all projects. Add a CLA to ensure the license holds for all contributions Work on Feature requests, bugs and change request (there are a lot) Share your thoughts SF is a good place for a small team of developers, working on their project. Users are only meant to report issues and make feature requests. All development is taken care of by the admins/maintainers. Although there are ways to do pull requests, they are very inconvenient and tend to scare potential contributors away. In my own experience, there are a few ways to revive a project like this: Get the original admins back to the project (unlikely, they left for their own reasons) Add new admins/maintainers who have full authority over the project => Requires at least one responsive admin / SF is difficult for contributors (compared to GitHub) Do what @Michael Aivaliotis did. Archive the original code base, move to a simpler platform and build on top of what is currently available. Option 3 is most likely to bear fruit.
  8. 2 points
    I and the whole rest of our LabVIEW community are the ones with the vested interest in OpenG. To me, the new github location looks less like a fork and more like reviving the project. LabVIEW isn't my day job anymore, but it is still my nights-and-hobbies job, and I welcome any action that brings things back to life. For instance, I took a look at JKI's OpenG-NXG github project, and there hasn't been a commit to any branch in over a year, and not to master in 3 years.
  9. 2 points
    The simplest way is to add "@users.noreply.sourceforge.net" to make them valid addresses that don't collide with any existing GitHub user (GitHub and SF both support these). It should be sufficient for this task. Here is my version: https://gist.github.com/LogMANOriginal/c4109873a5d524387d3fb46f5b83aa0a I agree. From what I can tell the reason it didn't work correctly is because each project has its own branch/tag subfolder. None of the standard systems support these (including git-svn). Find below a solution that can handle them. Done, see below. Sorry, my explanation wasn't very clear. My point is, that the original commit message actually doesn't have these URLs inside (see SF vs. GitHub). It was probably added during the Atlassian conversion process. Here you go: https://gist.github.com/LogMANOriginal/fa1e59703c41e27758bcb935f15bea21 The script must be placed in an empty folder next to 'authors-transform.txt'. It must be marked as executable (runs in bash, not sh). svn and git must be installed of course. Then start the script via './openg_import.sh' and it should work (unless it breaks of course). It does a few things: Lookup all projects, branches and tags Import all projects into dedicated Git repositories Cleanup the Git repository (i.e. tags are imported as branches, so they need to be fixed) The output are 39 bare git repositories, one for each project with full history, branches, tags and commits. Enjoy 😉
  10. 2 points
    I followed these instructions: https://www.atlassian.com/git/tutorials/migrating-overview I did that because my goal initially was to export to bitbucket, which I did. Then I changed my mind and decided that Github would be better for a community project like this. So then, since it was already in a Git format it was simple from within the Github website to select "import" and just point to the Bitbucket URL. Note: Those instructions work best if executed from a linux machine. I quickly spun-up an Ubuntu VM to do this.
  11. 2 points
    Add SuperSecretListboxStuff=True to your labview.ini , reload LabVIEW new menu items will show up when you right click on MLC control. Read this thread
  12. 2 points
    I just tested on a fresh 2019 machine and I also needed SuperSecretListboxStuff=True in my INI.
  13. 2 points
    As a community member and package consumer I want to support your efforts.
  14. 2 points
    The following slide was just presented at the CLA summit:
  15. 1 point
    Not out of the box. 32 bit LabVIEW interfaces to 32 bit Python. So you would need to have some 32 bit Python to 64 bit Tensor Flow remoting interface. If 64 bit LabVIEW is a requirement the lowest possible version is 2009 on Windows and around 2014 on the Mac and Linux platforms.
  16. 1 point
    Linux ODBC or iODBC or unixODBC work in principle. The idea is not bad but hampered by the fact that you need a compiled version of a database ODBC driver for your platform. As that is not generally something all database providers are eager to do, it makes unixODBC less interesting overall. In cases where you have a native driver like FreeTDS I would usually consider that preferable to trying to get unixODBC to work. unixODBC is an extra complication on top of a driver and the ODBC manager implementation is pretty complex in order to provide version compatibility between both higher and lower version ODBC clients and higher and lower version drivers.. This makes setting up a unixODBC installation more cumbersome. On the upside is of course the advantage to only have to interface to one API and connect to different databases simply by reconfiguring the connection.
  17. 1 point
    The SQL Server protocol has been reverse engineered as it is based on the old Sybase Tabular Data Stream format that Sybase did document at some point in a public document. Microsoft licensed the Sybase code and eventually created the SQL Server product from that. The underlaying network protocol is still very much the original TDS format with some extra features sprinkled into it by Microsoft over the years. This is the MS document from the original Sybase 4.2 version of the TDS documentation. This is a more detailed documentation about the later Microsoft modifications to the protocol. The "official" open source implementation of the TDS protocol is done by the FreeTDS project. Their implementation works also for the more modern 7.x protocol versions used in recent SQL Server versions, but as anything that was reverse engineered (even with proper protocol documentation) there are some obscure features that might not work properly with the FreeTDS implementation. Compiling the FreeTDS sources for a cRIO shouldn't be that complicated. Reimplementing it all in LabVIEW on top of the TCP primitives is theoretically also doable but the encryption features of this protocol will be hard to implement properly in this way.
  18. 1 point
    Not really unless you want to build some very custom stuff into your executable itself. And you would need an executable that does not statically link to the OpenG ZIP library as at the time you start it up, it can not reference the shared library anywhere or the loading will fail and the executable is not executable. To me that sounds like a lot more trouble than it's worth and you have the same issue with NI Toolkits. If you make use of (for instance DAQmx functions) you have to make sure the DAQmx driver is installed onto the target before you can deploy an executable that makes use of it. The Pharlap ETS platform did include some means of deploying shared libraries directly together with VIs when you deployed the program from the project but that may have sounded like a cool thing initially when a Windows DLL was simply executable on Pharlap too, but nowadays most Windows DLLs won't load on Pharlap and have to be created specifically for the Pharlap ETS target. For non Windows like OSes like the NI Linux RT system, where the elf shared library is all but Greek for the Windows based LabVIEW environment, this is even more complicated.
  19. 1 point
    The OpenG package file is simply a ZIP file in disguise, with an ini style package file (called spec) in the root that describes where the different file groups should go to in your LabVIEW installation and with restrictions for what version and platform they apply for. If you have 7-Zip installed you can right click on a *.ogp file and select 7-Zip->Open Archive. Then look in the directories for "File Group 8" and in there is the ogsetup.exe file. This is an Inno Setup file that installs the necessary packages into the correct NI Shared location for RT packages. I choose to do it this way as the files have to be installed in a location that has only write access when the process is evelated and rather than requiring the user to restart VIPM explicitly as admin (and trying to guess the correct location to write the files to from within a post install hook VI), I created an Inno Setup installer for the necessary files with an embedded manifest that requests elevation authorization from the user. After that and provided you have full cRIO support for NI Max for your target installed on your machine, you should be able to select the package in the Custom Software Install from within NI Max. Basically I choose to only extract the ogsetup.exe file into a LabVIEW 32-bit installation, since this is the only way to program LabVIEW RT programs anyway. I figured that the change that someone would want to install SW packages to a RT target from a computer that is not used to program that target too, would be a very unlikely situation.
  20. 1 point
    Here are some common files that could be helpful: The contribution guidelines are shown for pull requests: https://help.github.com/en/articles/setting-guidelines-for-repository-contributors LabVIEW versions, build instructions and the release process are commonly placed in a README file: https://help.github.com/en/articles/about-readmes The license can be managed in a similar fashion: https://help.github.com/en/articles/licensing-a-repository All of these files, if they exist, add to the GitHub experience. For example: https://github.com/microsoft/vscode
  21. 1 point
    View File Hooovahh Array VIMs Here is the Hooovahh Array VIMs. This initial release contains 14 VIMs for manipulating array data, which are intended to replace OpenG functionality, but with the added benefit of data type propagation, and increased performance using newer array manipulation techniques. In later versions other Array manipulation functions were added moving all the OpenG stuff to their own palette. Most of the OpenG functions are unchanged, but a few use the newer conditional and concatenating tunnels. And a few functions have added performance based on other inputs. For instance the Delete Array Elements can operate in a more efficient way if the input indexes are already sorted. The Filter 1D array can also be more efficient if the input is known to not contain any duplicates. Because these packages contain VIMs, they require LabVIEW 2017 or newer. Having these functions be VIMs mean all functions work with various array data types. Included functions are: Conditional Auto-Indexing Tunnel Delete Elements from (1D or 2D) Array Filter 1D Array Index (1D or 2D) Array Remove Duplicates from 1D Array Reorder (1D or 2D) Array Reverse 1D Array Slice 1D Array Sort (1D or 2D) Array Convert 1D to 2D Convert 2D to 1D Find Subarray Force Array Min/Max Size Foreign Key Sort Submitter hooovahh Submitted 10/11/2017 Category *Uncertified* LabVIEW Version  
  22. 1 point
    I have a "rule" something quite basic like "VisionSystemRef_CameraName_BufferType_Index" For the buffer type I have a typedef with a few options : - "Acq" for acquisition only buffer, I never do any processing on these, they are used only to store an image that has just been acquired from a camera - "Save" buffers reserved to store images that will be saved to disk - "Proc" for processing - "Disp" buffers reserved for images to be displayed on the UI So I use the "image copy" VI a lot do to transfer image data from a buffer to another
  23. 1 point
    I've migrated most of the code to Github.
  24. 1 point
  25. 1 point
    I looked at it briefly a while ago and came to the conclusion that it is really a stateful HTTP protocol framework. The underlying cryptographics are very simple (in 2.0) but there are a lot of HTTP states that are different for each method (6 methods in total with varying privlieges, IIRC). So you have to identify which method is being used then have an application go through the the appropriate HTTP process with various redirects. This means that a complete LabVIEW library could be quite unweildy and confusing rather than just using basic HTTP GET/POST in an application to achieve the one instance you are interested in-especially as you may have to use another 3rd party JSON library for responses as the NI one is useless. It's not difficult to create the HTTP messages, it's just the process logic is cumbersome. You can get away with a couple of HTTP POSTS and string stripping if you want quick and dirty but for proper and secure, you need the full stateful operation.
  26. 1 point
    As a user with a CI-system based on building my packages, I want to be able to programmatically update the package version on GCentral (or notify of a new package, or however this might work). This might involve something like a POST request.
  27. 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.
  28. 1 point
    Unfortunately, there is a significant learning curve for all frameworks, so it is hard to compare them. Here though is a GDevCon1 talk by Richard Thomas, where he discusses frameworks: Frameworks: An Executive Summary
  29. 1 point
    Company made version, based on Ref-based OO and active objects.
  30. 1 point
    That's great, I had no idea! I'll take a look at it at least and see if I can maybe come up with something similar.
  31. 1 point
    I don't have good examples to share, but here are a few helpful links for you: NI has an article dedicated to DVRs, which also explains the fundamental idea: http://www.ni.com/product-documentation/9386/en/ Here is a short video that explains how to use a DVR and some of the pitfalls: https://www.youtube.com/watch?v=VIWzjnkqz1Q Of course, you'll find lots of topics related to DVRs on this forum.
  32. 1 point
    Ahh, your illustrating my point. DQMH is similar to SMO in having custom-type "plumbing", with new messages requiring changes in multiple places. AF also has its own busywork of multiple things to do for each message. Now, all this work is highly repetitive and thus scriptable. So you can value the strength of DQMH's scripting tools, because similar tools would be a help for SMO. But from the point of view of Messenger Library, which uses more generic messages, scripting is just a way of reducing one of the weak points of custom data-type messages: all the extra work to carry the new custom types through the communication code. Scripting Tools aren't a strength, they're the minimization of a disadvantage that is shared by DQMH, SMO and AF.
  33. 1 point
    Apologies to JKI for not explicitly including State-Machine-Objects in the poll. Though I think what you compared was two common community frameworks, plus the framework you use, and largely developed, regardless of how common it is. Difficult to make such comparisons, as the stuff-you-know-well usually trumps stuff-you've-read-about. Even getting unbiased comparison categories is hard; I'd probably have "messaging pattern support" and "network communication", two things Messenger Library does well, yet not "Teststand Integration", which I've never tried.
  34. 1 point
    When I had to pick one, the options I considered were : DQMH AF JKI SMO G# ALOHA my own that would be much better than all of the above combined I picked DQMH because I love the API tester the scripting tools, also I feel there is a somewhat large community adoption and support.
  35. 1 point
    I use DCAF for most of the things running on compactRIO. I like it, very easy to write static modules, much harder to write dynamic ones where it works correctly with the configuraton editor, though I have done it. Nice to be able to manage tags with CSV files. My biggest gripe about it is that there is no built in events / messages/ triggers. So if you have a module that needs to perform some sort of sequence that you want to initiate on user command, you have to do something hacky like increment an integer tag, or change a boolean tag's state. I guess you could also do that with RTFIFOs or queues, sending this kind of command data from outside or even inside the framework but I have not invested any time in that, and seems like it would be hard to debug.
  36. 1 point
    SMO. I'm guessing Francois will say the same thing since he wrote a large part of it. Several months ago I was comparing three common community frameworks and I had Francois chime in. I attached a screenshot of what we put together with our rankings obscured. If he's ok with me showing it, I'd love to reveal our rough rankings for the categories shown. My superficial summary of each? Actor Framework - you better love having LOTS of classes in your project and opening DO methods to figure out how the code works. JKI SMO - Use this framework and Steven Mercer will castigate you because no human alive can write code with reference class data that isn't riddled with race conditions and bugs. Honestly though, if you're that worried you can impose some rules when developing with this framework to make it more actor-like. DQMH - The fact that it was developed for customers who don't understand object oriented programming suggests that if an experienced developer wants to combine it with classes that it might be unnecessarily complicated. Sure enough, I watched the presentation on how to do hardware abstraction with classes and DQMH and it confirmed my suspicions. It makes one think about what a framework would look like if your initial design goals were NOT to hide classes from less experienced developers. Turns out that framework might look something more like SMO. In the same project that is using SMO, I'm currently using DCAF at the lower level to manage I/O because there are hundreds of I/O tags. Now that I've spent a fair amount of time developing a variety of DCAF dynamic modules for this project I think I have a good idea of DCAF's strengths and shortcomings. It is open source so if I want some of the bugs and nuisances fixed, I'm going to have to fix it myself. Whoever wrote it got us 80-90% of the way there, but that final polish is going to take a fair amount of work. A lot of the code under the hood just ain't that pretty and some people don't really care about that. I do so I find myself getting annoyed every time I dig into it.
  37. 1 point
    Since 2011 I've been refining what I call Glued (Global User Event Driven) architecture. It is User Event driven using a publisher and subscriber model, with variants and variant attributes as the data containing things like the Request Data, event name, who requested the action, who is to perform the action, and GUID among other things. These parallel actors default to non-reentrant so that probing and debugging is easy (and possible on RT), and don't get spun up or down but instead have a known number of them at test start. They all start at once, and they all stop at once. If an actor needs to restart it can go through the queued message handler states that perform initialization but the only way to actually stop the actor is to stop the application with a global event, which is an event that all actors subscribe to. The actors are part of a Library but not Class. The architecture also supports events that are request only, or ones that will wait on a reply, and can do this by leveraging Futures or Promises. There is scripting tools for generating actors, template projects, or adding methods to existing actors. Manual panels, error actor, configuration actor, and probe actor are included with a template project since the majority of projects I have use them. Actors can be ran as the top level VI and events can be sent to itself. This way individual actors can be developed and debugged without the whole application, and without any other actors needed. Each actor can publish to a Sensor which is a scalar double or a string and is name based, or publish to it's own global which is a variant and can contain any data as a variant attribute and read with VIMs. These globals are read only to actors other than itself. Over the years this has been improved to support remote actors running on other targets such as RT with Network Streams being the back end for this. Requests for action can be sent to these remote actors, and reading the actor's global, or Sensors can also be done locally or remotely. It sounds like a lot of extra bells and whistles and there are times I'll start a new project just doing my own thing from scratch. And every time I've done this I ended up regretting it because some feature was built into Glued that I would have to re-write or hack in my custom project. Over the years I've just convinced myself that even small projects should start with some actor based design.
  38. 1 point
    We use the JKI State Machine, but have begun adding DQMHs. My last project launches up to twelve of them; my current project launches one or two. Both depend upon the number of pieces being tested (and were written by my CLA-colleague). I wanted to use JKI SMOs, but was given DQMH (and am happy about that, too).
  39. 1 point
    I'm afraid the chance for that is very small. Maintaining a separate install is a lot of work and the Community Edition is a different installation than the standard LabVIEW installer. More importantly: There is no license manager for the Linux version. So there is no way to put up something like the yearly renewal request for activation of the Community Edition. Basically it would be way to easy to distribute the LabVIEW Community Edition for Linux by bad actors and with no way for NI to even know about where it is used. The yearly reactivation requirement for the Community Edition is the only way that allows NI to at least track the use of it in some ways and give potential abusers at least once a year a bad feeling.
  40. 1 point
  41. 1 point
    The LAVA palette itself only installs a Lava icon into the LabVIEW palettes. When you then install Lava libraries (possibly OpenG libraries), they should appear in there.
  42. 1 point
    I'll be there as well. Since this will officially kick off my vacations, I will not be presenting this year 🙂. I'm eager to sit back, relax, learn and chat with all you guys & gals.
  43. 1 point
    That's why you are paid so much. Or if you aren't; you should be.
  44. 1 point
    Iperf3 gets ~95% of the theoretical speed of a 1G Ethernet easily and reliably on Windows, without being CPU bound. It requires multiple threads to get there, A single thread will be limited by the scheduler. It doesn't matter much whether it is TCP or UDP.
  45. 1 point
    I wonder if they will also release a community edition for Linux.
  46. 1 point
  47. 1 point

    Version 1.4.1

    17,225 downloads

    UI Tools v1.4.0 Copyright © 2009-2016, François Normandin All rights reserved. Author:François Normandin Contact Info: Contact via PM on www.lavag.org LabVIEW Versions: Created and tested with LabVIEW 2012 Dependencies: OpenG Application Control Library >= 4.1.0.7 OpenG Array Library >= 4.1.1.14 OpenG File Library >= 4.0.1.22 OpenG LabVIEW Data Library >= 4.2.0.21 OpenG String Library >= 4.1.0.12 LAVA Palette >= 1.0.0.1 Description: This package contains tools for designing user interfaces. A first palette helps create special effects using transparency of front panel. Using them allows to quickly create fade-ins or outs using linear or exponential variation of the intensity. A second palette contains VIs to calculate the position of GObjects for many purposes like alignment, snap, mouse follow, etc. A third palette contains VIs to create dialog boxes based on class instances. "Simple Error Dialog" and "Simple Selection List" are featured with or without backrground blackening effect. A fourth palette includes some VIs to move objects programmatically on the front panel, using a basic deceleration algorithm to provide an impression of a smooth movement. The packaged VIs are all namespaced using a suffix “__lava_lib_ui_tools” which should not conflict with any of your own code. Includes: Front Panel Transparency (Fade In & Fade Out) Utilities (Alignment, Snap) Dialog (OOP based, extensible) Engine (Beta) for object movement Instructions: This package is distributed on the LabVIEW Tools Network (version 1.3) and updates are on LAVA (1.4). It can be installed directly in the addon folder of any LabVIEW version from 2012 to now. The addon installs automatically under the LAVA palette of the addon submenu. License: Distributed under the BSD license. Support: If you have any problems with this code or want to suggest features, please go to www.lavag.org and navigate to the discussion page.
  48. 1 point

    Version 1.1.0.0

    294 downloads

    This XControl has the nice feature that a Calendar control should give you. Multilanguage support by property node. The input and output are Labview Time Stamp. When selecting a date, the date in the calendar become light blue. Please you receive this XControl for free. The minimum you can do is to rate it.
  49. 1 point
    Name: MemBlock Submitter: vugie Submitted: 26 Nov 2010 File Updated: 03 Jan 2011 Category: General LabVIEW Version: 8.2 License Type: BSD (Most common) Author: Wojciech Golebiowski (w_golebiowski (at) tlen dot pl) Name: MemBlock Type: library LabVIEW version: 8.2 Description MemBlock is easy to use interface for internal LabVIEW memory manager functions (namely AZNewPtr, AZDisposePtr and MoveBlock from LabVIEW.dll). It allows for convenient work with continuous nonreallocatable blocks of memory) - allocating and dealocating blocks and write and read data to and from them. It is usable everywhere you deal with external DLL and you have to provide pointer to some data or read data from received pointer. Typical usage case is dealing with complex C structs containing pointers to arrays or strings. Installation Preferred way to install library is to use VIP package and VI Package Manager. Alternatively library may be used after unpacking it anywhere on disk. However, it is most convenient to copy entire MemBlock directory to the directory \user.lib. After refreshing palletes (or LV restart), in the User Libraries, sub-palette "MemBlock" will appear. Documentation Descriptions of all VIs are available through the LabVIEW context help. Support If you have any problems with this code or want to suggest features: please go to lavag.org and Navigate to LAVA > Resources > Code Repository (Certified) and search for the "MemBlock" support page. Version History 1.0.0: Initial release of the code. License (BSD) Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. The name of the author may not be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. Click here to download this file
  50. 1 point
    QUOTE(tcplomp @ Feb 12 2008, 12:34 AM) It is very similar to tree control, but only because most of the methods and properties look alike. I only used MCL control type, no type casting needed. The difference between these two typecasts is that the tree control gives you much more ease of use in icon management. You can hide/show each icon individually identified to a particular tag name. The MCL allows for a whole list of icons to be shown quickly rather than individually controlled. http://lavag.org/old_files/monthly_02_2008/post-10515-1202824855.jpg' target="_blank">


×
×
  • Create New...

Important Information

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