Engine Simulation Custom Device Feedback

[StephenB]

Hi Jamesy,

Look at the status channels for the engine simulation custom device itself. What is the value of the loop duration channel and the count channel?

I'm guessing the loop duration is exceeding 1/3000 seconds so it cannot run that fast without going late. Unfortunately there are some low-level design issues with the custom device that cause it to run not-as-fast as it could... but I haven't had the time to improve its performance. You can work around this by reducing the amount of items you're reading. That will increase performance. For example if you don't need all the measurements for every event... you can right click them and remove some. Same for the APU and CAM VVT.

[jamesy]

Hi Stephen,

Even at 1khz the loop rate is more than 3 times 1/3000. I'm seeing  a 1ms ES loop duration at 1khz.

I'll start to take out signals as a last resort but really i need all of them.

Loop rates at 1khz

Graph showing ES loop duration at 1khz: y scale is in nano seconds.

Loop rates at 4khz:

[StephenB]

Hi Jamesy,

Can you clarify? I don't understand your last post.

Can you share the values of those two channels?

Thanks,

[jamesy]

Hi Stephen,

I added all the data above.

My objective would be to log a sample of actuator events at say 4000 RPM and plot these aginst crank/cam angle in TDMS format.

I assumed with a NI FPGA running at 40Mhz this wouldnt be a problem.

4000RPM/60 * 720 == 48000

1/48000 = 20us so say 10us logging

this would be 1mhz.

If this is not possible then 500us logging period would be the minimum we would need to do basic testing.

James.

[StephenB]

Hey James,

The ES count indicator shows your engine simulation is going late very often, so your data will contain "jumps". This explains the issue with your data logs. Ideally, ES Count would be 0.

Unfortunately it is not possible to log "single point" channel data at 10us because this would require NI VeriStand to run at 100 kHz, which is impractical for a CPU. You have two alternatives:

1. Log data at a much slower rate. The aforementioned issues with the performance of this add-on cause it to perform poorly with many measurement items. If you reduce the amount of items the add-on is reading it should run faster, allowing you to run maybe 1-2kHz with no late counts. Inside system explorer right click as many items under engine simulation as possible and remove them. You could also wait for me to improve the performance of the add-on, but this will take quite some time since I'm swamped at the moment, and it would never be able to reach 100kHz, maybe 5ish.
2. You could take advantage of DMA to write data from the FPGA to the host in a buffered fasion. This allows transfer of data from FPGA to host very fast for logging purposes. This is an advanced technique that would require serious development skills in RT and FPGA, as well as a new NI VeriStand custom device to read the FPGA DMA and log to disk.

[jamesy]

Hi Stephen,

Given your last comments I guess my new target loop rate is 2khz. It if can run and log at 2 khz with no missed packets or delays then i can perform basic testing.

I stripped out everything from the VI that i could. 2khz still shows ES incrementing. 

I can run at 1khz and get ES count ==0 , however the "missed packets" indicator still ramps up when im logging.

I have to run at 500hz in order to stop the "missed packets".  Why are packets missed? Are ES count and missed packets linked?

Are there some BIOS settings on the real time target that need to be congured for optimal PXI chassis to Veristand real time target comms ?

Would using a higher spec real time target PC help? ie 64 bit with faster processor?

How long before you can make the performance mods?

Will reducing the number of signals im logging in the embedded data logger improve the " missed packets" and ES loop count?

Note: I've no plant model here yet. Will the delays and logging issues get worse when i add one?

James.

[StephenB]

Hi James,

I stripped out everything from the VI that i could.

What do you mean? I was talking about reducing the number of channels under the Engine Simulation custom device in the system definition inside NI VeriStand. What VI are you referring to?

the "missed packets" indicator still ramps up when im logging.

I have to run at 500hz in order to stop the "missed packets".  Why are packets missed?

I assume you mean the missed packets of the embedded data logger? This can be due to the FIFO inside the embedded data logger overflowing. You can possibly work around this by increasing the FIFO depth on the configuration page of the embedded data logger custom device. However, since the embedded data logger uses target CPU and that is a premium... I suggest using the host side data logging APIs instead of the embedded data logger. NI VeriStand doesn't (yet) have a GUI for these host side data logging APIs, so you can get started using them by running the LabVIEW examples. There is much better API in 2012, so I will give you two paths.

For 2011:

"C:\Program Files (x86)\National Instruments\LabVIEW 2011\examples\NI Veristand\API\Execution API\Data Logging\Data Logging.vi"

For 2012:

"C:\Program Files (x86)\National Instruments\LabVIEW 2012\examples\NI Veristand\API\Execution API\Data Logging\NI_VS Data Logging Examples.lvlib"

Try that out instead. (Unless of course you must log on-target)

Are ES count and missed packets linked?

Maybe, the CPU of the target is likely running out of time to complete all the tasks.

Are there some BIOS settings on the real time target that need to be congured for optimal PXI chassis to Veristand real time target comms ?

Yes there is a wealth of settings you can change to increase real time performance of NI VeriStand. I have attached a document to assist.

Would using a higher spec real time target PC help?

Faster is always better. What hardware are you using?

How long before you can make the performance mods?

Several months

[jamesy]

Hi stephen: In reference to above.

I altered my AES HIL custom device VI and removed some signals from the Main VI and the sub VIs. Such as "time duration" etc.

Would just removing some signals from the system explorer have the same effect? I did notice an improvement but not enough.

Do i import these "host side data logging APIs" into veristand? I'll dig around for documentation. Eventually ill be using the ASAM HIL API for logging and not the embedded data logger.

I'll see how that performs when I've it up and running.

I'll play around with the BIOS settings you suggest and see if that helps.

I'm using a desktop PC with some not so glamourous specs: 4GB, dual core, 2.3ghz. I want to get some advice from NI on specing a new machine to run RTOS pharlap/veristand. Can you comment or will i go through the existing helpdesk i raised for this issue?

thanks,

James.

[StephenB]

Hello,

I altered my AES HIL custom device VI and removed some signals from the Main VI and the sub VIs. Such as "time duration" etc.

Would just removing some signals from the system explorer have the same effect? I did notice an improvement but not enough.

Yes. There is no reason to modify your VI. You can just update system explorer to not read those values. Actuallly.... now that I think about it.... removing those indicators completely will further increase performance a little bit more. So... I would keep it as is.

Do i import these "host side data logging APIs" into veristand? I'll dig around for documentation. Eventually ill be using the ASAM HIL API for logging and not the embedded data logger.

I'll see how that performs when I've it up and running.

NI VeriStand is a configuration based tool that exposes APIs for automation in other tools like LabVIEW, Python and TestStand. You must invoke the "host side data logging APIs" with another tool like LabVIEW, Python, or TestStand to use them. I gave you paths to the host side data logging examples in LabVIEW for you to try out. This is actually what the ASAM HIL API does for its logging.

I'm using a desktop PC with some not so glamourous specs: 4GB, dual core, 2.3ghz. I want to get some advice from NI on specing a new machine to run RTOS pharlap/veristand. Can you comment or will i go through the existing helpdesk i raised for this issue?

The faster the better. You can upgrade your existing PC or buy something new. The fastest we have is the PXIe-8135

[jamesy]

My chassis is a NI-1036dc ,with a NI PXI-8360 MXI express card. Would the fact I'm not using an "express" chassis make any difference?

James