multisim to fpga

[MirceaRuba]

Hi all,

I was wondering if it is possible to export a power electronic circuit built in Multisim to a certain source file or something that later can be uploaded on fpga via lv fpga to test controls and stuff like that.

Thx,

M.

[AL3]

Hi MR,

probably you could perform a FPGA-Multisim Co-Simulation. Have a look here: http://www.ni.com/white-paper/14154/en/

Both the FPGA VI and the Multisim model are executed synchonously even if the time evolution is not "real-time".

Cheers,

AL3

[MirceaRuba]

Thx AL3,

I am interested in creating Model in the Loop simulations, running a power converter model on one FPGA and it's control on an other FPGA. Both communicate using wires like in a real model. So I would like export models from Multisim to upload on the FPGA. If it is not possible then I will use state space models.

Best regards,

M.

[BMac]

You may also be interested in the StarSim FPGA Express real-time simulator. It is fully released and runs on CompactRIO. You use the StarSim editor to create the circuit model, and it is automatically downloaded to the LabVIEW FPGA target.

You may be interested in the OpalRT EHS Solver tools for LabVIEW FPGA that are being developed and releasing soon. Basically, you export the circuit netlist from Multisim, and it automatically loads it into LabVIEW FPGA for high speed real-time simulation. However, you currently must use special components for the circuit model you export.

Just a word of caution-- the LabVIEW FPGA support for the OpalRT solver is still being developed and the tools are not fully released. My colleagues involved may want to chime in to share the current status and timelines. However, it is very exciting that NI sbRIO and CompactRIO hardware can become a high speed real-time simulator with automatic download of models and no recompile needed when changing the simulation model.

They will be sold on the NI Tools network. You can download and check out the first version software from VI Package Manager, which only runs on the cRIO-9068 with appropriate modules.

vipm://flexible_ehs_real_time_power_electronics_simul_toolbox_(crio9068)?repo_url=http://ftp.ni.com/...

This is the "flexible" version of the EHS solver which let's you load in any circuit model with up to N switching devices (transistors and diodes) and takes over the entire FPGA to turn it into an HIL solver. You wire to your control system using physical I/O signals (i.e. the cRIO analog output modules simulate voltage/current sensor feedback, and the cRIO digital input modules read the PWM command signals for the IGBT top and bottom switches.) Here are diagrams that explain:

A little further in the future, the "open" version of the EHS solver will release. This enables you to place your control application and the real-time simulation in the same FPGA. This approach is often called "digital twin" real-time simulation since the control system interfaces both to the physical world, and to a model of the physical world as illustrated below.

I am very excited about this "open" version, since I often use embedded real-time simulation models to develop and test power electronics control code. Today, I hand write the models as differential equations with integrator solvers or as discrete transfer function or state-space models. I have found it to be a 10X productivity boost for control code development. Here is a screenshot from a GPIC buck-boost converter application where the physical measurements and digital twin real-time simulation values are plotted on the same chart.

Note that my hand written open source IGBT half-bridge model includes switching, conduction losses and IGBT junction temperature. This won't be available with the more idealized Pejovic switches of the OpalRT solver. In the screenshot above, the switch model used the same parameters for IGBT and Diode, so the optimizer picked the best compromise. In the latest version (in the Power Electronics Master IP Library) they have different parameters so the voltage waveform matches even more closely.

The real-time simulation model is often kept in the FPGA control chip after deployment and it can be used for many things such as active junction temperature regulation for IGBT lifetime extension, automatic tuning, prognostics and more. Here is a summary organized by stakeholder.

Here is an example of a digital twin model I use to develop and test grid tied inverter control code. It simulates the inverter current given the half-bridge output voltage and grid voltage, given the parameters of the line reactor filter. It's great for developing grid tied inverter control applications. (The new LCL line reactor discrete model still needs a bit of work however, BTW, particularly if used with PWM voltage waveforms.)

The code above is currently under development/testing and changing rapidly but if you want to check it out you can find it in the Power Electronics IP master library here:

C:\LabVIEW 2015\GPIC\GPIC Reference Design\FPGA DDS\U64 DDS Generation 3-Phase Sine-Triangle.lvproj

To learn more, download my full slide deck here.

[HIL_Tech]

BMac, hi

I was hoping to learn some more details about the NI ‘open’ eHS tool for LabVIEW FPGA.

At this point, I have slightly more than a year invested in Simulink model development for deployment to eHS on an Opal-RT target.  Do you know if the new eHS tool would be compatible (somehow) with the importing of Simulink models developed for eHS?

Will the open eHS tool provide additional compatibility with other NI FPGA product families, beyond the CompactRIO?  Is the eHS tool planned to be a function pulled off an FPGA module palette that behaves like any other block diagram function?  Would more than one eHS ‘core’ be allowed in the same LV FPGA design?  Does the LabVIEW FPGA developer have full access to (and control over) the eHS signals and I/O?  Traditional LabVIEW FPGA I/O node access (C-Series, Flex-RIO socketed CLIP, etc.) to the same signals being used for PWM inputs and voltage/current outputs of the eHS model?  Ability to add other LV FPGA functions to the same signal lines?

Opal-RT’s recent release of the Gen3 eHS has several improvements toward reducing parasitic oscillations, losses, and automatic Gs factor calculations for the switching devices.  Enhancements that all my existing eHS models would definitely benefit from.  Are these Opal-RT eHS features applicable to the tool used in the LabVIEW FPGA environment?  Does the NI developer have access to setting Gs factor values?

Could you elaborate further on details of the NI implementation of eHS?  Or maybe explain the main differences from the Opal-RT eHS implementation?  Does the NI solution use eHSx64, eHSx16, eHSx64 Gen3?  Are these feature topologies relevant to the NI implementation?

Any details would be greatly appreciated!  There are many projects and applications I’d like to pursue in our lab that would be greatly expedited by the ease of developing FPGA fabric around the eHS using LV FPGA instead of Xilinx XSG.  And a complexity which is possibly only feasible to pursue pending availability of a truly ‘open’ eHS solution for LabVIEW FPGA.

[FrancoisBerthel]

Hi there,

-As of today, eHS on NI platform allows you to import SimPowerSystems netlists, PLECS Blockset netlists, PSIM netlists and Multisim netlists to the NI FPGA.

-eHS is now supported on cRIO9068 (Zynq7020), cRIO9039 (Kintex 7 K325T) and PXIe-797xR FlexRIO (Kintex 7 K410T).

-eHS on NI platform is the same as eHS on OPAL-RT platform. You design your circuit in one of the supported modeling environment, then eHS extracts the netlist and runs it on the FPGA. When using the same FPGA on an NI platform and on an OPAL-RT platform, the performances are the same.

-Depending on your eHS license:

     ---The basic dev license requires LabVIEW-RT: you can modify your circuit and run in on FPGA. Comes with default I/O          mapping/scaling.

     --- The full dev license requires LabVIEW-RT and LabVIEW-FPGA: on top of the capabilities of the basic dev license, you can fully      change the I/O mapping, add FPGA signal generator / control logic and regenerate new firmwares.

-On the PXIe-7976R, running two eHS cores has been achieved in an R&D environment, but it was at the very limit of the FPGA capabilities. Other NI FPGAs support only 1 eHS core. To run two eHS cores and still have extended FPGA capabilities, the Virtex 7 found in OPAL-RT's OP5607 and OP5707 is preferred.

-Yes, you can tune Gs on the NI platform.

-cRIO9068 currently supports eHSx16 (Gen1), and Gen3 is planned for the end of 2016. cRIO9039 and PXIe-7976R both currently support eHSx64 (Gen3). eHSx32 is not supported on NI platforms.

-Things you can do on an OPAL-RT platform that you cannot do on the NI platform as of today:

     ---eHS on NI platform does not support scenario testing.

     ---eHS on NI platform does not support timed-stamped digital outputs (TSDOs) for firing/PWM logic generated on CPU

FB