Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation since 08/22/2020 in all areas

  1. If only there was a > git fast-forward <new branch> One step, and no scary "-force" or "delete" involved.
    2 points
  2. 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
  3. 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
  4. If we are talking about automating factories, isn't Factorio the game of choice, rather than Minecraft? 😋
    1 point
  5. Same story here. We've just started to standarize on Beckhoff. EtherCAT is nice medium for realizing distributed systems. We use EP boxes for distributed IO (just as your case - a great way to reduce wiring; add IO-Link sensors and actuators to the mix and you save A LOT of work with the system assembly and testing and gaining unlimited flexibility). EL terminals for the control cabinet - you can basically build any system capabilities you like, and add anything any time in case you'd forgot. Also, you get safety-rated terminals and boxes (and you can build distributed system with that, no nee
    1 point
  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. 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
  26. 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
  27. 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
  28. 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
  29. 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
  30. 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
  31. 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
  32. 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
  33. 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
  34. Version 1.0.0

    572 downloads

    Hi everyone, Since GRBL standard is open source, I decided to post my Library that I used in LabVIEW to interface a standard GRBL version 1.1 controller. Not all GRBL function has been integrated, but this is a very good start. Enjoy and let me know your comments. Benoit
    1 point
  35. Version v1.10.0 (for LV2013+)

    3,058 downloads

    LabVIEW Task Manager v1.10.0 (for LV2013+) This code is Open-Source, and free of charge Authors: Ravi Beniwal, Tim Vargo LAVA Names: Ravi Beniwal, TimVargo Contact Info: Contact via PM at the LAVA site (http://lavag.org) LabVIEW Versions Supported: LV2013 and up LabVIEW Versions Tested on: LV2017 LV2016 LV2013 Dependencies: GPower Error & Warning = 1.2.0.14 lava_lib_tree_control_api >= 1.0.1-1 NI SmartBalloon = 2.0.0.2 OpenG Application Control Library >= 4.1.0.7 OpenG Comparison Library >= 4.0
    1 point
  36. 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
  37. 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...
    0 points


×
×
  • Create New...

Important Information

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