Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation since 08/19/2020 in Posts

  1. After starting NXG 5.0.0 and traditional hang of the whole OS for 3 minutes, LabVIEW forgot how to write text on the screen Ok, not only LabVIEW, other apps too... They used to have a name software that caused weird system behaviour: a virus...
    3 points
  2. If only there was a > git fast-forward <new branch> One step, and no scary "-force" or "delete" involved.
    2 points
  3. Welcome to Lava! There is no way to intercept WaitForNextEvent, other than generating the event it is waiting for or the timeout occurring. It is, however, possible to handle the event directly in LabVIEW. Are you familiar with .NET Event Callbacks? Use the Register Event Callback function to execute a callback VI to generate a user event for an Event Structure. The event structure can then take care of the timeout as well as other events that may end execution prematurely. Here is an example. For simplicity reasons I didn't include error handling and the callback VI, but you should
    2 points
  4. I think that the error is in the use of "Current VI's Path". When you strip up one level in development mode (when the Current VI is directly in a folder) then you get the folder where the VI is located. For an EXE, the VI's path will be nested inside some virtual folders inside the EXE file. Try using the OpenG VI "Get Current VI's Parent Directory.vi" this is a bit smarter in terms of getting the actual OS folder where the VI/Code is located. You can call it like this -- both of these snippets are equivalent.
    2 points
  5. I figured I would post a resolution to my own problem for anyone who may run into the same thing. While searching for something unrelated today, I stumbled across my answer. TestStand creates a connection to the configured database with the first UUT that is tested and maintains that connection while UUTs are continuously tested. Only when the sequence is stopped is when the database connection is released. I was able to come up with my solution by essentially compiling what I found in my searches. In my situation - "hiccups" in network connectivity or with the SQL server cause t
    2 points
  6. You created a couple of global variables. This is not thread save. double *Re_zArr, *Im_zArr, *RelErr_Arr, *Re_wArr, *Im_wArr; double complex z, w; int Npts; int i;
    1 point
  7. TortoiseGit is an interesting middle way between command line and a "full-featured" UI tool, as it mostly just replaces text commands with menu selections, and it can be configured to show the basic few commands (with a submenu for less-used commands): Then on top of commands is the "log", which is a visual representation of the repo.
    1 point
  8. Tried GitKraken a bit. Couldn't see enough improvement over SourceTree to consider a paid product (but I may be missing something). If I were going command line, I would first look into Gitless, and attempt by Computer Scientists to fix the flaws of Git. There is a paper on it here: Purposes, Concepts, Misfits, and a Redesign of Git.
    1 point
  9. Why not use the LabVIEW's native Application Directory VI? This automatically takes into account if you are in development mode or runtime (exe). Application Directory VI Owning Palette: File Constants Requires: Base Development System Returns the path to the directory containing the application. If you call this VI from a stand-alone application, this VI returns the path to the folder containing the stand-alone application. If you call this VI from the development environment and the VI is loaded in a LabVIEW project file (.lvproj
    1 point
  10. Just for info: my recipe to fix a "detached head" is (using SourceTree) Create a temporary branch on the detached head commit (I prefer to name it "GitIsStupid") "Checkout" the real branch it should be on (usually) "Merge" the temporary branch into the current branch (no actual code merge occurs, so this is non-intuitive to me) Delete the now-unneeded temporary branch Git: making the easy things hard, and the hard things possible.
    1 point
  11. To add to the list of potential red flags: Windows Registry Access VIs VI Scripting calls (deleting or subtly modifying existing project code) Large VI file sizes / large constants (malicious VIs stored as byte arrays, so avoiding VI Analyzer's checks) Bugs known to crash LabVIEW Shortened links in VI help Non-standard block diagram colors (hiding a subVI on an identically colored BD) Obfuscated code (strings masquerading as boolean arrays, numbers with hidden precision, etc): Very small subVI icons (think a VI disguised as a
    1 point
  12. Here is my second part including some doubts. Please note that I make a few assumptions about the nature of this idea, so take it with a grain of salt. This will immediately flag all existing (non-malicious) packages as malicious, because each one will fail at least one of those checks. Just try running those checks on the OpenG packages... Also, most of those points only indicate potential technologies with which one could build malicious software. They are certainly not indicators of malicious software on their own. Not just that, but it also limits the options for the kind
    1 point
  13. Should ManagementEventWatcher.Start method be called in order for it to run asynchronously? Something like this: WMI_USBStorage_Event_withDeviceIDandTimeOut.viCB.vi Tested this sample on my own USB drive and it works fine.
    1 point
  14. What you describe sounds very similar to our situation, except that we only have a single top-level repository for all stations. If you look at a single station repository of yours, however, the structure is almost the same. There is a single top-level repository (station) which depends on code from multiple components, each of which may depend on other libraries (and so forth). * Station + Component A + Library X + Library Y + Component B + Library X + Library Z + ... In our case, each component has its own development cycle and only stable code is pulled in the top-level re
    1 point
  15. @Jim Kring & @drjdpowell Fantastic! Would've taken me ages to sort that out, thank you very much!
    1 point
  16. You are trying to create your ini file adjacent to your vi; in your exe that path is inside your exe, which cannot have files created in it. You need to have your ini file in a different place.
    1 point
  17. I presume you mean the 3D Cartesian Coordinate Rotation VIs. The NI documentation has a decent description of what they do: https://zone.ni.com/reference/en-XX/help/371361R-01/gmath/3d_cartesian_coordinate_rotation_euler/ These are polymorphic VIs. By default, they take an array of coordinates. If you just want to rotate a single point, select the "Scalar" version of the VI (Put the subVI on your block diagram, then Right-click > Visible Items > Polymorphic VI Selector) The 3x3 matrix is the transformation matrix, which is a concept described in linear algebra. There
    1 point
  18. Welcome to LAVA! You can customize the installer with a spec file. If I remember correctly that also allows you to specify the installation directory. Here is a KB article for how to create the spec file (scroll down to "customizing installation"): https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019Ld6SAE&l=en-US
    1 point
  19. It's badly documented, but it appears to be there for me, but in the "UseOuterEnvelopeLabel" vi (see below). This is because that is where I envision it being useful, with a requestor attaching something to the reply. But you may be using the "Add Attachment" vi, directly. This is still on disk, just not in the palettes. I will add it back into the palettes (issue 5).
    1 point
  20. The problem I had is that submodules are connected to a specific commit, rather than branch, so when one checks them out originally one must remember to manually create a branch, else if you commit changes they are a "detached head", which is then fixable, but a pain. I find Git to be very much "'Oh, you should have used the "engage safety" and "don't_point_at_foot" options when you called the "git new_gun" command'.
    1 point
  21. You've reached the limit of my understanding of PPLs, other than they sound like a pain.
    1 point
  22. Learned something today. I had an error with some software that relies on a command being called through a batch file. My code that has worked for years was all of a sudden failing. After a bit of digging I noticed my user has some French characters in their surname, so the path to the temporary files I was generating had these non-ASCII characters in it! If I ran my batch file from CMD.exe Windows was replacing the French character with multiple ASCII characters which is obviously not going to work. The simple solution is to change the active code page to 65001 which is UTF-8. (See:
    1 point
  23. I've started a new NI User Group, to discuss the various tools I've published. This is because the current LAVA support threads on SQLite Library or Messenger Library, etc. have gotten far too long. An NI group allows individual conversations.
    1 point
  24. I've never used PPLs, but my understanding is that they can only externally call other PPLs, and will include copies of any source code they call, including the Action Engine VIs that the CVT is based on. To use the CVT for communication, one would need to make a PPL out of the CVT and call that from both your other PPL and the main program.
    1 point
  25. I particularly like that the Magic Delay Fairy QD Plug-in is prominently displayed, only one click from the home page.
    1 point
  26. Right now you just see the name and icon of the package, and a short description of what it does. I would like to see some small icons or text at the top next to the icon of each package for example. That list of compact of information should tell me things like the price / type of license, minimum required LabVIEW version, whether the package is part of a larger set (OpenG-tools for example are easier to download by grabbing the all-in-one package), when it was introduced and last updated, project link, category....(and let us filter the list based on these parameters as well). Much of this
    1 point
  27. Wow. That was very fast: https://www.vipm.io/package/lava_lib_robust_csv/ What is the process for verifying submitted packages?
    1 point
  28. I'm kind of unsure whether this could be accomplished with a common File Dialog or an underlying yellow File Dialog and its ExtFileDialog internal function. But you could switch to .NET and use some third party libraries available. One of those is BetterFolderBrowser proposed here. I have just tested it on both 32- and 64-bit LabVIEW 2019/2020 and it works great. Here's the basic example: Untitled 1.vi
    1 point
  29. Here are my points: By default it should list about 15 to 20 of the most recently updated packages. That way even new packages get promoted and it doesn't feel "static". I want to select between a few high level categories (i.e. Frameworks, Utilities, Drivers). I want to specify the version of LV that the package should support (it should take older package versions into account). Each package should provide some key facts: Name, version, author, summary, picture, rating, price, download count, download button. I want to open the details page if I find a package
    1 point
  30. I am 14 and am ready to take the CLAD exam, and I am almost ready for the CLD. Will NI let me take it?
    1 point
  31. The options are actually in two places: some are in the LV executable, but most are in RSC files within LV folder. The executable you can open with any RE tool, like Ghidra, or Ida Pro. You could also use 'strings' command to list all text chunks from executable, and guess which of these are ini options. The RSC file you can extract using pylabview, and then you get a list of tokens in XML form, ie. there's part of lvapp.xml: <Section Index="11400" Name="ConfigTokenStrings" Int5="0x00000000" Format="inline"> <String>tmpdir</String>
    1 point
  32. 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
    1 point
  33. 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.
    1 point
  34. Long time didn't see those hackish threads about LV internals on LAVA, so here's something. As always it's strictly experimental and "just for fun", so don't run the things below on your work systems, otherwise you'll easily get LV crashed, your files deleted and your disk reformatted. You're warned. As some of you maybe know, starting from LV 2017 there exists hidden ArrayMemInfo node, available w/ the scripting. It provides some info on the input array including its data pointer. ArrayMemInfo.vi My first discovery was that this pointer is stable and doesn't change
    1 point
  35. Thanks @Stinus Olsen, will look into some of these. The tool I made can now extract and re-create most VIs, like this: ./readRSRC.py -vvv -x -i './examples/empty_vifile_lv14f1.vi' ./readRSRC.py -vvv -c -m './empty_vifile_lv14f1.xml' cmp -l './examples/empty_vifile_lv14f1.vi' './empty_vifile_lv14f1.vi' Though there are still a few for which `cmp` shows difference between original file and re-created one (I've run it on the standard VIs from LV2014, on thousands of files only a few had differences). Also, it currently leaves all Blocks as BIN files - does not parse their
    1 point
  36. Oh yeah I forgot about that. This is the Salt that gets applied to the MD5 of the password. Starting in 2012 NI started salting the block diagram passwords. The salt that gets applied is something like the number of all String, Path, and Numeric controls connected to terminals. I think this does go into clusters and arrays so the work actually needs to be recursive. This ends up being a 12 byte salt, but I think 9 bytes are always 0. Of course you don't need to do all of this, to figure out what the salt is. I mean all you need to do is guess three numbers, all of which are the numb
    1 point
  37. Yes, you might be right @Rolf Kalbermatter. As long as the whole work can be divided into steps, this might be doable though. For example - there is probably a way to tell labview to compile the assembly. So only disassembling the code, still puts us one step closer, and allows us to create buildable project. Right now, I already can replace single VIs and re-build the project. Having ASM blocks would allow me to replace only single blocks inside VIs. For the people who fear for their code being stolen - if the current solution is broken, NI will put resources into making
    1 point
  38. This is just silly. Of course theres a difference. If there was no difference we would use the same word to describe both types of property. In the dictionary if you look up Intellectual Property it will not say "See Physical Property". I also don't condone releasing anything to break NI's password protection scheme, but I also think it isn't in your place to say that he "WILL get into trouble" if anything is released. What happened to the last guy that released a password cracker that works on all VIs between 7.x and 2011? Well I don't know for sure but his website is still up with t
    1 point


×
×
  • Create New...

Important Information

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