Jump to content

Leaderboard


Popular Content

Showing content with the highest reputation since 11/24/2018 in all areas

  1. 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
  2. 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
  3. 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.
  4. 5 points
    Greetings Friends of LAVA, colleagues, cohorts, and Wireworkers Extraordinaire -- it's LAVA BBQ time! Date: Tuesday, May 21, 2019 Time: 7:30-10:00 pm Location: Uncle Billy's Brewery and Smokehouse, 1530 Barton Springs Rd, Austin, TX 78704 (1.5 miles from Convention Center) Cost: $25 Early Bird (through April 30th) $30 Regular Admission (through May 20th) $35 Door Price (May 21st) Meal Options: Expect to enjoy your choice of meats (brisket, turkey, ribs) with sides like street corn, cole slaw, and bbq beans. A vegetarian option is available when purchasing tickets. Cash beer bar. Who: Everyone is welcome, including spouses traveling with you. Even if it's your first time, expect to recognize many faces/names from the forums and NI R&D. What to wear: It's a covered, outdoor venue in Austin during Spring, so dress for the weather and comfort. Door Prizes: We will have a drawing to give away prizes. All attendees are eligible and will receive a door prize ticket upon entry. See below about sponsoring a door prize yourself to share the love. Hope to see you there! Chime in once you buy tickets to let everyone know you're coming. ------------>>------------>> Get LAVA BBQ 2019 Tickets Here <<------------<<------------ The venue is a 30 minute walk from the convention center, or a $6 Uber. Get together and carpool, people are typically gathering at Challenge the Champions in the Expo Hall, which is great fun. There is a free parking garage behind the building. We'd love for you to sponsor a door prize - Continue Reading: If you or your company want to sponsor a LAVA BBQ door prize, please post a reply below. You can also include a small blurb about your company and a link to your website in the post below. By donating a prize you and your company will receive a small announcement of your choosing, during the event. We will ask you to write the announcement on a post-it note and will attach it to the prize to be read before awarding it. We love the door prizes, but we love time for socializing too. Here are some guidelines to keep our event balanced and streamlined. Single item donations work best. If donating more than one item, then multiple identical items is strongly preferred. If donating non-tangible items or something that is not physically with you, then please bring a card with your contact info and instructions on how to collect the prize. This will be given to the winner. Donations are typically $25-$200 in value. Not recommended: Apparel (hats, t-shirts, underwear, etc.) - never the right size Software licenses (Toolkits, add-ons, LabVIEW) Branded trade show booth type giveaways (mouse pads, pens, keychains, etc.) Jokes or something meant as a gag and not a real prize
  5. 5 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.
  6. 5 points
    I think this is a valid comparison: (from https://forums.ni.com/t5/LabVIEW/Global-Variables-Are-Better-than-Functional-Globals-So-There/td-p/1528392/page/5) You are either Novice or Guru 😋
  7. 5 points
    The preference to use init methods instead of non-default class constants is so strong, LabVIEW NXG is planning to never support the feature. Any class constant there will always have only the class’ default value.
  8. 5 points
    I found it! Unfortunately it's deprecated. It takes dotted inputs as either names or ID codes.
  9. 5 points
    Proud to say that lavag.org and labviewwiki.org both get an A rating from an SSL labs security check. Even better than ni.com which is getting a B rating. 😎
  10. 4 points
    The best thing about a UDP joke is I don't care if you don't get it.
  11. 4 points
    Writing the notes forced me to watch the videos closely. I'm going to use the notes as a quick-ref whilst getting started and hoped others might have a go if they had them too. Feel free to make changes/fix wrong stuff in whatever way you like - expect you're a busy man. I'm happy to own the doc and expand it given the info. It's written in libreoffice writer, which exports a good pdf. Now looking fwd to cooking up a few actors. LabVIEW_Messenger_Library_-_Programmers_Notes_v1.7.pdf LabVIEW_Messenger_Library_-_Programmers_Notes_v1.7.odt
  12. 3 points
    Dating will always be a problem for software engineers.
  13. 3 points
  14. 3 points
    1. Place a control refnum 2. Right-click, Select VI Server Class, Generic, GObject, Control, Pixmap 3. Now it's a "Pixmap Refnum". Right-click again, Show Control 4. Drag the control out. Unfortunately, I first noticed this control in the VI Scripting style ring, where it was labeled as "warning: dangerous" or something like that. But the class isn't marked private, and it can be placed in the manner I described without any kind of warning, so maybe that warning is obsolete and it's been fixed? Then it would probably be in the palette, I guess, but I'm curious to hear what NI has to say. Maybe it's a bug that it can be placed that easily without generating any warnings. :p
  15. 3 points
    Let's take a look inside labview.rsc first... Four of the connector pane patterns actually have names: 4833: "monnie pleaser" 4834: "super monnie pleaser" 4835: "monnie would be pleased-er" 4836: "add supports 2 ddt" I guess this book wasn't lying. Two cursors with rather...interesting names: 64: "order sucker" 65: "order squirter" Someone at NI has a dirty sense of humor 😛 There's some resources that correspond to the style values for VI scripting. Some of them aren't in the style list; unfortunately attempting to use these just gives an error: 2051: "Comment Node" - says "Case" in the data, and gives "Unable to create new object" instead of the usual "object not found" error 2358: "Line of Script" 3902: "Growable Node with Header" 3905: "ExtFuncTerminalTipStrings" - data says "External Function Node", and has names for "path in", "path out", and the standard error in/out terminals 9008: "Select Menu Item" - with all the menu nodes. Looks like at one point they were working on a primitive for programmatically activating menu items. Someone found some hidden structure types a while back. All but one of them didn't work, and that other one is now an official part of LabVIEW. I found the image for the "Race Structure", which I've posted to that thread: There's also this super-minimalist "Alternate Splash Screen": And some monochrome sprite sheets—looks like the old Boolean constant graphics are still there. From what I know about internal VI data structures, I wouldn't be surprised if those were still used if you load a VI created in an old version of LabVIEW. Just thought I'd share. Curious if anyone has seen these before!
  16. 3 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.
  17. 3 points
    Loving this central location of organized and searchable LabVIEW knowledge! (Just like LAVA.😁) I've made a couple of small contributions to this so far. Mostly clicking on "Random Article" and reviewing it for typos and broken links. I set somewhat of a personal goal of trying to do this at least once per workday. Every little bit helps, right? Granted, they're not contributions on a grand scale yet, (i.e I'm not creating articles, etc.) but maybe I'll get there. This is my first time contributing to a Wiki of any kind, so I'm a n00b at it.
  18. 3 points
    Does anybody know how to get a LabVIEW built application to ignore the scaling setting in Windows? I have some code designed to fit nicely in 1280x1024 pixels, but some of my customers say that even on a 1920x1080 display the menu bar at the top is cut off. I guess this is probably because their windows scaling is set to some number other than 100%. In my experience LabVIEW looks really rubbish when run on Windows 10 with this setting to anything other than 100% (blurry and inconsistent). I suppose is to be expected from an application like LabVIEW that is approaching retirement age! Am I missing something obvious here? Although I always set my Windows scaling to 100% on all the PCs I control it is not really practical for me to expect ask my clients to change this setting as some of them have probably gotten used to seeing Windows text nice and big at 125 or 150%. Edit 1 I have done quite a bit of googling and not really come across anything LabVIEW specific. The closest I got was some NI KB about LabWindows. Edit 2. Success! https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000004A7eSAE Note a newer Windows update adds a few more options which are now tucked away in a separate dialogue. I have not tried playing around with the other options yet as this fix works fine on my PC. Edit 3. And this is how it can be done programatically: https://blogs.technet.microsoft.com/mspfe/2013/11/21/disabling-dpi-scaling-on-windows-8-1-the-enterprise-way/ (i.e. as part of an installer action)
  19. 3 points
  20. 2 points
    That's good to hear, I guess I don't need to use this meme.
  21. 2 points
    So, I've gotten word that some of y'all are concerned about me because in the last year, I basically vanished from both the LAVA forums and the NI forums other than the Idea Exchange. One person at the CLA Summit in Europe last week wondered if I'd died. Honestly, I had no idea that I'd dropped my post frequency down so low. What happened was that in May the forums that I monitor exploded with content. This is generally a good thing -- says the community is vibrant. But it meant that I went from having tens of posts in each forum to hundreds of posts, and the deluge overwhelmed me, and I started ignoring the backlog. That's just turned into a natural attrition. I'm going to try to get back to reading (and posting) the forums. I doubt I get back to the high rate of read that I had before -- I've got a lot more internal-to-NI stuff that I deal with on a daily basis these days -- but I intend to get back to posting at least every couple days instead of every couple months. And, just to be clear: no, I'm not dead. :-)
  22. 2 points
    Here's a shortcut menu plugin I wrote that does something I've found myself needing every now and then. You select some objects, right-click, select "Ad-Hoc Scripting", and then it'll open a new VI with pre-populated refnums in a cluster. All selected objects with a label (even a hidden one) will be included in the cluster, as will a refnum to the VI, its panel, and its diagram. Ad-Hoc VI Scripting.llb
  23. 2 points
    For a while I've been tinkering with the idea of building a LabVIEW client that could to talk to Jupyter kernels for interfacing with Python having been previously a user of RolfK's OpenG LabPython package. Although this, and now the native LabVIEW 2018 Python support have many uses (and indeed I use them in my 'production' code), there were a few things that a Jupyter kernel client can do: Not be tied to particular versions of Python - LabPython got stuck for me around 2.7.10 and I think was fussy about which compiler have been used. The 2018 native support is restricted to 2.7 or 3.6 I believe (3.7 defintiely doesn't work) Not being tied to the same 32/64 bits of LabVIEW Being able to offload the Python to a remote server, or go cross platform I haven't investigated the Enthought package (too much hassle to get a new vendor set up on my University's purchasing system and not really able to justify spending tax payer's money on playing!) which I suspect might be doing something similar. Anyway, the attached zip file is a proof of concept - it includes a test vi that will try to find an ipython executable and fire it up and you can then interact with it. There's lots of things not properly tested and probably a slew of bugs as well. To run it you need several dependencies: OpenG Toolkit libraries, particularly the LabVIEW Data, string, error and array libraries The JKI JSON library - I had to pick a JSON serialiser and the JKI one seemed as good as any and better than some... The JSONText JSON serialiser library available via VIPM The Zero-MQ Labview bindings - libzmq is the underlying network transport used in Jupyter and there is an excellent LabVIEW bindings library for it. The attached SHA256 implementation so that the communications messages are properly HMAC signed. LabVIEW 2018 - sorry I'm only writing in 2018 now and this code uses malleable vi's with type specialization and asserts in use - so it may not be easy to backport There's a few things that I'd still like to figure out - primarily the client protocol is very much focussed (reasonably enough) around the idea that the client is sending strings and is interested in string representations of data.I'd like to figure out an efficient way to transfer largish LabVIEW data structures backwards and forwards. I think this probably means developing a custom message handler and registering it with the kernel when the code starts and writing some Python 'flatten to string' and 'unflatten from string' code - but that's only this week's concept.... If you use it, please note that this probably only alpha quality at best - it may or may not work for you, it may not be safe to use, If it causes any loss or damage or eats your cat then it's not my fault.... Edit 6th MArch 2019: I've switched the JSON parser to JSONText, found and fixed a few bugs, managed to build a VI package for it that should have the correct dependencies and installs the example client in the LabVIEW example finder. university_of_leeds_lib_sha256-1.0.5.3.vip university_of_leeds_lib_jupyter_client-1.0.1.5.vip
  24. 2 points
    Short version - you're running a 32 bit process on a 64 bit OS which causes a mess as to how to correctly run LPR. Here are a couple of relevant links: https://knowledgebase.progress.com/articles/Article/Running-OS-COMMAND-LPR-EXE-from-within-32-bit-OpenEdge-the-Procedure-Editor-fails-on-64-bit-Windows https://docs.microsoft.com/en-us/windows/desktop/winprog64/file-system-redirector The first one suggests a solution, although I haven't tried it myself.
  25. 2 points
    Try this. Windows User Login 2017.zip
  26. 2 points
    Why would you need an Open Sourced LabVIEW for something like that? This was possible in the Control editor since LabVIEW 3!!! (Discloser: the Browse button in the Path control was not added before somewhere around version 6 to 8 but the principle worked in LabVIEW 3). 1) Place a path control on your front panel 2) Right click on it and select Advanced->Customize => The path control opens in the control editor 3) Right click on the browse button and select Advanced->Customize => The browse boolean control opens in the control editor 4) Save this as your Browse Boolean.ctl file or whatever you want to call it. 5) Use as you wish and enjoy that it automatically adapts to the platform style for the system you run it on Browse.ctl
  27. 2 points
    If the DVM and power supply are SCPI compliant; you only need to change the address of the command you send.
  28. 2 points
    I agree with James. That could be achieved through composition and adding an abstraction layer. (Sink and Source in the diagram below)
  29. 2 points
    Here is a small and borderless picture frame, along with smaller array. https://forums.ni.com/t5/LabVIEW/One-pixel-frame-for-picture-control/m-p/3716581#M1046089
  30. 2 points
    Thanks for the interesting conversation. I've resolved the issue however, in a roundabout way and by cleaning up my code. The UDP communication code in question is a model written in LabVIEW running on VeriStand, which is essentially a bunch of LabVIEW RT timed loops running on a Phar Lap target. So the model essentially opens a UDP connection, sends the message, then closes the connection. This is done at a rate of 50Hz. I changed the code so that it opens the connection at the start of the test and the model just continuously sends the message at the 50Hz rate, then at the end of the test I close the UDP connection. This resolved the issue because now the ARP is not sent anymore, like at all. Well, maybe at the start? But I haven't checked that, so I should do that later. The explanation I can come up with is, I was closing the connection every 20ms, so the OS considered the port closed, so it took that time to do the normal housekeeping of sending the ARP? But since the port was always open to a known IP address (and thus mac ID), it didn't need to do the ARP. I don't know, just my guess. Ok, so bring on the comments about, why I would keep opening and closing the port. Bring it on, I can handle it... 😀
  31. 2 points
    You know the 3D Picture control? I was messing with it and I noticed there wasn't any way to merge objects together except by chaining "Add Object" subVI's, which can be annoying if you have a whole lot of objects. I was thinking it could be a good idea to have a growable node to do it, so I decided to make one. Yes, a simple For loop (perhaps in a subVI) combined with a Build Array node would work just as well—and would really have simplified the code generation if I had thought to do it before—but I like making XNodes, and thought this would be a fun one. And yes, the usual disclaimer about XNodes applies—use it at your own risk; XNodes aren't supported by NI. Merge 3D Objects.zip
  32. 2 points
    I agree. Ben works on making a language safe for references. I work on making a language without references. Our goals are the same: a world where data can be trusted.
  33. 2 points
    Most Brians I've met are pretty cool, but those shifty Bryans on the other hand I wouldn't be to sure about.
  34. 2 points
    Wait, what about the person who already had the name Bryan?
  35. 2 points
    You can also use Quick Drop Replace to replace multiple items at once. Select all the controls you want to replace > Ctrl-Space > Type name of new item > Ctrl-P to replace them all.
  36. 2 points
    Do you have the Desktop Execution Trace utility? The first thing I would do if I had an out-of-memory would be to use this to look for "leaked" references. I once had a failure after 4 weeks of running that was caused by an unclosed .NET reference in a once-a-second loop.
  37. 2 points
    update to this thread: we got it working on the cRIO 9068. See this thread https://sourceforge.net/p/labview-zmq/discussion/general/thread/87780372ed/ for details. Thanks to everyone here and Martijn Jasperse for all your help.
  38. 2 points
    I"m not sure it's conflation only. Many seem to be focused specifically on the fact that LabVIEW GUIs don't look like the latest hyped Office version, which of course will be again different over 2 years when yet another modern style design guide claims that everything needs to be high contrast again, or maybe alpha shaded with psychadelic animations (you need to find reason to sell high end GPUs to spreadsheet jugglers). Your second point is indeed one thing I feel LabVIEW could have made more advances. Dynamic control creation while indeed complicated to get into the dataflow paradigma of LabVIEW would be possible with the VI Server reference model, although it would not be classical dataflow programming anymore for such GUIs at least for the part that you use such dynamic instantiation in. XControls was a badly executed project for an in principle good idea, Splitters are a God send for more dynamic UIs together with Subpanels, but to try to edit splitters once they are placed on a frontpanel really can be an exercise in self control. In doing so I feel the same frustration as when I'm forced to edit some Visio drawings. The editor almost seems to know what you want to do, because it always does the opposite of that, no matter what.
  39. 2 points
    Every now and then I hope for a bright future and open the latest NXG - and my head hurts. They've changed too much, and gained so little🤯. I immediately get irritated by how disrespectful the whole thing is of the strengths of LV, but try to push myself to get more used to it. Then I hit a brick wall in a lack of functionality, and my patience runs out. Back to LabVIEW 2018. Home sweet home☺️ (sure, the roof is leaking and the style is a bit 90's, but it beats NXG).
  40. 2 points
    The context help for the "RemoveXnode" method says "Removes the XNode from the diagram. The contents of the diagram of the XNode are merged with the diagram" However if you try it, it may or may not work. That's because this method just calls the "ReplaceSelf" ability; so if an XNode doesn't have a "ReplaceSelf" ability, the "RemoveXnode" method will do nothing. So if you want your XNode to work with the "RemoveXNode" method, you must create a "ReplaceSelf" ability. Fortunately doing so is very trivial: Your ReplaceSelf ability only has to call the "GenerateCode" Ability; like this: Paul Cardinale P.S. Note that the "ReplaceSelf" ability of some NI Xnodes doesn't work properly. For instance if you call "RemoveXNode" on the "Match Regular Expression" function, it will make a mess, breaking the VI.
  41. 2 points
    Maybe it's a new version of the Marshmallow test.
  42. 2 points
    Check out the awesome home page updates that @The Q has made. Huge improvement. I love it! https://labviewwiki.org
  43. 2 points
    Well after some research, this is what i came to. Sending the email in html format with the following VI to transform Unicode from LabVIEW to HTML character. I think it will work in most of the case. Benoit PS: Thanks for your help. Unicode to html.vi
  44. 2 points
    The new version is ready for download under Untested Version https://opengds.github.io/
  45. 1 point
    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  
  46. 1 point
    Could you use an adaptor around the DVM that inherits from the desired abstract classes? That has been my solution to this problem in the past.
  47. 1 point
    I think it's important to distinguish between what the language semantics are and what the compiled code and runtime actually do. For an initialized shift register on a loop, its value for a particular execution of that loop is only accessible during and immediately after the loop; the language does not let you get that value at any other point, and the value will be overwritten when it is initialized on the next loop execution. (NB: I'm not talking about individual iterations of the loop, but the execution of the loop over all iterations.) The compiled VI does store the shift register value in its dataspace, so yes, that value will be retained in the dataspace between loop executions, but from the language's perspective this doesn't matter because it's inaccessible. The language does not require the value to be retained or its allocation to be reused between loop executions; that's an optimization that the runtime provides. I'm not sure if we're agreeing or disagreeing here. My claim is that the way LabVIEW does dataflow--meaning wires carry immutable values that can be used in any number of concurrent places downstream--means that refnums are probably the best way of referencing objects that is available to LabVIEW. (I'm not enough of a theoretician to prove that reference systems with better properties aren't possible, but I do trust that if there were a better way, somebody smart around here would have discovered it in the last 30 years or so. However, another hint in this direction is the fact that channel wires have properties that approach what I'm proposing with Rebar, and channel wires are fundamentally different from normal wires.) If you want a reference system with better properties, I believe you must fundamentally change the way LabVIEW does dataflow. And so, to your next point: Yes, this is a new type of VI, or a new Model of Computation, or a new set of compiler rules, or whatever you want to call it--though I'd prefer you just call it a function, to distinguish it from what a VI is, which is more than a function. Importantly, it is not merely an extension of VIs, because it works differently enough that I do not think it should be mixed with G on the same diagram. Interoperating with VIs is a different story, and I think there is an interesting set of possibilities there. But I'm not sure I understand your question, "is there way to expand that more broadly?" I think to make life simpler for the compiler, you have to change the language, like I said above--maybe that answers it? Also, rather than "relying on the user to manage lifetimes," I would state it as "providing a set of safe and complete rules for lifetimes and guiding the user into writing code that follows the rules."
  48. 1 point
    My understanding from what came up is that Matlab is attempting to build a wrapper dll with some more matlab friendly interface. A quick google didn't find me anything about how it does this, but that seems to be what its doing. I say that because the "we dont know the..." come from the labview headers. So it seems like Matlab is running a compiler against stim.h which includes the platdefines header, and since I'm assuming the matlab compiler is not one of the ones NI was expecting when they built this (or if matlab simply doesn't #define the same definitions NI is expecting), the compiler correctly spits out the errors shown, as in this snippet of platdefines: #ifdef _M_PPC #define ProcessorType kPPC #elif defined(_M_IX86) #define ProcessorType kX86 #elif defined(_M_X64) #define ProcessorType kX64 #elif defined(_M_ALPHA) #define ProcessorType kDECAlpha #elif Compiler == kBorlandC #define ProcessorType kX86 #elif defined(_ARM_) #define ProcessorType kARM #else #error "We don't know the ProcessorType architecture" #endif So the question becomes what should it be. My guess is that they should be defined per the labview exe/dll which is why I suggested the MSVC compiler definitions (as I understand it, this is what NI uses for windows builds). However it may be that the right answer is to edit the headers to set something more appropriate. For example, in the section above, you could comment every line out except for "#define ProcessorType kX64". Similarly you could comment out the compiler section and replace it with "#define Compiler kGCC" (if that is what matlab uses, which I assume it is). The only reason these need to be defined is so that extcode.h picks up all the appropriate definitions and headers for the platform. For example. stim.h uses the type "uint32_t". This is defined in stdint.h, but if your compiler isn't including it already then stim.h can't be compiled. So, in fundtypes.h, it has a bunch of platform checks to see if it needs to define those types. The easier route, vs trying to make extcode.h have the proper types, would be to just edit stim.h directly to include the type definitions you need. I would suggest editing your stim.h to look like this (lines 1-7): //#include "extcode.h" //this dll only uses two uncertainly defined types, but they are defined by stdint.h. This section is borrowed from fundtypes.h #if !defined(_STDINT_H_) && !defined(_STDINT_H) && !defined(_STDINT) #include <stdint.h> //alternatively comment the line above and uncomment these lines: //typedef int int32_t; //typedef unsigned int uint32_t; #endif #ifdef __cplusplus extern "C" { #endif .....
  49. 1 point
    LLVM/Clang is truly a marvel! If you need to write wrapper VIs for DLLs, then I think a tool like this is the way to go. However, unless the C API has anything non-trivial like passing a large struct by-value or strings/arrays, you'll end up having to write your own wrapper DLL, right? (side note: I do wish LabVIEW would let us pass Booleans straight into a CLFN by-value...) This struct has the same size as a single int, so you can lie to the CLFN: Say that the parameter type is a plain I32. What are the possible types in the union? If they're quite simple and small, you could tell the CLFN to treat it as a fixed-size cluster of U8s (where the number of cluster elements equals the number of bytes of the union), then Type Cast the value to the right type. The type cast will treat your cluster as a byte array). These would require project-specific scripts that don't fit in a generic automatic tool though. The import wizard was useful for study purposes, to figure out how I should create my wrapper (using a simple sample DLL). That was about it.
  50. 1 point
    Also, this is kind of a side point but the concept is the same. Has anyone noticed that reentrant VIs get super slow sometimes when debugging? Its not always, but I can't figure out what conditions might be causing it. Its like you're going along debugging some code, you step into a reentrant VI, and everything just stops, and it takes like 20-30 seconds for the window to materialize. I know its not just one computer, sadly.


×
×
  • Create New...

Important Information

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