crossrulz

In LabVIEW 2017, there is the Malleable VI (vim). This will adapt to the input type. In previous versions, this was a hidden feature called "macros".

There were several improvements that were made due to the Champions griping enough and actually got some R&D ears. I do not remember if those made it into 2017 or if they were pushed to SP1. The new feature in 2017 that annoys me is the autowiring when you drag code into an out of a structure. You can turn that off by pressing W during the drag.

A few things need to be discussed here: 1. Does your message protocol have a Termination Character? This is common for ASCII messages and is typically a Line Feed. If you are using a binary message protocol or your message does not have a termination character, then you need to turn it off (boolean input at the top of Configure Serial Port). 2. If you know how many bytes you are to receive in a message, then tell the VISA Read to read that many bytes. If the termination character is involved, then you tell it to read more than you expect and the termination character will stop the read. Regardless, because you are using a command-response protocol (the instrument only sends you data when you request it) you should let the timeout tell you there is no data.

Discussion on the NI forums: LabView vulnerability allows hackers to hack your computer And the patch that is due out sometime: Incomplete RSRC Validation in LabVIEW

Not that I am aware of. But yourscheme is not much better. You really should have descriptive names for your VIs.

If you are just adding to the end of the enum, I don't think the enum constants are supposed to reset. I have ran into issues when changing names and/or adding in the middle, but the Update Typedef tool is used to fix those. Now I have to go play around with this...

If going that far, I would just add the Open and Close cases as well and then just leave the file open. It would be a little faster as it avoids all of the opening the file and parsing the data etc.

cross point on the dark side: CRC-16 Calculation from C code

Sounds like the classic floating point accuracy issue to me.

I tend to bound back and forth depending on the application. At some point, it just becomes way too many User Events to try to keep track of when you use individual events. I think I only had 1 application where this became an issue. But on the other hand, it is quite nice to only register for the events/messages that that specific process cares about instead of having to process all messages.

Here is my 16-bit CRC saved in 2009. 16-bit CRC.vi

crosspost on the dark side

What do you consider "expensive"? For most of my test systems, by the time I put in certain upgrades, I have been quite consistant at $1500 with Super Logics.

There's a reason I always gave management an estimate that was 4x what I thought it would take. They would always cut an estimate in half trying to win the bidding war and then crap happens which causes things to take twice as long as you initially thought. Hey, I was right on budget! How did that happen?

Do you really have an application that needs that much optimazation? You likely have other issues if that is the case. Anyways, you can do that exact logic easily enough without the AND. Note: The FALSE case just has the FALSE value passed through.

It should NOT be enabled by default as of LabVIEW 2014. NI knows that is a security hole and has WebDav instead enabled.

Sounds like somebody make a new Shortcut Menu Plugin. A bunch of community made plugins were posted here, but I don't think I've seen a spell check one.

A solution was found in the cross post I linked to above. The solution was to use Unflatten From String

I actually got a couple of wrist wraps that had a pad built in. These helped a little bit. In the end, I found that the desks that I was using (mostly at a customer site) was the main issue. Been working from the office a lot more (which have musch better desks) and my wrists have not bothered me hardly at all for almost 2 years now. I haven't even used the wraps.

Sounds like you need a digital output. How much current do you need for this 5V output? You may need a relay to control the output voltage.

I also highly recommend Tom's book. It was well put together and even taught me a couple of things.

I'm moving my current projects to use 2015. Have not ran into any issues yet. As Brian stated earlier, NI has focused a lot of their energy on stability. So 2015 is practically 2014 SP2 (just with a couple of new features). If you are going to upgrade, I would just move up to current and then use the SP if/when it comes out.

cross-post on the NI Forums

Yep, ran into that issue as well. I had to take the cycle mean and subtract that from the waveform and then calculate the RMS. I wonder if I still have that code floating around here...