Відео

The most commons use case is to deploy to speedgoat real-time hardware as MathWorks directly supports this vendor. However, you can use pretty much any real-time hardware for this workflow. This would be in order to implement real-time hardware in the loop testing. This allows testing without high voltage/current HW for initial test/debug of control hardware. FMI is a specific way of implementing models so that disparate models from different software vendors can be combined in a unified framework (the idea is usually nicer than the reality as its very hard to integrate models from different tools even if there is an interface for it). DPI C is a specific way of using c code to integrate with tools often used for chip design to do verification of designs. (xilinx/cadence are examples)

For a given load and a specific topology, ripple is primarily controlled by the sizing of your components and switching frequency or switching approach (not all approaches have a fixed switching frequency). You can also put converts in a parallel with phase shifted carrier signals for PWM. Different control approaches can be used to improve harmonics, but at steady state, if operating at the same switching frequency, ripple will be the same across control methods.

Unfortunately, some of the LTspice models uses LTspice proprietary functions that don't import, so I have to look for PSPICE equivalents or hand modify the file to get the import to work. At that point I'm more likely to just use the n-channel mosfet and parameterize it from the data sheet.

​@@electrificationenthusiasts8611hello, do you have a video about how to parametrize the n-channel mosfet from datasheet?

You're welcome

Thanks! I hope to, once I adjust to being a new father...

Thank you!

The most likely culprit would be that the dc voltage source is set to 0V, or that the PWM signal isn't actually turning on the Switch (check if it is correct value, and that it is connected). Other than that, a connection error is possible. MathWorks provides working examples that you can also work off of: www.mathworks.com/help/physmod/sps/ug/buck-converter_example-ee_switching_power_supply.html

You are welcome!

Unfortunately that is a pretty common error. It usually means the model as set up isn't realistic, but typically requires someone to look at the model and debug it to see what is wrong.

To get simscape outputs, you use sensor blocks or the probe under simscape utilities.

A computer simulation is almost always an estimation of numerical equations, and even those equations if solved analytically, are a simplification of reality. For an ODE solver, which plays a large role in Simulink, certain algorithms have a tendency to either over estimate, or under estimate the integral of an equation. This is particularly noticeable for first order methods like forward and backward Euler. If you are using a variable step solver such as ode23t or the DAE solver, you probably aren't going to see an issue with damping. However, to make sure, you can tighten your tolerance and see if the simulation changes. By default, the simulation tolerance is rel: 1e-3, and abs: auto. You can change both of these to 1e-5 and see if your simulation results change. If there is no difference, it is likely an issue with the model or model parameters, and not the solver. If the tighter tolerance makes a noticeable difference, then you have a particularly challenging topology for the solver to handle and will need to have slower simulations with the tighter tolerance to get accurate results. Having particularly fast frequencies on top of an otherwise slow system (think wide bandgap device turn on and turn off transients compared to line frequency) can be a reason you would need tighter tolerances. One thing that happens when the tolerance is made tighter, is essentially the solver takes smaller time steps (I'm leaving out why and how for brevity), and the smaller the time step, the more accurate the estimation of the integral. The integral error approaches 0 as the time step approaches 0, but it is physically impossible to have a time step of 0, so you always have some error.

The simple reason is that is is much easier to put together complex models in Simscape than Simulink. Simscape supports bi-directional connections while all Simulink models must be represented by input and output ports. This makes Simscape models much easier to maintain and change compared to Simulink. Getting deeper into the math, the Simscape engine can solve DAEs which allows for more accurate representations of things like variable resistances and other physical realities that can't be represented as well by an ODE. A good exercise if you have free time, is to design your own RC circuit in Simulink and then in Simscape. Then add another RC circuit across the capacitor of that circuit. It is very easy to do in Simscape (just cut and paste), while it is hard to do in Simulink (your must rederive all of the equations).

You are correct. One rule of thumb I use to simplify the decision is this. If you are going to implement your controls in a digital/embedded system that is clocked, use Simulink, and break the loop with a unit delay representing the controller update rate. If you are implementing it analog, leave everything in simscape (granted, it's easier to tune the controller in Simulink). However, if you want to go to Simulink for the loop design, there is a trick to getting past the algebraic loop although it's a little bit of a hack. For instance, if you want to close the loop on the inductor's current, you can measure it's voltage with a sensor in Simscape and pass that signal through an integrator in Simulink, divided by the inductance. This will tell you the current very very very closely to what simscape will calculate, and having the integrator in the Simulink portion of the model breaks the loop. This would cause problems if the simulation was run for a very very long time, but the error is so small it takes a while to accumulate and is very useful for tuning gains and using the controls toolboxes for initial loop design before going back to the hardware design for implementation.

I'm looking into this, they released an example here: www.mathworks.com/help/physmod/sps/powersys/ref/cccvbatterycharger.html but there are no files associated with it. It's a good document to explain the nuances, but doesn't provide a good starting point. This is a file exchange entry that has decent reviews that tries to implement it: www.mathworks.com/matlabcentral/fileexchange/72570-lithium-battery-charger-block?s_tid=srchtitle. The best way to do it is to model a converter that changes control modes from voltage to current, but this requires designing two closed loop control systems and coordinating the transition between them, which isn't an easy starting point. To do something simple, you could have a controlled voltage source behind an inductance in parallel with a controlled current source. Put an ideal switch on the output of each one and switch between which you want to use (there will likely be an artifact at the cross over point unless you add some snubbers/tune circuit paramters to clean it up.)

@@electrificationenthusiasts8611 please i wanna know how to creat a block of loss in simcape for an induction motor

You can bring c-code blocks into Simulink, you would need to interface them to the simscape network through controlled current and voltage sources.

please do you have an idea about how to creat a block of loss in simcape for induction motor

the black circuit elements are part of a sub library called specialized power systems. They use a different technology implementation and are not compatible with standard simscape components. There are ways to connect them, but generally make the simulation slow or unstable. Most times, there is a direct equivalent block in the simscape library that you can use instead.

I suspect the black mosfet is just to provide more of a physical interpretation to standard simulink blocks. While simscape is true implicit modeling with predictions for both current and voltage and so power delivery occurring at the terminals So I guess the black components are masked subsystems to be more representative of actual electrical components