Frequently Asked Question
Press "Ctrl + F" to find the keyword of your interest.
If you wish to have a direct link access to the video timestamps, please follow these instructions.
Found this video helpful? Why not take the whole HIL Specialist course? A Certificate is waiting for you for free at HIL Academy.
Would you or your organization benefit from having these videos narrated in your native language? Contact us and let us know if you wish to contribute.
TRANSCRIPT
Hello! In the previous lesson, we discussed HIL architecture,
model mapping, and how this impacts the way we design our models. So far, you ve seen only
positive hardware utilization cases resulting in successful model compilation. In this video,
we will teach you how to deal with less fortunate cases where you hit hardware limits and need to
optimize your model in order to bring it to successful compilation and stable simulation.
In addition to offline troubleshooting in the compiler console, you will also learn
to troubleshoot your model during runtime in HIL SCADA. As you can see on the screen,
we will demonstrate these typical situations using the model we have developed during this course.
First, let s discuss matrix memory. A comprehensive explanation of matrix
memory was given in lesson 3.1, Model mapping in compiler console.
There, it was pointed out that matrix memory defines the maximum size of the
Standard Processing Core, or SPC, in terms of the number of passive
components and in the number of ideal switches.Let s find out what would happen if we surpass the
maximum matrix memory. In order to achieve this, lets add some passive elements and switches.
We ll add two additional contactors and one variable passive load to the DC link.
This load will be implemented as a simple variable resistor, with a SCADA input provided
as its controller. Lastly, let s add a capacitor between the inverter and the rest of DC link.
Now, when we compile the model, we ll receive an error that matrix memory utilization is
over 100 percent, and that we should make the needed corrections and restart the compilation.
What are the following steps we should implement to solve this issue? There are several ways
we could deal with this. The main approach would be to partition the model into cores.
As we are currently on HIL404, on configuration 1, we can see that we can have up to 3 Standard
Processing Cores. So, let s make use of them and partition the circuit into two separate cores.
In order to divide our model in two cores, we use an Ideal Transformer Coupling,
or IT coupling. To do this, we will use the Single Phase Core Coupling component.
By doing this, we now have two cores.
In the first core, we have the voltage source, ideal switch,
variable resistor, and capacitor. On the second core, we have the inverter,
the remaining ideal switches, and the induction machine.
Now, when we compile the model, we can see in the messages log that we have two cores.
There are links to components that you can use to trace their location
in the schematic and identify which sub-circuit belongs to which core.
In the matrix memory utilization section, we can notice that matrix memory utilization
has significantly dropped and the memory load is being shared between two cores.
The compiler has now successfully finished compilation.
Core couplings will be more comprehensively explained in lesson 3.3, Model partitioning.
If you are interested in a more comprehensive explanation on performing model partitioning
when matrix memory overloads, please check out our documentation, linked in the materials section.
Let's also take this chance to look at the compiler log in more detail. As you can see,
there are two tabs in the messages console the Output tab that contains both compiler report
and warnings, and the second tab containing only warnings and errors. Let s go to the second tab.
We'll address only the second warning the one warning us about a bad voltage loop.
If you take a closer look, you ll realize that the meaning of this warning is to warn
us that for a specific arrangement of the converter switches, the HIL won t provide
correct simulation results. When we receive this error, we must be sure that our externally
connected controller or our internally developed control won t bring our converter in this state.
Let s determine what this means for our model. As the Boolean values in the brackets suggest,
this warning is for the converter state where all the switches are closed and the contactors in
front are open. Since our control algorithm will never bring our converter in this permutation,
we don t have to worry about this error. There is a FAQ article linked in the materials section
which contains a more comprehensive explanation of this warning and what to do in case it appears.
Let’s now go back to the discussion about matrix memory utilization.
While IT coupling is a good way to our matrix memory utilization issue,
it isn t the only way to address it. Let s reset our model and try a different method.
The second approach we could take to deal with insufficient matrix memory is
to choose a configuration or device which provides more matrix memory.
Let s check possible configurations for HIL404.
Unfortunately, all configurations offer the same matrix memory capabilities.
Therefore, if you only have access to the HIL404, then you have no access to configurations which
have more matrix memory. Let s see what configurations the HIL604 device offers.
As you can see in the device configuration table,
Configuration 4 of the HIL604 device offers much more matrix memory.
Therefore, let s choose HIL604 with configuration 4 and see how it handles our model.
Now, when we try to compile, we finish the compilation successfully.
Notice that this is done on a single core, which was not possible on HIL404, configuration 1.
It s important to note that we can perform these compilation tests without actually connecting to a
HIL device, simply by setting the desired hardware configuration and compiling the model. This
means that if you have a specific model in mind before purchasing or leasing a HIL device, you
can already begin to build it to determine which HIL device or devices are right for your needs.
The last solution to consider could be that we reduce the model by removing components that
are nonessential to the model behavior. However, reducing your model should be considered only as a
last resort, as this may affect model fidelity.Next, we ll discuss how to deal with possible
problems that may occur during time slot utilization. This utilization is tied
to the matrix multiplier, as was explained in lesson 3.1, Model mapping in compiler console.
As we are now using a HIL604 with configuration 4, let s try to simulate
this model with a simulation time step of half of microsecond. We ll change this in model settings.
Now, when we try to compile this model, we are notified that timing constraints are not met.
There are two time slot utilizations which surpassed the limit time slot utilization of
core0 and time slot utilization of the machine.Let s discuss the time slot utilization of core0.
The most effective solution for time utilization of core
zero would be to split the model in two cores.
However, this would still not solve the second issue of time slot utilization of the machine.
An alternative solution for time slot utilization of the core would
be to change to a configuration which offers more peak processing power.
Since we are on HIL604, configuration 4, we can try switching to another configuration.
As you can see, by using configuration 5, we would increase the amount of peak
processing power, which would decrease the time slot utilization of the core.
Still, this wouldn t be enough to address the machine time slot utilization issue.
Reducing the number of elements in the model would help solve time slot utilization issues,
but again should only be used as a last resort.
There are several solutions which could solve both issues with time slot utilization
core and machine. The simplest way would be to increase the simulation time step, since
currently we are trying to simulate the model with a simulation time step of half microsecond.
Increasing this to one microsecond would solve the time slot utilization issues. However,
if an application demands a smaller timestep, we can still try to optimize the model by
replacing the VBR induction machine with a regular current source-based model.
For successful compilation, we would have to change the calculation method to constrain matrix.
In this way we ve made the whole model capable of running on half a microsecond.
We should note that this wasn't an issue when we were using the HIL404 device. Although the
HIL404 device offers smaller capabilities in terms of memory and maximum model size, it offers much
better circuit solver possibilities, allowing it to run this model at a half of a microsecond.
Let’s switch back to HIL404.
Let’s now compile the model.
As you can see, this model is successfully compiled for the HIL404 device.
Exercises like these can help you find a perfect HIL device for your
model and eliminate any mistakes from your purchase decision.
Now, let's cover some of the more common issues you might encounter during model creation.
We'll first expand our model in order to fully resemble a drive setup.
In order to do this, let s replace our DC voltage source,
switch, and variable resistor with a Three Phase Voltage Source component with passive
components on each phase, in order to model a grid. We ll set the RMS Voltage to 230V.
Then, let's connect a Three Phase Diode Rectifier, which we can connect to the DC bus. Lastly,
we will attach the single phase core coupling, this time connecting the red side to the inverter,
in order to divide this drive setup into multiple cores and finish compilation successfully.
When we go to the SCADA and start simulation, the Arithmetic overflow flag is raised,
and simulation results are far from correct. The reason why this is happening is because the
IT coupling is oriented incorrectly. For now, we can fix this by flipping the IT coupling.
We will cover the root causes for this issue in detail in lesson 3.2.1 Topological conflicts
and model degenerations, and we will cover Model partitioning in much more detail in lesson 3.3.
Incorrect coupling placement isn t the only possible cause of this issue.
Electrical machines can also cause arithmetic overflow when the snubbers of the machine are
incorrectly calculated inside the machine component. Arithmetic overflow can also
occur because a potential load is applied to the machine while the load torque exceeds the
electrical torque, causing the machine speed to go over the calculation limit.
A useful component during debugging of arithmetic overflow is the HIL Flag
status. Let s return to Schematic Editor and drag and drop it into our model and connect
the outputs we want to track to Digital Probes. The HIL Flag status provides binary signals at
the outputs that refer to the type of arithmetic overflow that is occurring, and whether it s a
core or machine arithmetic overflow. If you want to learn more about arithmetic
overflow and what causes it, please check our FAQ article listed in the video description.
Now let us discuss other issues which may occur.
When Signal processing was discussed previously during this course, we mentioned that we define
the execution rate of signal processing. For example, this simple control algorithm which we
created in order to control Three Phase inverter has an execution rate of 100 micro seconds.
What if we set an execution rate to be too small for the CPU to guarantee real-time computation?
If the CPU can t manage to run this code in the given time slot,
we will be warned in HIL SCADA by the computing interval overrun or CIO flag.
Let's experience this by decreasing the execution rate of our control algorithm to one microsecond.
As you can see, compilation finishes successfully but when we run our simulation,
the CIO flag pops up, warning us that the control
algorithm can t be executed in the given time slot of 1 microsecond.
As a rule of thumb, most power electronics models should not have an execution rate
below 10 microseconds and most microgrid models should not go below 100 microseconds.
However, the 4th generation HIL404 and HIL606 can grant you even faster execution rates.
This troubleshooting process can only be done on a real HIL device, since CIO issues only
occur during real-time simulation. If you want to learn more about the CIO flag, please check
out the link to our time slot utilization documentation in the materials section.
By combining this knowledge with what we covered in lesson 3.1 Model
mapping in the compiler console, we can identify two types of time validation.
Electrical domain time validation is done statically, where the compiler determines
if the FPGA can run the solver with the required simulation step. Meanwhile, signal processing time
validation is done dynamically as we just saw. It's for this reason that the compiler will prevent
you from starting a simulation with an electrical domain simulation step which is too small,
but only notifies you of an inadequate signal processing time step during simulation.
This lesson covered the most common issues you may come across during compilation and simulation. We
looked at circuit partitioning components, which are the most effective and most important tools
for resolving circuit solver overutilization. You will have a series of dedicated lessons devoted
to them later in this module. However, since the number of device cores is limited, they should be
used economically. This is why you need to know about the alternative solutions and modeling
tricks we covered in this lesson. If you want to learn more about these issues, please refer to the
Knowledge Base articles provided in the materials.
Thank you for your attention.
