Mr Mike

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.

Hello LAVA,

I left NI about 9 months ago, but LabVIEW is on my resume, so hear from recruiters occasionally.  I got a flurry of calls and emails from recruiters yesterday and today searching for a LabVIEW developer.  One said it was contract work, one said it was for a full-time position.  The position is in Spring, TX, which really only points to one company.  They specifically asked for no telecommuting, so you've got to be in the Houston area, or willing to relocate.

Let me know if you're interested by replying or private messaging and I'll send your contact information to the recruiters.

- Mike

In case anyone stumbles on this, this more name documentation here.

I was curious so I put something together (well most of it was stuff I've had lying around from previous benchmarks). I figured my first go at the benchmarks would be wrong, so there is a script to generate them.

1. Run gentests/gentests.vi

2. Open Benchmarker.vi and set the path to a generated report file

3. Run benchmarker.vi

 

My first attempt is attached. If you want to change the benchmarks, they are the templates in the folder. From this first run, I don't see a difference, but as I said my first attempts are usually wrong when it comes to benchmarking.

I took a quick look over it.  I removed the write before the property node reads because I thought it might be doing some priming that wasn't necessary.  I also made all of the loops use a shift register to use the same object the whole time, instead of copying it each time.  Finally, I made every VI read or write four times instead of just once, so that the differences in timing could compound and be more noticeable.  It looks like the property nodes are 8% slower.  I haven't looked at these tests with a critical eye (or a properly caffeinated eye), but that's about what I'd expect.  I bet if you included the same error checking as the property node the difference would be closer.  I hope you're coming to the LAVA BBQ

It will be a cold day in Austin during NI week (or let's say it will be hotter inside the convention center than outside during NI Week) before I will use property node accessors again.  I once succumbed to their siren song and wrote some SDR code using them.  The inability to inline subVIs containing property nodes was a disaster, I had to write a QuickDrop shortcut to replace the property nodes with their underlying accessor VIs.   Simply doing that (it was not so simple in practice) allowed me to inline certain SubVIs and then the code worked.  No changes to the underlying VIs, just removing them from the PN was enough.

 

Want to quibble over what a "big" difference is.  A seemingly "small" difference which means the difference between being able to process the IQ data in less time that it took to acquire it or not is by definition a "big" difference in my book.

 

In summary:  you could write code that shows that Property Nodes are in fact faster than the underlying SubVIs.  Nice, but not so helpful in the real world.  When the rubber meets the road, the inability to inline can hurt much, much more than some minuscule performance difference.

I was under the impression that issue had been fixed.  I filed CAR 484048 to our performance team.  They'd still not be uninlinable if they were dynamic dispatch.

 

The other smaller question is LVOOP property nodes - I haven't noticed any problems at all with using them, and I'm still on LV2012 (may jump to LV2014 in a month).  Is something unsavory lurking beneath the surface?

I was under the impression that all the linking issues with LVOOP property nodes had been resolved.  I haven't seen a CAR on that at least since 2012.  Admittedly, LVOOP property node CARs are handled by someone else now, but they usually come to me to review fixes for any serious issues.  I was silently following this thread to see if anyone else had anything to say about Jack's comments about LVOOP property nodes.

If anything, issues with property nodes have gotten better over the last few years -- at least in my usage. All of the really bad bugs I've seen have been fixed as of this most recent patch (see this recent thread for an example: http://lavag.org/topic/18308-lvoop-compiler-bug-with-property-nodes/).

 

But, there are still a lot of usability annoyances related to case sensitivity. For example, if I name my folder Properties in the parent class and "properties" in the child class, you'll see two property items which link to the same dynamic dispatch VI. When a recent code review found a misspelling in the property name of a parent class, I had to go through every child implementation (~15 at this point) and fix the spelling there, because the classes were broken somehow. This and more is tracked by CAR 462513.

 

Finally, I remember seeing Stephen post somewhere that property nodes, due to their inherent case structure, prevent LabVIEW from optimizing the code -- even if the VI is set to inlined. For this reason alone I avoid them in any code I expect to be running at high-priority. For UI, however, I use them extensively.

The case sensitivity CAR is an interesting one.  I hadn't seen it yet.  Sorry it was a pain for you.

About the case structure issue.  Yes, there is a second case structure that gets inserted, but it's set up so that it defaults to the no-error case, which means it operates very quickly.  I haven't tested it thoroughly, but I don't think it makes a significant difference on performance.  You can also turn on the the "Ignore Errors Inside Node" option to remove a case structure on the calling VI.  And you can remove the case structure from the property implementation VI.

BONUS: I'll buy a (free) beer at the LAVA BBQ to anyone who writes a test that shows a big difference in performance between property nodes and subVIs.  Consider whether the subVIs are inlined, too.  I reserve the right to judge what a big difference is.  To be clear, the factors to consider are: 1) Ignore Errors Inside Node, 2) Case structure in property accessor, 3) Inlined accessor VI or not.  You immediately forfeit your right to a beer if some crucial part of your code gets dead code eliminated.  Competition ends August 4, 12pm CDT.  Really the only purpose of this is to settle the question once and for all.

Does anyone have some code they'd be willing to send to NI that replicates this issue?  Or detailed steps to reproduce?

I was curious when you guys are encrypting files, where do you store the key? I have heard if you open a LV Binary in a hex editor you can relatively easily read string constants, so hardcoding in an encryption key may not be the best idea. In general, I am not worried about this happening as I don't need anything "super secure", but I wanted to get other's opinions/solutions.

I don't have an answer for you, but I just wanted to point out that string constants would be scrambled in a part of the VI.  It'd be hard to see the encryption key -- you'd need to know what part to get out, how to get that part, and how to unscramble it -- but it's not there in plain text.  If that's suitably secure for you, then go for it.  But I'd recommend against it

Just to let everyone know, I've notified a few people at NI about the problem.  I'm not sure who to contact within NI, but I contacted people who probably know who to contact.

Mike B

National Instruments R&D

I assume you're being sarcastic. I guess I didn't really make that very clear. Sorry; I'll fix it!

By the way, could you maybe post some stuff about what each flag does? Or is that confidential?

Definitely not sarcastic.  It was entirely sincere.  Your older posts didn't include the warning at first and you edited them to include it.  Now you're including it by default.  Thank you.

What each flag does is confidential.  About a third of the flags are for edit-time features (like "object is grayed" -- but that's just a side effect of what the flag actually does), a third for settings on objects, and another third for flags for the compiler.  That's all I'll say about it.

I found an interesting private property for the GObject class: Basic Object Flags. This provides low-level access to an object's flags, such as (for controls) the mechanical action, disabled/grayed behavior, etc. Some of them cause very strange behavior, which is not surprising for a private property. I can confirm that this is the same as the "flags" value seen in Heap Peek.

 

I wrote a VI (attached here) that lets you change these flags. Just wire a GObject reference to it, and the front panel will pop up and let you interactively change the flags and see the results. Does anyone have any more information on what some of the flags do exactly? Here's what I have so far for controls:

 

 

00000008 - Object is disabled (sort of like it forgets it exists)00000010 - Object is not selectable00000020 - Object is not resizable00000080 - Object is grayed00004000 - Object exhibits strange behavior, becoming grayed at random00010000 - Affects mechanical action00020000 - Affects mechanical action00040000 - Affects mechanical action

 

 

Object Flag Manipulator.vi

 

(For those unfamiliar with private properties/methods, they're additional properties and methods that remain hidden even when scripting is turned on. To enable them, just add "SuperSecretPrivateSpecialStuff=True" to LabVIEW.ini, but be warned, this is internal low-level stuff that NI doesn't support.)

Thank you for being much more explicit about the dangers of playing with these things.

I'd be especially careful with 0x0000 00010, 0x0000 0080, and 0x0000 4000.  Different types of objects have different sets of flags stored in the same place.  Good luck.  You're probably going to be seeing a lot more strange behaviors once you start playing with non-controls.  And they're not good strange behaviors

Are you sure NI-IMAQ contains the barcode functions? I thought NI-IMAQ only contains the functions that are directly necessary for getting image data into the computer. The actual processing of images is then done with NI Vision Development Module.

 

And to heng1991, this software may seem expensive but once you have exercised your patience with trying to get external libraries not crash when trying to create an interface in LabVIEW for them, you will very likely agree that this price has a reason. Especially since unless you are very experienced with interfacing to external libraries you are very likely to create a VI interface that may seem to work but will in fact corrupt data silently in real world applications.

You're right.  It's in Vision.  I got bit by the same mistake 2 weeks ago and I thought I had memorized which is where.

But do anyone know how to decode the Code 39 and QR code by using labview?

Any .dll library or zxing library can be used?

You can use the NI-IMAQ package for decoding barcodes.  I'm not 100% sure about Code 39 (frequently called 3 of 9), but I know it can decode QR codes.  

I would think it would have sent.  If you can get me the report ID (the GUID in C:UsersYourNameDocumentsLabVIEW DataLVInternalReportsLabVIEWVERSION) corresponding to the crash, I can look it up.  just having the log file doesn't let me look it up.

Did you submit the crash report?  The minidump that comes with that is insanely helpful.  If not, can you attach it?  It's in: C:UsersYourNameDocumentsLabVIEW DataLVInternalReportsLabVIEWLabVIEWVersion on Windows 7.  You can figure out the path on other OSes.  A quick glance at the log doesn't give me anything immediate, but someone will take a deeper look if this gets filed as a CAR.  I'd need steps to reproduce and the minidump to file it as a CAR.

Call NI to obtain a SRQ from NI so that is issue is followed and can give birth to a CAR.

Or go to ni.com/ask and connect with you NI profile, it's pretty similar to calling, you only "lose" 1 or 2 days depending on how busy the AEs are, the advantage of that is that you can follow all the SRQs linked to your NI profile by logging on on ni.com/ask, I find it quick and easy.

And don't forget to post the CAR number in this thread!  

The documentation for Format Into String says that you can use escape codes in the format string.  (Search for "Use special escape codes")

Dang, but my sincerest thank you for addressing this.

No problem.  If it makes you feel better, I kudo'd the original idea.

It's still broken in a yet-unannounced version after LV 2012, whose version number remains entirely unguessable.

I filed CAR 382426. I have no workaround, since I don't know much about the compile process. I've noted in the CAR to post the workaround here if there is one.

This CAR has been fixed in LV 2013.  The fix should be in LV 2013 Beta 2.

MikhaelH: If you're part of the beta program, you can download the LV 2013 Beta 2 and test it out.  If not, PM me and I'll send you a link to sign up and my email address to get you into the beta program.

Thanks, Jarrod! I'll do some property node hunting and see what I come up with. I don't currently have scripting turned on, so hopefully this method will end up working in the RTE...

Both FrontPanelWindow:OSWindow and FP.NativeWindow are in the Run Time Engine.  They are not in RT (Real Time).

- Mike

This isn't the first time the EULA issue has been brought up. As long as I'm not doing what I'm doing to make a profit or anything like that (or to enable anyone else to), I'm pretty sure I'm in the clear. Correct me if I'm wrong, of course.

This is wrong.

Wow, this thread sure is getting off-topic.

 

NI doesn't make the law. (That would be silly.) Say I created a game, and I put in the license agreement that you weren't allowed to make mods for it. (For the record, I would never actually do that, as you may have guessed.) Someone made a mod for it anyway. Now if they were selling it, maybe even giving it away for free, I might be able to claim they're violating my copyright. (Without copyright law, software licensing is meaningless.) If they just modified the software on their own computer and played it like that, I wouldn't be affected in any way.

Generally speaking, in the US: Violation of copyright is something that a person does and they get in trouble with the government (fine or jail).  Breach of contract is something you do and you get in trouble with the other party (you get sued for monetary damages).  Both are illegal even though the person bringing the complaint (the district attorney or the other party) is different and the punishments are different.

I know cars are overused in analogies, but if I buy a car, and the manufacturer of the car says in the manual I'm not allowed to modify their copyrighted design by painting it another color, I can still do so. It's still my car. If the manufacturer goes that route with the copyright, they might be able to prevent me from then selling my car, but otherwise I can modify my car however I want. (as long as it's not violating any laws that would exist anyway.)  How is software any different in this respect? It's my computer, and while I may not own the rights to the software, that particular copy is still mine, as it exists only on hardware 100% owned by me.

 

As long as there's no damages, I fail to see how any legal action could be possible. You can't sue someone for pissing you off, even if they said they wouldn't. That's why I'm not releasing my password hack, as if someone uses it in a way that causes harm to NI or someone else, they might have a case.

Unfortunately, it's not yours.  I personally believe it should be, but that's not the way software licensing works.  It's not the way the software world works.  We gave you a copy of LabVIEW and you (most likely depending on what your license agreement says) have a intangible copy of it -- whether it's bits on your hard drive or on a CD -- and we grant you the right to use it for so long.  It's never your property.  I think it's absurd but that's how it works.

Uhh...didn't I? In the image? No offense.

Haha...I completely missed that...I just read the text of the post.

I've shortened quotes for sanity and added parenthesized numbers after statements to indicate what I'm replying to where.

[...] As for intellectual property, it's their fault for expecting miracles from what is essentially security through obscurity. If they care so much about their precious code, they can just remove the block diagrams, and deal with the side-effects. (1) Open source is the way to go, and NI shouldn't help people hide their code if those people choose to release it unencrypted. (2) If the block diagram is accessible to LabVIEW, but it doesn't obey the user who wants to view it, that is certainly not user-friendly, and I could even go so far as to classify it as a bug. (3)[...]

Also, does anyone else see the irony in describing a "feature" designed specifically to go against the wishes of the user whose computer it's running on, as a "user-feature"? And how is that not DRM? [...]

1. Yeah, it is kinda silly that people expect miracles from it.  That's why in 2012 we added this to the password dialog:
   
   And why we published Security of LabVIEW VI Password Protection vs. Removing VI Block Diagrams.
   And why we continue to openly state that it is circumventable and only provides as much security as a locked door -- a determined intruder will get in due to the nature of a house.  You want the homeowner to be able to get in a house and open the windows.  You want LabVIEW to be able to get into the VI and open the block diagram.  You can break the window or use a battering ram, or you can use the key.  NI made this clearer in 2012, though no amount of warnings or papers will be enough for some people.  That's why it's silly for people to rely on that.  But just because they weren't smart/motivated enough to protect themselves does not give you the right to break in.
2. Open source is great and I'm a huge fan.  I've been running various flavors of Linux exclusively for 9 years.  And I'm a software engineer.  I realize that although great things come out the FOSS community, it is very very very hard to make a living off of FOSS software.  Most FOSS software doesn't have a large enough user base (or code base) to make money purely off of support.  You need to pay for software sometimes because that's how the technology industry works.  We software engineers need to be paid, too.  If you're only looking at VIs and not misusing the contents (plagiarizing source code, redistributing, stealing) then I don't think there's much harm.  However, I think there is harm in immediately releasing information on how to break password protection because other people will misuse it.
3. You are not the only user.  LabVIEW is obeying a different user and disobeying you.  Why should LabVIEW disobey a different user and obey you?  Just because it's your computer doesn't mean you gain rights over other people.  You choose to run LabVIEW.  If a parent tells a child they can't have ice cream before bed, that doesn't mean the can have ice cream before bed in someone else's house.
   

[...] It is strange that NI seems to be putting this above things that seem more important to developers...[...]

This was probably on the order of 1/10000th the effort put into LabVIEW 2012.  We don't only have a duty to develop features important to customers, but also to continue to support older features important to customers, even if the feature isn't perfect and cannot be.  Don't throw out the baby with the bath water.

Well. The adult way to go about it is to furnish NI with the exploit so they have the chance of evaluating whether they want to expend the effort in plugging it before you release it into the public domain. This would allow you to gain a moral position rather than just looking like a petulant script kiddie. Careers have been made this way and the skills are usually prized rather than punished.

 

White hats and black hats come from the same milliners, however they are viewed and treated very differently both in the community and in the law courts.

[...]If I was just going to tell NI about it, I wouldn't have gone to the trouble of finding it in the first place. Who would telling NI help? (Other than NI, of course.) Who do you think I'm more interested in helping: a large company that makes millions of dollars from selling expensive software and hardware, or those products' community of users?

 

Again, I'd really like to release this hack, but I'm holding off because I'm not a lawyer, nor do I have a lawyer, and I'm not sure what kind of trouble if any I could get in by doing so. If anyone has any questions about the contents of one of NI's password-protected VI's, of course I'll answer them.

Although ShaunR opened with a bit of a dig that really blunted his message, I think he's definitely got the right message.  flarn2006, check out Responsible Disclosure and a quick list of companies with Responsible Disclosure policies.  Although NI doesn't have one, we have worked within the general framework of responsible disclosure with many people.  If you'd like more of an assurance, I can try to find something for you.

Finally, even if you're helping NI, it's probably not going to make us significantly more money.  It might not even make us money.  But you will also be helping customers by helping ensure customers have a more secure application.  You talk like you're fighting a battle for the proletariat, the unwashed masses of LabVIEW users, against NI.  In reality, we're pretty open to playing ball as long as you don't make it a pain.