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". 

On 8/9/2019 at 10:06 PM, Zyl said:

I was seeing the DVR more like a 'pointer' (the address in memory) on the class, not a representation of the class itself

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 

23 hours ago, smithd said:

Looking because they have a legitimate reason like they locked themselves out

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 

23 hours ago, smithd said:

you should remove front panels for any code which may have sensitive data on it

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? 

22 hours ago, hooovahh said:

It may also be possible to load a VI of the same name in memory and have your functions link to the new one

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...

21 hours ago, infinitenothing said:

A dedicated hacker would probably modify your DLL/object code and "wire" a true constant to your case structure that enables the functionality.

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

21 hours ago, infinitenothing said:

Have you seen the third party licensing toolkit?

 

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

On 6/2/2017 at 9:21 PM, Aristos Queue said:

Split design mode, yes, where you can see both panel and diagram. We don't maintain an in-memory XML form, and if you look at the save files, directly editing the XML is a fools' errand (at least for me... I've tried to doctor several such files over the last few years). So if you're asking for an XML format, there isn't one.

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?

On 5/31/2017 at 8:25 AM, Mads said:

The MDI/tabbed interface solution for VIs seems to be one of the most fundamental flaws of NXG GUI.

 

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,

18 hours ago, Tim_S said:

each application would be in a subdirectory and the PPLs in an adjacent "Common" or "Shared" subdirectory

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,

15 hours ago, Tim_S said:

I expect you've dropped VIs/classes from the PPL right onto your block diagram.

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. 

3 hours ago, smithd said:

Whats your use case?

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. 

3 hours ago, smithd said:

You could load your main code dynamically using VI server and before doing that, use VI server to dynamically load the packed project library

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