Should I put this section of code into its own VI?

[David99999]

It's a simple question, but I don't have any senior labview guys to ask these types of questions to, other than you guys 😁 I'm reading a lot of values from the FPGA, and the current code I have makes it so I have to scroll vertical and horizontal.

And I just realized something. Technically I could even place the Read/Write Control Function into the subVI, freeing up more room. At first I was thinking I would be only placing the averaging and string/number functions in there

[Kyle97330]

Maybe consider doing this as a Natt Sequence. 

You're doing the same thing over and over again with minor variations, which usually would be a good time to consider a subVI, but it's problematic to use things like the point-by-point averaging from subVIs as well as the FPGA node.

So instead you could do something like this:

With each FPGA node getting its own case, and the constants and Mean subVI now condensing down into the 1st case , the shared "trim" code in the shared middle section, and then the indicator in a second case structure (I'm using a random property node as a placeholder for the FPGA node as I don't have FPGA).

However just as a general note, the process you're using to trim things to only show a certain amount of decimal places is a bit weird?  

I would normally change the display properties of each numeric indicator to show only the precision needed, or use mathematical rounding instead of a string conversion, but that may just be because I personally think it's a bit silly to convert things to a string and back if the string is never used or stored anywhere.

[David99999]

This is great, although I will have to spend some time looking at this because I'm new and have never seen things done this way 😁

And I'm glad that you pointed out that it's weird haha. I would MUCH rather not be converting to string and then back to normal, it's silly I agree. I can't remember when I wrote the code, but I'm like 99% sure I saw somewhere that that's what I had to do to trim a FXP. Yes, I could send it to a double indicator with a set length for trimming, but I wouldn't be able to do anything with it, I think? I would still need to convert it in a way that is....distributable.

I don't even think there's a rounding math function is there?

[Terry_ALE]

This part is more of an API and less FPGA specific.  Specifically this is like making an instrument driver, after all that is what we do with LabVIEW FPGA, we are making our own instrument.  And as with most instruments, a useful instrument driver is needed.  This information is covered here: https://www.ni.com/en-us/support/documentation/supplemental/21/developing-labview-plug-and-play-inst...

When designing the host (API) side of the FPGA based system, I recommend you think about how it will be used or modified in the future.

Who will maintain it?

Who will use?  (one application or many)

Some things cannot be squashed all that much.  I mean you do have a bunch of things being read back.

You could couple each reading from the FPGA and the processing into its own subVI.

[crossrulz]

---

@Kyle97330 wrote:

However just as a general note, the process you're using to trim things to only show a certain amount of decimal places is a bit weird?  

I would normally change the display properties of each numeric indicator to show only the precision needed, or use mathematical rounding instead of a string conversion, but that may just be because I personally think it's a bit silly to convert things to a string and back if the string is never used or stored anywhere.

---

The to and from string is an expensive operation.  If you can keep it in numerics, you definitely should.  All of those conversions with 0 width should just convert to an integer.  The ones with a width of 2 should multiply by 100, round, and then divide by 100.

[David99999]

This is great, thank you. I already asked Kyle in a response about this, but I swear when I was looking up how to trim an FXP into a value I could use somewhere else, that this was the only way.

But I must've been confused at the time, because surely I can still do mathematical functions on an FXP

[Kyle97330]

There isn't a built in "round to X decimal places" math function, just a round to nearest whole number, but it's not hard to do as a one-off subVI you can reuse:

[Hooovahh]

---

@Kyle97330 wrote:

There isn't a built in "round to X decimal places" math function, just a round to nearest whole number, but it's not hard to do as a one-off subVI you can reuse:

---

Oh yeah this deserves to be in everyone's reuse library.  I do use it a bit more generic than this with a "Round to Nearest Increment" but I think when I've used it, it has always been to a power of 10 anyway.

I know it can be a bit expensive resource wise, but you could also think about trying to put the mean for the signals on the FPGA side.  That way you can read the average of N samples using the property node.  With so many division (or MUX) operations needed this might not be the best design for you.  But I thought I'd suggest it because for me I like to put as much on the FPGA as possible, since it frees up resources and work that the host would normally have to do.  But still a general purpose CPU is probably more capable than an FPGA for this number of average operations.

[altenbach]

---

@Kyle97330 wrote:

There isn't a built in "round to X decimal places" math function, just a round to nearest whole number, but it's not hard to do as a one-off subVI you can reuse:

---

Of course there is absolutely no guarantee that you get a clean decimal truncation due to the limitations of the internal binary representation of floating point numbers (e.g. 0.10 might be 0.100000000000000006 as DBL) . For true decimal truncation, you need to use a string indicator. 😄

[billko]

---

@altenbach wrote:

---

@Kyle97330 wrote:

There isn't a built in "round to X decimal places" math function, just a round to nearest whole number, but it's not hard to do as a one-off subVI you can reuse:

---

Of course there is absolutely no guarantee that you get a clean decimal truncation due to the limitations of the internal binary representation of floating point numbers (e.g. 0.10 might be 0.100000000000000006 as DBL) . For true decimal truncation, you need to use a string indicator. 😄

---

Yes, this is true.  I always point this out to whomever tries to tell me they have a way to round FP numbers to the nearest decimal place.  This kind of rounding is only good for comparisons, end even then, you stop after round to nearest (I also convert to integer to make sure the comparison is actually on integers and not FP).