Jump to content

Mr Mike

Members
  • Content Count

    122
  • Joined

  • Last visited

  • Days Won

    12

Mr Mike last won the day on April 30 2014

Mr Mike had the most liked content!

Community Reputation

57

About Mr Mike

  • Rank
    Very Active
  • Birthday January 5

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.

  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 recru
  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
  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 structur
  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 case
  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.