Denormalized floating-point numbers

Recently, when debugging with Visual Studio 2019, I noticed that a variable had the unusual value of 6.324...e-322#DEN. This is "almost" equal to zero. In Visual Studio's debugger, the #DEN label refers to a denormalized (or subnormal) floating-point number. This occurs when the value of a floating-point variable is so close to zero that it cannot be represented in the normalized format of the IEEE 754 standard.

A floating-point number is typically represented as:

This is called a normalized number because the leading digit of the fraction (mantissa) is assumed to be 1.

When the exponent is at its smallest possible value (the minimum exponent), and the number is still too small to be represented in the normalized form, it is stored as a denormalized number. For denormalized numbers, the leading digit is 0 instead of 1, so the representation becomes:

Denormalized numbers fill the gap between the smallest normalized number and zero. 

By the way, it turned out that the strange 6.3...e-322#DEN value I was observing during debugging was due to an unitialized variable.

You can use the following C++ code to investigate further:

Strange error when generating C code from Simulink

When I tried to generate code from a recently updated Simulink model, I got "index exceeds the number of array elements. Index must not exceed 0". This error happened only during code generation, not when running the model. After spending a day, I found out that the reason was forgetting the folder separator "\" in an entry in Model Configuration Parameters > Code Generation > Custom Code > Source Code list, i.e. instead of "abc\file.cpp" the entry was "abcfile.cpp". A very unhelpful error message for such a simple error... A better error message would be "could not find file abcfile.cpp".

By the way, you can generate code from the MATLAB command line with slbuild('your_model_name').

Another error is "Invalid setting for input port dimensions of ...". If you are sure that there is no problem with port dimensions, close MATLAB, delete existing .mexw64 files, open MATLAB and regenerate them.

Finding root cause of latencies

A common issue in real-time hardware-in-the-loop simulations is latency in components that run on separate computers. These latencies can significantly degrade system performance. To differentiate between delays in component operations and network latency, you can send timestamps along with the data, log the time at reception, and record both timestamps:

Since components A and B have different clocks, you cannot directly compare the send and receive times. However, you can calculate the differences separately. If diff(timeSend) == diff(timeReceive), the latencies are likely not due to network congestion or a faulty switch/NIC but rather to delays in the operation of component A. It is highly unlikely for time differences to be the same if there is a problem with the network, it could only happen if the network was always adding a constant delay for each packet transmission.

Of course, you should perform the file saving in a separate thread to prevent blocking other operations. To minimize disk access, write to the log file periodically, for example, by flushing the log buffer to the file once per second.