MoTeC Global Forum

maybe not possible to do but would really be helpful to be able to simulate the build using software to make sure it has the expected behavior. Right now I can do it by sending the build to tune and loading it into an ECU on the simulator which ultimately you would want to do anyway but I was thinking it could be very beneficial if it could be simulated ahead of time or if you wanted to build a package for an ECU you didn't happen to have in stock. Maybe once you have a good proficiency with Build - this would not be needed as much but seems like a good idea now.

No Problem, been sitting tight for a long while now. Thanks for the response.

PS, you think the ideas are good in the lunchroom, try the bar

I made a similar suggestion to Motec UK a while back. It would be great if the software could also simulate processor utilization so that you know if you could run into trouble with the number of tables and calculations you are running.

Having formerly done simulation work...
It is my opinion that it is generally best in the context of this example to have the simulator be separate from the MoTeC S/W.

For example, one probably does not want to simulate the behaviour in the S/W, but make an engine simulator, which outputs the TP+Baro or MAP or MAF, Crank and Cam signals, IAT (and maybe lambda, H2O temp, Oil pressure, etc) and then run those signals into the actual ECU.

Then pull out the observed behaviour either in-situ, or from the log file.

Having the simulator doing Alpha-N would be a lot easier than also having to look at the injector p/w and doing some lambda maths, but it would not be too difficult... But there are a lot of detail like delay times in lambda, that need to modeled.
Other than the S/W time, there is also expense in an DAC/ADC to output the signals for the engine, and ingest the ECU outputs if doing closed loop work.

I have read through a number of the forum entries. There has been some discussion about simulators. One thing I have seen in other control systems software is the ability to step through the software and see how the code changes values (input and outputs) line by line. This is very useful when you can move quickly between the development side and the active side of the software (Build to Tune and back) to make minor corrections in the code quickly. I see this as very important given the rising costs of software development and tuning costs. With this new software, the link between software and hardware can be decoupled opening up a lot of options. Developers will be developing software for ECU they may not have ready access too. It may be impractical to obtain access to an ECU during software development. With this software you will be able to develop code for any M1 ECU at any time.

The biggest change I see coming as an end user is; We now have the option of choosing one organization to do software development and another to do tuning. In the past, these activities have been tied together. A real good tuning organization a software developer does not make.

Agree with Shane, that could be a strong tools, will save time and maximize Build project development even because right now something like that it is available with a competitor.
Regards
Andrea

TunedByShaneT wrote:maybe not possible to do but would really be helpful to be able to simulate the build using software to make sure it has the expected behavior. Right now I can do it by sending the build to tune and loading it into an ECU on the simulator which ultimately you would want to do anyway but I was thinking it could be very beneficial if it could be simulated ahead of time or if you wanted to build a package for an ECU you didn't happen to have in stock. Maybe once you have a good proficiency with Build - this would not be needed as much but seems like a good idea now.