Jump to content

Mr Mike

Members
  • Posts

    122
  • Joined

  • Last visited

  • Days Won

    12

Mr Mike last won the day on April 30 2014

Mr Mike had the most liked content!

Profile Information

  • Gender
    Male
  • Location
    Austin, TX

LabVIEW Information

  • Version
    LabVIEW 2012
  • Since
    2009

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Mr Mike's Achievements

Newbie

Newbie (1/14)

57

Reputation

  1. 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.
  2. 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
  3. In case anyone stumbles on this, this more name documentation here.
  4. 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 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.
  5. 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. 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.
  6. Wow. Lots to respond to here. You can also pass in floating point numbers, but be careful: LabVIEW uses the IEEE 754 round-to-nearest even integer rule when rounding numbers that end in .5. 102.5 rounds to 102. 70.5 rounds to 70. 71.5 rounds to 72. Also, the behavior changed in LabVIEW 2010. To Upper Case, To Lower Case, Octal Digit?, Decimal Digit?, Hexadecimal Digit?, White Space? and Printable? all allow you to wire in a numeric. According to their documentation, those nodes evaluate the numeric as the ASCII character corresponding to the numeric value and in all other cases return FALSE. In LV 2009, they return false for any value over 256. In LV 2010 and later they return true for some values -- corresponding to the proper return value for the lowest 8 bits. E.g. LV 2009's White Space? primitive returns true for Int32(10) -- the line feed character -- and false for Int32(266). In LV 2010 it returns true for both. I'm usually the loudest complainer about people treating strings as a byte arrays. In most programming languages, strings are not bytes arrays. In some languages, for legacy reasons you can treat them as byte arrays. In LabVIEW they are byte arrays. That results in interesting things with Multibyte Character Sets. I don't have any of the Asian localized LabVIEWs installed, but I think strings in those languages will have a string length reported as twice the number of characters that are actually there. When you have the unicode INI token set, this is definitely the case. Arguably that's wrong, but there's no way to go back and change it now. I couldn't agree more to your first three paragraphs, but I've got to disagree about the difficulties. The platforms which are supported is entirely related to the language and compiler for that language. Any time -- absolutely any time -- strings move from one memory space to another (shared memory, pipes, network, files on disk) the encoding of the text needs to be taken into account. If you know the encoding the other application is expecting, you can usually convert the text to that encoding. There are common methods for handling that text that doesn't convert (the source has a character that the destination doesn't have), but they're not perfect. The good thing is that it'd be extremely rare since just about everything NI produces right now "talks" ASCII or Windows-1252, so it's easy to make existing things keep working. What you're talking about is how the characters are represented internally in common languages. In C/C++/C# on Windows they're UTF-16. In C/C# on Unix systems they're UTF-32. As long as you're in the same memory space you don't need to worry. There is no nightmare. Think of your strings as sequences of characters and it's a lot easier. As soon as you cross a memory boundary you need to be concerned. If you know what encoding the destination is expecting you encode your text into that. If/when LabVIEW gets Unicode support, that will be essential. Existing APIs will be modified to do as much of that for you as possible. Where it's not clear, you'll have the option and it'll default to Windows-1252 to mimic old behavior. Any modern protocol has its text encoding defined or the protocol allows using different encodings.
  7. Does anyone have some code they'd be willing to send to NI that replicates this issue? Or detailed steps to reproduce?
  8. 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
  9. 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
  10. After what I've read in this thread, I think there may be a bug here. I've filed CAR 440207 to investigate this behavior. I'll update this thread when I hear more information. While I understand and appreciate hoovah's sentiment that you should just trust the compiler, I think that blindly trusting it is not always the best idea. There's a lot that can go wrong. It almost always does the right thing. And it reflects well on LabVIEW that you trust it so much. But sometimes it doesn't do the right thing. It's important to look at LabVIEW with a critical eye sometimes.
  11. 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.
  12. 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
  13. 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.
  14. 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.
  15. 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.
×
×
  • Create New...

Important Information

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