Jump to content


Popular Content

Showing content with the highest reputation since 07/13/2020 in all areas

  1. 3 points
    on that note, stumbled upon this last night...
  2. 3 points
    https://www.tiobe.com/tiobe-index/ LabVIEW dropped below 50... Might it be that its rank follows its average user age?
  3. 3 points
    The Application class has a couple of private methods which can do this (called Global Data.Set and Get) which operate on a name and a variant value (I believe this goes back at least to 2009). I think this should persist across QD calls. Note that you should pick a name which will be different from other things which might exist in the system.
  4. 3 points
    TL;DR: This is NOT a bug. It is all explainable by the normal behavior of the memory management mechanisms used by LabVIEW, including a memory allocator layer provided by SmartHeap (from MicroQuill). Details: Actually the original bug report in Dec 2013 by Mr Mike (bonjour, Mike!) was pretty accurately analyzed and documented by Ryan P in 2014 and the bug was closed then. Mike's post from today did manage to gain the attention of someone else at NI, who asked me to take a look. I reviewed the VIs from this page and decided I could explain all the behavior with actual numbers. See the enclosed picture of Process Explorer's trace of LabVIEW 2019 (64-bit) memory usage during a session looking at these VIs. The labels I've placed in the picture attempt to explain it all, but I'll summarize by saying that all the "lost" memory (around 422MB) can be explained by the 10M master pointers managed by LV, plus 10M _freed_ small blocks sitting in pages managed by SmartHeap. These _freed_ blocks are not "lost". SmartHeap knows where they are and will let us use them again, although because they are small SH keeps them in special low-overhead pools that are used _only_ for small allocations, and who knows when LV will need 10M small blocks again. These _freed_ blocks were formerly the 10M strings with one "space" character in them, each of which actually take up probably 40 or 48 bytes. Each string block has a LV-managed 32 byte header, plus a 4 byte length, plus 1 byte for the "space" char. LV asks Smartheap for this 37 byte block, and they probably give us a 40 (rounded up to multiple of 8?) or 48 (rounded up to multiple of 16?) byte smallblock to contain our request. Small blocks in SH are low overhead because they only require a single bit to represent their inUse state and require no header of their own. The numbers don't all add up exactly, but they are sufficiently in the ballpark that any slop is explainable by the the fact that a lot of other stuff is going on in the memory management arena in LV. It's complicated. There could be significant amounts of fragmented small free blocks already available. Process Explorer could be reporting in mebibytes vs. megabytes. etc. Hope this helps. Rob
  5. 3 points
    That's a mighty fine VM you got yourself there. Almost like having a VM of this Linux RT target is a super useful tool, that helps troubleshoot and debug features of the embedded UI that are at times "inconsistent" as you put it. For anyone else that finds this useful you should go vote on the idea, and/or contribute to the conversation.
  6. 2 points
    I don't think that would work well for Github and similar applications. FINALE seems to work (haven't tried it yet) by running a LabVIEW VI (in LabVIEW obviously) to generate HTML documentation from a VI or VI hierarchy. This is then massaged into a format that their special WebApp can handle to view the different elements. Github certainly isn't going to install LabVIEW on their servers in order to run this tool. They might (very unlikely) use Python code created by Mefistoles and published here to try to scan project repositories to see if they contain LabVIEW files. But why would they bother with that? LabVIEW is not like it is going to be the next big hype in programming ever. What happened with Python is pretty unique and definitely not going to happen for LabVIEW. There never was a chance for that and NI's stance to not seek international standardization didn't help that, but I doubt they could have garnered enough wide spread support for this even if they had seriously wanted to. Not even if they had gotten HP to join the bandwagon, which would have been as likely as the devil going to church ๐Ÿ˜€.
  7. 2 points
    I remember having to figure this out when generating tokens for the LabVIEW Cloud Toolkit for Azure. I remember that there was some weird stuff I had to figure out, but I've long since forgotten how I did it. On the bright side, the toolkit is open source, you can browse through the source code here to see how I did it.
  8. 2 points
    Following up from some of the information here. This is the bug I am seeing regularly in LV2020 When I close a project I never want to defer these changes, I am used to this option being "dont save changes". See the video, it shows clearly what is happening. As can be seen from the video if I re-open the same project from the Getting Started Window it opens instantaneously which is further proof that it is not actually closed. I really hope this is not a new feature, this is really dangerous behaviour as you think the project is closed so go to commit files or whatever. This has been reported to NI, no CAR as yet. Anyone else seeing behaviour like this? 2020-07-25 18-46-58.mkv
  9. 2 points
    Just use the Array Max & Min PtByPt.vi. It does all of this for you. There is also the Data Queue PtByPt.vi that you might find useful.
  10. 2 points
    Well, they're obviously not enough to have an absolute control over SH, including memory pools management as per SH API. Unfortunately I don't see any other functions or private nodes exposed, except maybe FreeSmartHeapPool function of mgcore, but that one crashes LV for some reason. I'm afraid, my find about mgcore's switching is almost useless, because compiled app (i.e. EXE) uses lvrt.dll, which already has mgcore stuff integrated into it, so no way to disable SH in lvrt, as it would require its recompile from the sources. And I never saw any different versions of LVRT except a classic one and a Full Featured one. Honestly, I don't know, why LabVIEW is shipped with 4 variants of mgcore, even if it's using only one of them. Yeah, it doesn't help much, because it's like you have inserted RD block in the end of every VI. In LabVIEW before 7.x there was "Deallocate memory as soon as possible" checkbox in the settings. This setting was stored in INI as anxiousMemoryDeallocation token. In 7.x they removed the checkbox and likely renamed anxiousMemoryDeallocation token to overanxiousMemoryDeallocation. LabVIEW still tries to read overanxiousMemoryDeallocation on the start, thus it could be used if needed. Not much sense for that though. By the way, this wiki page should be updated as well.
  11. 2 points
    Thanks, Rob! Very well done research with a lot of technical details, as we all here like. ๐Ÿ™‚ After reading and re-reading your post and SH related documents and playing with the samples I still have one question. Can we control SH behaviour in any ways or is it up to LabVIEW Memory Manager completely? Say, could I make SH to empty its pools and free all the data cached, thus reclaiming the space occupied? Or it never gives it back to me entirely? Could I disable SH utilization somehow or is it hardcoded to be always on? I found few private properties to control Memory Manager settings, e.g. Application.Selective Deallocation, Application.Selective Deallocation.EnableForAllVIs, Application.Selective Deallocation.LargeBufferThreshold and Application.NeverShrinkBuffers, but playing around these doesn't help much. I would say, it even worsens the situation in some cases. Currently I see no way to return the occupied memory, thereby LabVIEW can (and will) eat as much memory as it needs for its purposes. So, we have to live with it, don't we?.. upd: I think I found something. In [LabVIEW]\resource folder there are four variants of Memory Manager library: mgcore_20_0.dll - no SH, no AT (Allocation Tracker) mgcore_AT_20_0.dll - with AT mgcore_AT_SH_20_0.dll - with both SH and AT mgcore_SH_20_0.dll - with SH LabVIEW uses SH version by default. If we switch to "no SH, no AT" version by backupping mgcore_SH_20_0.dll and renaming mgcore_20_0.dll to mgcore_SH_20_0.dll, then the memory consumption is somewhat reduced and we get more memory back after RD was called. On default mgcore_SH_20_0.dll I'm getting these values: LabVIEW is opened and the example is running - 199 056 KB; After the string array was once created (RD is on) - 779 256 KB (the peak value is at ~800 000 KB); After the VI is stopped and closed - 491 096 KB. On mgcore_20_0.dll I'm getting these values: LabVIEW is opened and the example is running - 181 980 KB; After the string array was once created (RD is on) - 329 764 KB (the peak value is at ~600 000 KB); After the VI is stopped and closed - 380 200 KB. Of course, it all needs more extensive testing. I see however, that "no SH, no AT" version uses less memory for the operations and so it could be prefferable, when the system is fairly RAM limited.
  12. 2 points
    I'm no longer with NI (as of 2014!), but I just got notification on this thread. I'll forward it to someone who's still there and ask them to respond.
  13. 2 points
    I've seen people add LabVIEW to their resume with less experience then that.
  14. 1 point
    That's a very common misconception. But it's actually not right. Service businesses definitely do not have 100% gross margin. "Cost of Sales" is a more accurate term than "Cost of Goods Sold" for a services business. But otherwise, it's the same calculation. Services businesses should be calculating gross margin by figuring out how much they pay an engineer directly for every hour that engineer bills. If you pay an engineer $50/hour, you'll need to bill him at $200/hour to get a 75% gross margin. And he's going to need to bill 40 hours every week. If he's not billing 40 hours every week, there won't be enough money to pay for sales, marketing, and G&A overhead. If you're a one-person company (i.e. a single person alliance member), you will need to be so damn good that you can support your own salary on 2 billable hours per day if you want to hit 75% gross margin. This is a great conversation. I hope we can have more business conversations like this on LAVA.
  15. 1 point
    Note: I am considering uping Messenger Library's base LabVIEW version from 2013 to 2017. This is to allow use adding actor templates that use JSONtext to do configuration, and to add VIMs to the palettes. None of my clients use LabVIEW earlier than 2017. Let me know if you use Messenger Library with LabVIEW earlier than 2017sp1 (sp1 fixed VIM bugs).
  16. 1 point
    Thanks Oliver for pointing out this problem. I actually don't myself use a single Connection in parallel (if in parallel, I use multiple Connections), but the library should support this. The problem comes not from the single Connection, but from the preprepared SQL Statements for attribute access. They are preprepared for speed, but this means one needs to serialise use of the Statement. I've been burned by Semaphores in the past and won't use them, but I'll use some other method. Issue: https://bitbucket.org/drjdpowell/sqlite-labview/issues/10/attribute-parallel-access-bug
  17. 1 point
    After living with this for 5 years, I have finally figured out the solution for the yellow plots. The root-cause of the yellow plots appears to be that the standard 256 color palette contained in a cluster coming out of an invoke node (FP.Get Image) become corrupted by the application builder on Mac OS X. The colors when running source code vs. when build into an application are very different. My workaround is to bundle the 256 colors directly in the source code. Of course, I am using 8-bit color. I would assume that if a higher bit-depth is needed, then a different set of reference colors would need to be bundled but I have not investigated that. I also suspect the yellow icons are similarly corrupted but I don't know how or if I could solve that. But at least now I can save my plots using LabVIEW 2020. I hope this helps someone else that has been frustrated with this. A screenshot of the work-around is below. I also have attached a screenshot showing the yellow icon.
  18. 1 point
    And it is working! Thanks @Darren
  19. 1 point
    Did you have a look at VI Scripting? If not, check the following example - [LabVIEW]\examples\Application Control\VI Scripting\Creating Objects\Adding Objects.vi To be able to create controls or indicators you should open the BD and change VI server class for "Function" constant to Generic -> GObject -> GObject. Then you change "Subtract" constant to something like "Numeric Control" and run the VI. Hope, this will help you move further with your task.
  20. 1 point
    I want to share a bug that exists in LV2019+ that results in data being overwritten in independent wire branches when changing maps with the Map Get / Replace Value node of the IPE. Here is the code: This should produce two maps <"key", 0> <"key", 1> But the actual output is <"key", 1> <"key", 1> As it turns out, Map Get / Replace Value breaks dataflow. There are two workarounds for this issue. Use the Always Copy function Wire the Action terminal of the write node This was reported to NI with the bug report number #7812505.
  21. 1 point
    I have seen this too -- looking for RT Get CPU loads.vi in the wrong place, breaking the VI. Not sure how LabVIEW gets into that state but it's been a bug for years. Deleting all RT utility VIs in your code, then adding them again seemed to fix it.
  22. 1 point
    Your Fig 1 still has a couple issues. First the memory issue. You build the array, then put it into a shift register that continues to build. You need to perform the array subset, and then put that into the shift register. Because adding elements at the start of an array were less efficient than at the end (not sure if LabVIEW improved) I often put elements at the end, then perform an Array Size, and if it is greater than some value, I use the Delete From Array, providing the index to delete as 0. Just a pointer that probably doesn't matter. The other issue with Figure 1 is you start with 1000 elements, then add elements one at a time. I suspect you either want to start with an empty array, or use the replace array subset but then things like pointers and shifting might be an issue. If you are just trying to keep it simple, I'd suggest this. Also if you are preallocating the array with a bunch of data, doing an Array Min/Max is going to use that preallocated data too which probably isn't what you want. If you go with a preallocated method you can still use array min max, but you will have to keep track of how full it is with real data, and then do array subset before Min/Max. This seems easier and honestly isn't that bad. Also you should be posting VI Snippets, these allow for posting pictures of your code as PNGs, that can then be dragged into the block diagram. Then others can get your code more easily.
  23. 1 point
    @dadreamer, nice find! Apparently these private properties should do exactly what you want: control SH behavior, but they allow to only control the size of large blocks (which shouldn't be the root of this problem) and don't seem to make any difference in my test anyway. Library replacement, on the other hand, eliminates this problem completely, even for blocks <256 bytes. Edit: Selective Deallocation is also available as an INI key along with a key "overanxiousMemoryDeallocation" (which doesn't help either).
  24. 1 point
    Really good value and a real chance of not being vapourware!
  25. 1 point
    Absolutely. This is such a good tool it is a bit sad NI does not officially endorse this. By the way I found this thread a bit more current https://forums.ni.com/t5/LabVIEW-Real-Time-Idea-Exchange/Provide-a-Virtual-Machine-VM-in-which-to-run-LV-RT-systems-on/idi-p/1069833#comments In particular this post with step-by-step instructions on how to begin: https://forums.ni.com/t5/LabVIEW-Real-Time-Idea-Exchange/Provide-a-Virtual-Machine-VM-in-which-to-run-LV-RT-systems-on/idc-p/3953070/highlight/true#M598 with a bit of further info instruction here to get the embedded GUI up and running: https://forums.ni.com/t5/LabVIEW-Real-Time-Idea-Exchange/Provide-a-Virtual-Machine-VM-in-which-to-run-LV-RT-systems-on/idc-p/3953394/highlight/true#M603
  26. 1 point
    I can only see a link to a request page, where only Pro users can make a request to presumably get older versions. There's no link to just get an older version that I can see.
  27. 1 point
  28. 1 point
    Are those front panels part of your intended Embedded UI, or only for debugging? When I run VIs on the cRIO "from source", both (1) and (2) work correctly for me on the cRIO's screen but not on the PC's screen (including preallocated re-entrant VIs). Tested with LV 2017 SP1 + cRIO-903x image in a VM. It is always worth having the cRIO screen visible during embedded UI development because what you see on the PC is not what you get on the cRIO: https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019LZ9SAM
  29. 1 point
    Confirmed in LV2019 64-bit and LV2020 32-bit running on Windows. Urgh this is horrible ๐Ÿ˜ž but I am actually kinda surprised I missed this as I am finishing up quite a large 2019 project and moving stuff around in the project is something I do quite regularly for housekeeping. As you said, it was difficult before but possible. I am hoping this is just a bug and not an added "feature" that the "data" told NI that customers wanted. My latest weird project bug with LV2020 is when I close the project it does not automatically close any windows I had open ๐Ÿคฌ
  30. 1 point
    By the way, this has also fixed the issue I forgot to mention that right-clicking in the project also took a really long time to bring up the first instance of the menu.
  31. 1 point
    Try mass compiling the [LabVIEW 2020]\resource folder? LabVIEW should install the compiled cache for this already, but maybe something got messed up?
  32. 1 point
    @kosist90 Here is a beta version, that you can test if you like: drjdpowell_lib_sqlite_labview- It's not implemented exactly the same way as your example, but it should work in the same places. See the example "SQLite Parameters in Execute".
  33. 1 point
    I've seen that with clients I have been working for on LabVIEW related projects. A new software development manager came in with a clear dislike for LabVIEW as it is only a play toy. The project was canceled and completely rebuild based on a "real" PLC instead of a NI realtime controller. The result was a system that had a lot less possibilities and a rather big delay in shipping the product. Obviously I didn't work on that "new" project and don't quite know if it was ever installed at the customer site. That said, we as company are reevaluating our use of LabVIEW currently. We have no plans to abandon it anytime soon, but other options are certainly not excluded from being used whenever it makes sense and there have been more and more cases that would have been solved in the past in LabVIEW without even thinking twice, but are currently seriously looked at to be done in other development platforms. And I know that this trend has been even stronger at many other companies in the last 5 years or so. My personal feeling is that the amount of questions in general has dropped. The decline is less visible on the NI fora, but all the other alternative fora including LAVA, have seen a rather steep decline in activity. Much of the activity on the NI fora tends to be pretty basic beginner problems or installation pericles and pretty little advanced topics. It could be because all the important questions for more advanced topics already have been tackled but more likely it is because the people who traditionally use LabVIEW for advanced usage are very busy in their work and the others are dabbling their feet in it, come with their beginner problems to the NI fora and then move on to something else rather than developing to the intermediate and advanced level of LabVIEW use. Also with exception of a few notable people, participation of NI employees in the fora seems nowadays almost non-existent and except the aforementioned notable exceptions, many times if an NI empoyee eventually reacts after a thread has stayed unanswered from other fora members for several days, doesn't go very much beyond the standard questions of "What LabVIEW version are you using? Have you made sure the power plug is attached?" and other such pretty unhelpful things. This is especially painful when the post in question clearly states a problem that is not specific to a certain version and pretty well known to anyone who would even bother to start up just about any LabVIEW version and try the thing mentioned! It sometimes makes me want to tell that blue eagle (รคah is that a greenie now?) to just shut up.
  34. 1 point
    First off, let me say that this is yet another post concerning functionality that has not officially been released by NI, so the standard disclaimer about not using it in anything you care about applies here. Basically, if you add the line SuperSecretListboxStuff=True to LabVIEW.ini, it adds some additional options to the context menu for the list box control. Here's a comparison: Just thought I'd share this, since I googled the INI key and didn't find anything, so I figured nobody's found it yet.
  35. 1 point
    Chris' post here mentioned an NI internal debugging tool called Heap Peek that I hadn't known about. So of course after reading the wiki I immediately enabled it and started poking around. I can't find any other useful information online about it. Is there any other tribal knowledge on this tool or are there other things you have used Heap Peek for? I also discovered Ned (Ctrl-Shift d, Ctrl-Shift n) and a combo to show buffer allocation (d, q.) One key combo (d, ,) causes some BDs to be grayed out. I don't know what purpose it serves though. Any other known gems?
  36. 1 point
    You can edit that wiki if you have more info. or write your comments in "Discussion" page if you're unsure about editing it directly. I created a whole category of articles there: https://labviewwiki.org/wiki/Category:LabVIEW_internals
  37. 1 point
    I work with those CURSED USB to RS232 adapters nearly every day and have had a whole range of different issues with them. I won't get into it all here, but here are the troubleshooting steps that I typically do in no particular order: 1. Jumper the Tx and Rx pins on the connector closest to your device to form a loop back (pins 2 and 3). 2. Use PuTTY or some other method to send data out, you should get the exact same data back. If you get data back, then you're communication is making it round-trip to at LEAST the connector of your device. 3. Try a null-modem cable/adapter, which swaps the Tx and Rx pins between one end of the cable to the other. Sometimes manufacturers don't make it easy to figure out if it's required. 4. Double-check to make sure your Baud rate, data bits, stop bits, parity and handshaking have been configured to match what the UPS is expecting. It looks like you're specifying a termination character for READ (For the initialization, 0x0A), but not enabling it. If the UPS requires a termination character, you'll have to explicitly send one with writes, it doesn't automatically append. If the UPS is expecting it, you may have to add an "0A" to the end of your hex string. 5. Look in the documentation to find out if the UPS requires any special termination characters, start/stop, etc characters - I.e. is what you're sending properly formatted? I've had devices which required unusual starting and termination characters before, with or without the common "0x0A termination character. 6. Your VISA Open timeout is zero, try adding something a little longer... possibly 50ms to 250ms or so.
  38. 1 point
    After digging around some more I found more hidden INI keys. Again, use these at your own risk. whileLoopSharedCloneOptions=True - adds an additional context menu option to the While loop; not sure what the different options do GenericsAreGo=True - enables the creation of generic VI's (danger!) by right-clicking a control or indicator and selecting "Generic" ActiveXMoreContainerOptions=True - Adds "Persist State To Edit Mode" and "Destroy And Recreate When Run" to the Advanced submenu of an ActiveX container AdvancedPlotLegendMenu=True - Adds a whole bunch of additional options to the context menu for a plot legend EnableStrictTypedefConstantConfiguration=True - Adds a new context menu item to constants based on strict typedefs called Act as Strict Typedef Constant. Function unknown. enableSecretPopups=True - Adds additional context menu items to custom control parts that configure how they scale with the control. Apparently some other hidden menu items are added somewhere too. (Thanks, hooovahh and Christina Rogers!) showRunAtAnyLoopMenuItem=True - Adds a new menu item to Property and Invoke nodes labeled "Run At Any Loop". When selected, the node turns brown as if a private property or method was selected, even if none are. Function unknown. ShowWireAddressMode=True - Adds some additional memory-related information to the context help window when you hover over a wire. Also adds a context menu item to wires called Select InPlace Signals, which likely selects wires that share a memory address. Seems like it could actually be pretty useful for optimization! SimShowCompanionDiag=True - Adds a context menu option to the Simulation structure called "Show Companion Diagram", which toggles showing what looks like a "behind-the-scenes" block diagram for the simulation. NEW! ShowHiddenLibraryItems=True - Shows hidden library items. (big surprise there!) So far I've only seen changes when editing a statechart library, but it seems most of the items in a statechart library are hidden, so it reveals a lot. There's also some more whose functions I'm not sure of (but look interesting) such as TotallySecretAndPrivateMSNCompanionDiagram, and growSubVI.enabled (might be pretty mundane, but it's false by default and might have something to do with creating subVI's that can grow like XNodes.) If I find any more interesting ones I'll post them here, but here's a list of every INI key loaded when LabVIEW starts, obtained by hooking the internal function that reads them: http://pastebin.com/j1iAEZXg. See here for information on finding the rest. In the meantime, if anyone knows what any of these do, please post!
  39. 1 point
    The NI_Unzip.lvlib VIs are all password protected (probably because underneath, they are using some .NET calls they don't want people to mess up with). So yes we don't know what they do, although the help tells us what they can't do: Unzips the contents of Zip file to the Target directory. Set Preview only? to TRUE to preview the list of files in Zip file before you unzip the zip file. This VI cannot unzip a zip file that is password protected. Why wouldn't it support password protected archives? Anyway, the compression/decompression algorithms are not necessarily particularly well described or unique for that matter and it is therefore not surprising that some implementations might be incompatible (although they shouldn't): .NET documentation https://docs.microsoft.com/en-us/dotnet/api/system.io.compression.deflatestream?view=netcore-3.1 An old 40,000 ft description: https://zlib.net/feldspar.html quoted in this interesting "from-the-ground-up" implementation (quoting the previous reference): http://www.integpg.com/deflate-compression-algorithm/
  40. 1 point
    I have the same board. This is what I did. Download the RaspBerry Pi Imager v1.2 and used that to format a microSD card used for the Raspi. Select the first recommended OS: Raspbian Boot up the Pi with keyboard and mouse. Walk through the startup config (installing updates, etc) and wifi setup. When asked to enter a new password, ignore this and just click next. Reboot as suggested. Go to RaspBerry Pi configuration and on the Interfaces tab, enable SSH Open a command prompt on raspi and type: sudo raspi-config Select 7: Advanced Select A1: Expand file system. (this will expand the file system if it's not already expanded) Reboot In LabVIEW select from the Tools > MakerHub > LINX > LINX Target Configuration Click the connection button and it should connect. Hostname: raspberrypi, username: pi, password: raspberrypi. These are all the defaults. Click the Installation button. Click the Update button on the installation page. it should go through the process of doing the update. At some point the raspi will reboot. this is part of the process. When the raspi reboots, the LINX target configuration dialog will lose connection and give an error. This is normal. it will take a while to reconnect. Eventually, it should come back. If not then click the Connection button and try to connect. The Installation panel should now show the installed version: Click on Launch Example. In LabVIEW, right-click on the Raspberry Pi Target and select connect. This should should show the deployment progress dialog and after connection a small green indicator will appear in the target tree You should be able to execute (run) the VI now. Everything should be good to go now. Sometimes you will try to connect, in the project, and then you will get an error not connecting. If that happens, just wait and try again. I find that the connection is more reliable if you use the IP address of the raspi instead of the DNS name. To specify an IP address, right-click on the Raspberry Pi target and select Disconnect. Then right-click again and select properties. In General, enter the IP address of the raspi. Then click OK. To find the IP address of the raspi, type: hostname -I in a raspi command prompt. I think the reason why the log message states Raspberry Pi 2 B, is because the LINX toolkit is old and that message was probably not updated to handle all the new boards that have come out since release? Not sure. i'm getting the same message on my system even though the board is Pi3.
  41. 1 point

    Version 1.0.0


    This VI program implements the Discrete Fourier Transform (DFT) to draw any drawn shape outline with epicycles as demonstrated in this video. For more information on the mathematical principles, please watch this video by Mathologer. How to Use: 1.Unzip the attached zip file. 2.Open Main.vi file. 3.Run the VI. 4.Draw a shape. 4.Enjoy animation!
  42. 1 point
    Thousends of releases? I kind of doubt it. Leaving away LabVIEW prior to the multiplatform version (2.2.x and earlier which only were Macintosh) there have been 2.5, 3.0, 3.1, 4.0, 5.0, 5.1, 6.0, 7.0, 7.1, 8.0, 8.2, 8.5, 8.6, 2009, 2010, 2011, 20012, 2013, 2014, 2015, 2016, 2017, 2018, 2019 releases so far. Of each of them there was usually 1 and rarely two maintenance releases, and of each maintenance release between 1 to 8 bug fix releases. This does probably only amount to about 100 releases in total and maybe another 50 for beta releases of these versions (a beta has usually 2 to 4 intermediate releases although that tends to be no more than 2 in the last 10 years or so). I'm not aware of any LabVIEW release that had the debug symbols exposed. PDPs were used even in Microsoft Visual C 6.0, the first version that was probably used by NI to create a released LabVIEW version (NI only switched to use Microsoft C for the standard 32-bit builds for Windows NT, the Windows 3.1 versions of LabVIEW were created using Watcom C 10.x which was the only compiler able to create full 32-bit executables that could run on 16-bit Windows 3.1 through the built-in DOS extender runtime). Microsoft makes this anyhow pretty hard to happen by accident as such DLL/EXE files would normally link to the debug version of the Microsoft C Runtime library and you can't install that legally on a computer without installing the entire Microsoft C Compiler contained in the Visual Studio software. There is definitely no downloadable installer for the debug version of the C runtime engine. The only early leak I'm aware of was that the original LabVIEW 2.5 prerelease contained a huge extcode.h file in the cintools directory that showed much more than the officially documented LabVIEW manager functions. About half of it was still pretty much unusable as you needed other functions that were not exposed in there to make use of some of the features, and a lot of those functions were removed from the exported functions around LabVIEW 4.0 and 5.0 as they were considered obsolete or undesirable to pollute the exported symbols list, but it did contain a few interesting functions that are still exported from the LabVIEW kernel but not declared in the current extcode.h file. They fixed that extcode.h bug before the official release of LabVIEW 3.0, which was the first non-beta version of LabVIEW running on other computers than Macintosh. (2.5 was basically a beta release called prerelease version to have something to show for NI Week 1992 that runs on Windows 3.1, and there was a 2.5.1 and I believe 2.5.2 bug fix release of it in 1993). Also lvrt.dll is a development that only got introduced around LabVIEW 6.0. As this was released in 2000 it most likely used at least Microsoft Visual Studio C++ 6.0; Before that the application builder was concatenating the generated runtime LLB to a stub executable that contained the entire LabVIEW runtime engine. That was a pretty neat feature as it created a single file executable, but as LabVIEW was extended and more and more functionality implemented in external files and DLLs that get linked dynamically, this was pretty much unmaintainable in the long run and the entire runtime engine was externalized.
  43. 1 point
    One thing I've always wanted (and have asked about here before) was a way to edit the data inside VI files at a low level. Well I finally figured that out. I have here a tool that will let you open a VI, look at the individual blocks of data stored within, and make changes. Plus, with the power of private methods and internal settings, it can also convert VI's to a format where the front panel and block diagram are XML-based, so you can easily edit the raw representations of objects. Here you go. Run "Resource Editor.vi", select a VI (make sure you make a backup first if you care about it), and click Load to load its resources. Click "Load as XML" if you want to edit the front panel and diagram as XML. If you've edited the block diagram at all, make sure to click Fix VI Checksums. Then just click Save once you've made the changes you want. EDIT: Second version is posted; this one should work in LabVIEW 2014, and fixes some bugs. I also added copy/paste buttons for the front panel and block diagram resources, since LabVIEW's built-in copy/paste function didn't seem to work for some reason. Note that if you edit the front panel or block diagram in the VI without using copy/paste (and the size is different), you need to update the size (first 4 bytes) as well. You can do this by clicking Copy and then Paste. Now this may not be too useful for you, considering it's not something you should use in production code or anything you don't want to break. (I say that a lot in my posts, don't I?) But if you're curious about how VI's work internally, it's perfect. This requires OpenG. Also, special thanks goes out to Thomas Zeugner for making VI Explorer. You know, that tool for cracking VI passwords. Turns out he figured out how the VI checksum (in the BDPW block) is calculated, which helped me greatly. Oh, one more thing, I do plan on improving it. I was just excited to share what I had. So keep in mind there may be bugs. Latest version: The latest version is posted on the tool's home page, here: http://flarn2006.dyndns.org/llvim/ Older versions: Low-Level VI Manipulation rev2.zip Low-Level VI Manipulation.zip
  44. 1 point

    Version (latest version 5.5)


    (latest version 5.5 - November 3, 2015 - LabVIEW 2010) Chess Game with artificial intelligence 100% LabVIEW AI : algorithm MinMax + Alpha-Beta pruning two game levels : "novice" and "Jedi" editing interface (edit on/off) a) moving mode : left-clic on the starting square, left-clic on the destination square b) positioning mode : right-clic on a square opens a context menu to choice the piece. This engine 5.5 is stronger than the previous engine 5.0 (Jedi level) unzip - run "Chess_ouadji.vi" Have fun! ouadji, if you like this Chess Game, a kudo is most welcome! (here - first post)
  45. 1 point
    enableSecretPopups - I put this token into LabVIEW 2011 for Silver control development, as a quick-and-dirty way to make low-level control edits. I've been giving it out to people on a very limited basis, but I guess since it's out here I'll widen the audience. I show a screenshot of the new menu items in https://decibel.ni.com/content/docs/DOC-17431 Once this token is enabled, you'll be able to see the settings on parts of the Silver controls to get an idea what they do. eg "Left Move" means the part will move left when its "master" part changes size via moving its left edge. "Left Grow" means the part will scale in that situation. Setting both the left and right move options will make the part stay centered. There are clearly combinations that don't make any sense and I suspect LabVIEW will behave badly if you use them. I recommend that you disable the token when you're not using the Control Editor, because it also enables other menu items that are not ready for prime time and you might use them later without realizing they're only there because of this INI token.
  46. 1 point
    After what I've read in this thread, I think there may be a bug here. I've filed CAR 440207 to investigate this behavior. I'll update this thread when I hear more information. While I understand and appreciate hoovah's sentiment that you should just trust the compiler, I think that blindly trusting it is not always the best idea. There's a lot that can go wrong. It almost always does the right thing. And it reflects well on LabVIEW that you trust it so much. But sometimes it doesn't do the right thing. It's important to look at LabVIEW with a critical eye sometimes.
  47. 1 point
    Click the uo button (I think it means "UID ordered") to sort the objects by UID. The UID is the first number in the rows (see attachment) That should help you find it. I don't know why it's not not showing up in order in the memory-ordered list.
  48. 1 point
    Over the past few years, I have advocated that several private properties/methods that could be useful to the wider LabVIEW audience be made public/scripting. I have been largely successful. Please let me know (on this thread, or with PMs, or whatever) if y'all come across private entries that you think would be useful, and I'll see what I can do to make them official in a future LabVIEW version.
  49. 1 point
    Here are the VIs we use for Windows authentication and domain groups. Validate Username and Password.vi takes the username and password and returns a TRUE if it validates against the domain controller. User in Group.vi takes a username (or current user if left blank) and a Domain Group name and returns TRUE if the user is a member. User Groups.vi takes a username (or current user if left blank) and returns an array of Domain Groups to which the user belongs. We only use these on our internal network, so I can't guarantee they work in every situation. Still, they may give you a starting point if you need something similar. Pat P.S. LabVIEW 2010sp1 User Groups.vi User in Group.vi Validate Username and Password.vi
  50. 1 point
    You could also use graph cursors or annotations, and position them just under your bars. That would look decent enough if you set the Yscale min to -1 rather than zero, and then you could put the labels at Y = 0.5 or something. You'd fill the bars down to zero rather than down to -infinity. You would have a few compromises with the appearance, but the zooming &c.would all work. Bar Graph With X Labels.vi

  • Create New...

Important Information

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