LabWindows/CVI Idea Exchange

Comparison between floating point numbers is best done using FP_Compare() - see CVI help for details.

Often you need to choose the maximum (or the minimum) of the two floating point numbers, and the most common approach is:

if (a > b) {

choose a

} else {

choose b

}

If you use FP_Compare instead of ">" you'll notice that FP_Compare is much slower than ">" (because it involves calculation of the ratio between the two numbers). This is extremely evident if you have to choose the maximum of several couples of numbers.

I think that the maximum (or the minimum) between two floating point numbers could be found in a more effective way, comparing the exponents of IEEE representation (for example), and calculate the ratio only if the exponents are equal.

For this reason I suggest two new functions FP_Max() and FP_Min() that would much more performant than the easy approach.

In this thread it has been discussed how PlotScaledIntensity() handles NAN values.

In CVI 2010 SP1 NAN values are plotted with the center-scale color (and this is a bug).

Unfortunately the fix is not easy, and there could be different ideas on how NAN values should be handled.

I suggest not to plot NAN values, or to plot them transparent so that the plot area size is visible under NAN pixels.

When you use NAN values in PlotY(), for example, this points are not plotted.

There is no way in the current Serial Com functions to determine where a BREAK or FRAMING (or other) error occurred in the input steam (see Reference#7355407).  Add a new "ComRdStatus" to log the UART Status for each and every character individually.

Your "driver" code would be:

     When CHR received in UART

          Get STATUS from UART and put in ComRdStatus buffer     // New array of Status bytes for each character

          Get CHR from UART and put in ComRD buffer                   // Same as it is now

          Increment count returned by GetInQLen                            // Same as it is now

Then user S/W can be:

     While (GetInQLen(port) > 0)    // characers and their status's in queue

          ComRd (port, &chr, 1)                // read character

          ComRdStatus (port, &status, 1)     // read character's status

          if (status != 0)    // check if any status bits set

               if (status & BREAK_BIT)     // Check if this character is a BREAK

                    // Process BREAK condition at the point it happened

               if (status & FRAMING_BIT) // Check if this character had a Framing error

                    // Process Framing Error at the point it happened

               if (status & OVERRUN_BIT) // Check if this character had a Framing error

                    // Process Framing Error at the point it happened
               // ETC to handle all errors at the point in the stream they happened

          else // no status bits set so this Char is "normal"

               j// Process "normal" chr

This would let the user know EXACTLY where the BREAK (or Framing or Overrun or ...) condition occured in the queue.

Right now, if you have 15 characters in the queue and GetComStat says there is one or more "status" bits you have *NO IDEA* whcih character(S) had the status issue.

     E.G. if there is 15 chars in the queue and 5 are 0x00 and BREAK_BIT is set in GetComStat you have no idea which 1 or 2 or 3 or 4 or 5 of the 0x00 bytes where the BREAK and user's need to know this!