smidsy

Hi, this is a great opportunity for you to join one of the best companies in the test and measurement field NOFFZ Technologies! My team and I are looking for a talented LabVIEW and/or C# developer to work on interesting projects together. We develop software and hardware products, prototype new solutions and employ interesting technologies. Ideally you should bring 3+ years of LabVIEW or C# professional experience, CLD and CLA certificates are a great plus as well as TestStand knowledge. Sounds intriguing right? If yes, please go to https://noffz.com/karriere/stellenanzeigen/softwareentwickler-labviewteststand-mwd/ and apply. P.S. German language knowledge is not required, but recommended. P.P.S Please feel free to PM me for any questions regarding the position.

I am happy that they finally realized, that the NXG idea is a way far from being somewhat practical or pragmatic. I am very sad it took NI so long to understand it. If I were NI I would probably go for changing the underlying engine and software stack and would rewrite LabVIEW completely, if I realize that the LabVIEW source code has reached it's end-of-life state and is very hard to maintain. This was one of the driving forces according to the information I got from NI during CLA Summit 2019. But I would never ever change (at first) the interface to the Users and to Developers and re-invent core concepts of LabVIEW just because I can. Then I would probably start adding new features and slowly adding value to the community. I would not ever threaten people by saying that "NXG is the Future", "Programming is optional" and "It is better to start switching to NXG now, because one day we will inevitably stop LabVIEW development".

Hi, You can actually typecast your DVR reference to U32 value (pointer) and back. You can store this U32 number in a helper class, that will represent your API. Or, if you decide to go with a helper API class, then you actually don't need to typecast it to U32 - just store the DVR inside the public API helper class:

Posted also on forums.ni: http://forums.ni.com/t5/LabVIEW/Excluding-instr-lib-folder-from-Project-Save-For-Previous/td-p/3760288

Hi, I would like to automate downgrading process for few LabVIEW projects from LV17 to LV14. I use Project.Save for Previous method and it works fine for simple projects. It ignores everything that lives in vi.lib (KB). But if I have a project that refers to toolkits located in instr.lib like instrument drivers, NI-DMM or NI-DCPower, saving for previous exports some of them to my destination folder. Interesting fact: I receive a warning, that NI-DMM and NI-DCPower were not converted (good news), but niModInst (part of NI-DCPower) was! And, of course, third-party instrument drivers (PSU drivers) were also converted. As you know, It greatly changes the destination folder hierarchy and alters references to these VIs in my project. I don't want to save these external files and toolkits for previous version, because I already have them in a different LV version installed. They are toolkits indeed and not project specific files. Have you ever tried to setup Save for Previous function so it really ignores instr.lib? Or maybe, is there a way to setup third-party toolkits in instr.lib so they act like NI-DMM? Like "I don't support saving for previous, please be kind and install me for a different LV version by yourself"? It is a pain, honestly

Yes, I agree, if something isn't right with a third-party toolkit, and you need to fix it quickly, you would probably want to look inside instead of exchanging emails with a support team. An then you open the block diagram with your favourite password cracker and realize, that the paid toolkit code is ugly and dirty, and you can definitely make it better. You copy and paste (or just take some ideas from the code), adjust it here and there, and reuse. It is not that bad in general, but my boss would not be happy Good point. Not sure that this is enough though. Will inlining make it more secure? Does inlining dll nodes force a host VI to be running in UI thread? Interesting! It is kind of a game without knowing the rules. You don't know what to expect, so it is better to be prepared for everything. So I will come to my boss and will say to him that we will put the licensing check into a private class method with inlining with no block diagram and with no front panel with a name like "get last user string" or even better "general error handler" and we put it into a dll and wrap it into dvr and do not forget pack into packed library but even if we do this there is still no warranty that we missed something trivial and well known by LabVIEW community Or maybe we should just put a password on our block diagram... Yes, exactly. So we may build huge walls and forget about the roof. What are the measures against this? DLL signing, hash digest or similar? I am a noob here, sorry Yes, I tried it with a normal password protected VIs. Not sure if it supports VIs with removed BD. Will check this.

Hi, I would like to implement a Run-time license checking mechanism that will enable or disable some parts of my LabVIEW API depending on a license status. After reading numerous discussions here on the forum (We need a new password cracker :( , Low level VI data editor (warning: not for production use!) , I found some more hidden INI keys, Password Security in LabVIEW) I realised few things: - reverse engineering in a LabVIEW-related field seems to be a doable task for some smart people, - password protection on block diagrams does not protect your IP, it is more of a "read-only" or a "private property" sign, - removing block diagrams or compiling it into an executable are the ways to go, and finally, - there are few tools out there, that seem to have a potential to "unflatten" VI data and modify/extract its data even without block diagrams. Back to my task. I decided to remove block diagrams. Inside my protected VI I call an external library that does the actual license checking. So the code only gets this status and returns it back to other VIs. Then the VIs do not perform their main functions, and the user gets an error. Do you think I am safe here? Is it possible to extract sensitive string information out of my VIs (without BD)? Is there a way to change wiring rules/connector pane on my VIs? Should I worry about DLL hijacking? Does NI have some kind of a tutorial for protecting your run-time API? How do you protect your API knowing all that? Do you sleep well? Thanks

Hi Aristos, Thanks, good to know this! Other questions (very trivial I guess) that came to my mind: 1. Is it possible to configure the size of a Panel? Restrict resizing? 2. I opened one of the examples and zoomed out. Why do I have the white space around my UI and then the gray space (I suppose the limits of my panel)? 3. How should zooming feature on front panels work in a compiled application? Would it be possible to control it programmatically (restrict or allow zooming, zoom to a specific value)? Am I alone seeing new panels a little bit strange?

I feel uncomfortable with this too. But maybe I just need to get used to it. This is a screenshot of Microsoft Visual Studio designer: When designing in Visual Studio, you can choose between WYSIWYG, XML or split design modes. It makes sense and it is very practical from my point of view. You can zoom in or zoom out on your application window, and you get the perspective of how it will look like. Is it possible to do the same in NXG?

Tim_S, Yes, I agree, this would be the best solution to the problem with having multiple apps referring to one set of Core PPLs. Each application build process though needs to copy all static Core PPLs to its own ..\Shared\ folder.

Hi Tim_S, Hi smithd, Yes, that is what I did. I have my parent classes from PPL dropped on my block diagram in the application. I have also few child classes that are dynamically loaded using the mentioned Packed Library palette. Parent classes are stored in few PPLs (Core PPLs). Child classes are also stored in few other PPLs (Plugin PPLs). They are loaded dynamically. I plan to have more than one application on one PC that uses Core PPLs and Plugin PPLs. I also plan to update the functionality (fixing bugs, extending functionality etc.) in both Core and Plugins PPLs in the future. Basically I don't like the idea of having the same identical Core PPLs spread across application folders on a PC. Even if I put core functionality in one PPL, I still have the problem with updating this PPL in every app folder. This sounds promising, I will try! What do you guys think of using Soft Links to directories on Windows? Basically it works right now with my apps and it does what want.

Hi All, I have an application that uses PPL (Packed project library). During the build process of my application LabVIEW copies the PPL to build/My App Folder/data. I can run the application afterwards. If the PPL is deleted or moved later from this ../data/ directory I no longer can run the app. Is there a way to dynamically link and load PPL from another location? I've tried using viSearchPath for this but unfortunately it doesn't work. Thanks, Nikita. also posted here http://forums.ni.com/t5/LabVIEW/Create-a-link-to-PPL-Packed-Project-Library-in-Application/td-p/3555902