Components

cancel
Showing results for 
Search instead for 
Did you mean: 

Automotive Engine Simulation Library for HIL

Please provide feedback, comments, and questions on the
Automotive Engine Simulation (AES) Library for HIL,

HIL Automotive Engine Simulation Reference Example,

and NI VeriStand Add-on - Automotive Engine Simulation

in this thread

Message Edited by Daryl E on 11-03-2009 02:24 PM
0 Kudos
Message 1 of 54
(17,267 Views)

Hi, I'm starting to work with the AES Add-on for Veristand and I need to modify the custom device in order to use a different R Series model, the PXI-7851R. I've downloaded the reference example and I have compiled the FPGA VI to the new target. Now, I need some help on how to integrate this modification to the custom device with no problems.

 

Any help is appreciated

 

Andre Pereira

Field Sales

NI-Brazil

0 Kudos
Message 2 of 54
(17,111 Views)

Hi Andre,

 

The custom device was created with the idea that others may wish to extend it to use a variety of different FPGAs. As you open the source code for the Engine Simulation Custom Device, you'll find a Contros Virtual Folder under the Engine Simulation Custom Device.lvlib. Within this folder, you'll find a TypeDef for FPGA Target.ctl.

 

 FPGA Target Enum.png

 

This TypeDef is an Enum that allows you to select which FPGA target you wish to run the custom device on. The first step will be to add an additional item to this Enum for your FPGA Target (i.e. 7851R). At this point, you'll be able to select the new FPGA target on the Main Page of the custom device (Engine Simulation Main Page.vi).

main page.png

 

If you then open the Engine Simulation RT Driver VI.v, you'll see that the FPGA calls are all wrapped up in SubVIs (Set FPGA Config, Run FPGA, Set FPGA Crank Cam Throttle, Set FPGA Outputs, Get FPGA Inputs, and Close FPGA). In Set FPGA Config.vi you'll find that a case structure will execute the Open FPGA VI depending on which FPGA was selected in the FPGA Target enum. At that point, the reference is written to a cluster that contains an FPGA reference for every FPGA Target type that was included in the FPGA Target enum.

 

In order to adapt the custom device to your 7851,

  1. You will have to add a case in Set FPGA Config.vi for the 7851. I suggest duplicating one of the pre-existing cases.
  2. Then you can configure the Open FPGA Reference to use the bitfile created for your 7851. I suggest binding it to a TypeDef.
    1. Note that there's a bug in #179896 LabVIEW 2009 that will cause the TypeDef created by the Open FPGA Reference to be empty and unusable. In order to work-around this issue, point the Open FPGA Reference node to an already-existing .ctl that has a control on its front panel. It's important that a control already exist within the .ctl file.
  3. Then you will need to modify the FPGA Ref Cluster.ctl TypeDef to include the TypeDef for the 7851 Reference.
  4. Within the Set FPGA Config.vi's case for the 7851, make sure you connect the FPGA Reference to the new reference for the 7851 within the FPGA Ref Cluster.
  5. Modify the Run FPGA, Set FPGA Crank Cam Throttle, Set FPGA Outputs, Get FPGA Inputs, and Close FPGA VIs to add cases for the 7851.

Set FPGA Config.png
Figure: Set FPGA Config.vi

 

 

Regards,

0 Kudos
Message 3 of 54
(17,100 Views)

I forgot to add one last final step:

You must then build the Configuration and Engine Build Spefications found in the project.

0 Kudos
Message 4 of 54
(17,099 Views)

I'm from PTTPLC. Could you give us any idea to simulate crank and cam in variable reluctance form ?

Or do you have any plan to develop them to your libraries ? Our engine have 36-2 crank and n+1 cam

(4 piston then 5 cam) as in attached. Thank you.

 

Shinapat Rhienprayoon

PTTPLC

shinapat.r@pttplc.com

0 Kudos
Message 5 of 54
(16,487 Views)

Hi Shinapat,

 

I do have plans to develop variable reluctance simulation for crank. Unfortunately I do not have anything currently ready.

 

I can certainly help with some ideas though. This solution isn't flexible in a general use case which is the reason why I haven't implemented it yet, but you could create look-up tables (LUT 1D) from those waveforms captured in your screenshot and then cycle through the look-up tables according to the crank angle (0-360) for crank simulation and adjusted crank angle (0-720) for cam simulation.

 

I'd like to do something similar to the above suggestion, except just have one waveform that I cycle through for each tooth. This is much more complex because I'd have to keep track of where my teeth are in relation to the crank angle and then correspond the tooth to a waveform instead of corresponding the entire crank or cam to a waveform.

 

My understanding is that most people typically only care about the 0V crossing between peak and valley so you could also rig up the current implementation of Hall-Effect sensor simulation to output between a positive and negative voltage. A VR Sensor also crosses 0V at the middle of a tooth, so the Hall-Effect output would also need to be phase shifted to account for this difference. Of course this won't provide the nice sinusoidal looking output, but it ultimately depends on what the ECU is actually checking.

 

If you'd like to discuss this in more detail, feel free to email me at mike.lyons@ni.com.

 

Regards,

0 Kudos
Message 6 of 54
(16,411 Views)

I have a litte Problem with the behaviour of the example.

 

I used it as it is, but removed everything but the cam/crk generation.

 

As soon I press the start button it is deployed and visually running, but at the output of the 9401 nothing happens.

Then I press stop, and start it again ... nice, it is running an generating a nice crk/cam Signal.

 

When I disconnect it from the power line, it is redeployed and again needs 2 times to start it up,

from then its working without any problem until the next power off/on.

 

Why this strange behaviour?

 

I added a 2sec delay to the fpga to give the cam-fifo a little mit more time to fill, but sadly this didn`t help.

 

Thanks a lot

 

Regards

 

Martin

0 Kudos
Message 7 of 54
(16,167 Views)

Hi Martin,

 

I apologize for the delayed reply. It's possible that you're needing to re-deploy twice after the power cycle because the FPGA is not having its reference closed properly. I would recommend properly stopping the application and restarting it without a power on/off to see if you still get the same behavior. I did not experience anything like this in my testing. This sounds like an issue with LabVIEW FPGA/Real-Time and not specific to the reference example code so I would recommend contacting your local support resource.

 

I would strongly recommend against the 2 sec delay you added to the cam FIFO loop. This could cause problematic behavior since the crank will be running for those 2 seconds. The code was designed to prime the FIFO before running the FPGA. Also the FIFO will be in the read state until it receives all the expected cam angles.

 

Regards,

0 Kudos
Message 8 of 54
(15,816 Views)

This is a notification that the device connections for the NI 9474 module for both the reference example and the NI VeriStand custom device were incorrect. Pin 4 is actually populated with Cam4Out and pins 5-7 are populated with 12VPWMOut1-3.

 

Regards,

0 Kudos
Message 9 of 54
(15,812 Views)

Excuse me, I've just downloaded the custom device lib of Automotive Engine simulation. I found it should support Veristand 2009 and I wonder whether it is still compatible in Veristand 2010 or is there any methed that we might use the lib in Veristand 2010?

0 Kudos
Message 10 of 54
(14,711 Views)