Quote:
Originally Posted by adrian@vishnu
My description above was basic, but Procede did the same thing. Target the boost at slightly below the actual boost target to prevent a spike that could cause throttle closure.
Yes Procede also did the same things to isolate the closed and open loop components of the DME control output and apply scalings to the open loop to get steady state duty cycle into the correct range for the increased boost, and to the closed loop component to alter the gain. We went a fair way down that track in the last 6 months of V3. In the end we discovered that it was taking more effort to dissect the individual closed loop components than it would take to get a more effective standalone control system and went that way. Basically, although we could control the total control loop gain as I am sure JB3 is now, we could not accurately control the PID components that we need to get response where we wanted. I wish there was a way that JB3 could datalog boost and throttle at high rate to compare the response. V4 is ALOT quicker than our most advanced V3 (and I have yet to see anything suggested JB3 2.0 has exceeded V3) to get to target with almost no overboost and stabalise instantly than the modified DME setup was.
In your opinion the factory system is quicker/safer than any external controller, but what is this opinion based upon... How many external boost controllers have you tried? This statement you make is at best false since you have NO idea how well an independant controller could work. You are just sticking to your mantra that since BMW did it, it must be best... even though BMW had different goals to you or I. Put you money where your mouth is and lets compare them.
Time will tell if this way you are doing is smarter/better. I have my opinions on what time will show. Are you able to increase the details and resolution of you datalogging, as that would show alot.
The thing you have to realise here is that the Procede still has access to the input DME target (which you model), and the output duty cycle. With late versions of V3 we tried doing what you are doing and it worked to some extent, but we got frustrated at not being able to control the PID components accurately, so decided to replace the controller itself. It is actually very simple the PID that we run... far simpler than trying to modify the DME setup before. It takes about 3 lines of code and a few bytes of RAM to do a full PID controller. The thing is that you make assumption that our method would not be as safe... but you know we have access to the DME targets and alter our targets based in them... how safe can it get... If the DME targets go low for a safety reason... we see it instantly. You say that you can modify the DME PID to make it the fastest system available, but you can really only alter the overall closed loop gain and not the individual components like we can as we are doing the PID. We can now run alot of differential to control spikes.... can you alter the DME differential gain seperately?
Anyway, I think I understand your system quite well, and I think you probably have a good idea of ours. The questions is... what is the reason we do not run the same system. Is it because your system us better and we are just trying to use marketting hype of this new system... or is it because ours is better, and you do not have the resources to replicate it, so you are trying your best to take away from what is a superior system. How about we have a shootout to find out?
Adrian
|
I think that the reason you recently chose stand alone is spelled out in your posts. You found it took less effort to work with a stand alone controller than tuning the factory PID. Some speculation on my part here but perhaps your firmware and implementation contained logic that made tuning the factory PID more cumbersome than it needed to be. From BMS perspective they have not found tuning the factory PID to be a burden and see many benefits to sticking with it. Again this is just my opinion but if you truly felt stand alone was the best approach why didn’t you start with it from the beginning? Only after working with and not achieving the proper results with the factory system did stand alone suddenly become the "superior" choice. As you pointed out a stand alone PID is technically simple to implement. So why did BMS choose to go integrated? I think we can agree that both ways work and just bring different views/approaches/philosophies to the table. Obviously both of us are way to bias to say which is better, but thats best left to the end users to judge for themselves.
It may be premature to get in to the technical safety differences but I will say in reading details I’ve come across several things that caused me to raise an eyebrow. We will have to see how it plays out and can have an open discussion on that when details are made publicly available and both system finish their beta runs.
On safety, I think to easy to dismiss BMW’s integrated system but like any OEM application it is designed specifically for durability and safety. BMW has to stand behind resulting warranty claims and with over 100,000 N54s on the road by my estimate has quite a bit of skin in the game. Much more so than say Vishnu or BMS. It would be great if you could explain how you guys choose to implement the safety nets that have been replaced by your new logic. I think how everything comes together, safety, ease of use, power, drivability makes a total criteria by which users will judge each.
I would also like to say that I am thankful we have had this discussion in a very professional and non belligerent manner, which is so refreshing and I look forward to our continued dialog as do many of the e90post readers I am sure.
Mike
