_       
( (    /|
|  \  ( |
|   \ | |
| (\ \) |
| | \   |
| )  \  |
|/    )_)
         

         
         
  #####  
 ##      
  #####  
      ## 
 ######  
         

   ___  
  / _ \ 
 | | | |
 | |_| |
  \___/ 
        

  _____
 |__  /
   / / 
  / /_ 
 /____|
       

         
### ###  
 ##  ##  
 ##  ##  
 ##  ##  
 ##  ##  
  ### ## 
         

IMPORTANT: enter the case-INsensitive alphabetic (no numbers) code AND WRITE SOME SHORT summary of changes (below) if you are saving changes. (not required for previewing changes). Wiki-spamming is not tolerated, will be removed, so it does NOT even show up in history. Spammers go away now.


Visit Preferences to set your user name
Summary of change:
Eventually VEMS will release new and more advanced hardware, hardware I think the current VEMSTune implementation wouldn´t be able to handle properly. See linked PDF for my notes on organizing complex ECUs into more easily manageable user experience and user interface. http://www.vems.hu/files/VemsTune/VEMS%20Advanced.pdf I don´t think everything in that document needs to be exactly as it is there, but by following similar construct a more advanced VEMS can make itself more user friendly and more easily supported. If you want any information on anything in Pectel ECUs let me know. I can provide screenshots of anything requested. ------ Consideratiosn about input and outputs for future VEMS I think for maximum versatility and future proofing the base of the VEMS ECU should be so that each input or output selectable should be detached from a physical input pin, this allows for instance CAN channels(or other protocols) to act as analog/digital inputs, as would outputs be (apart from ignition outputs). This could be described as base software and application software layers in where the application software layer only deals in the mathematics and logics while the base software only deals in converting physical pin values and stream protocol values into engineering values to be put into the two layers interface. Example Fuel injection pulswewidth direct to pin *'''AppSw''' : **Cylinder in question = 1 **VE calculations = 105 **Required injector constant = 6ms@100kpa **Total pulsewidth after all considerations = 105/100 * 6 = 6.3 Application software sends the value to the base software as Cyl1_Pw additionally the injection angle is also sent seperately as Cyl1_Angle *'''BaseSw''' : **Inputs are Cyl1_Pw = 6.3ms **Cyl_Angle = 360° Other inputs are **Cyl 1 Injector = Pin 8 BaseSw takes care of WHEN to start pulling the injector circuit down and when to stop given that it knows the crank angle etc. '''Boost control 2 methods''' '''Method 1 & 2''' * App_Sw : ** Duty cycle calculated as 40% ** Boost_Pct >> Base Sw '''Method 1''' Base Sw : Boost output is set as a physical pin, BaseSw calculates timing and actions the pin accordingly '''Method 2''' Base Sw : Boost output is set as CAN out - CAN Id = 0x45, 16Bit size, Byte 0-1, gain 0.01%/bit , offset = 0 Can message byte 0-1 is sent as 4000 >> 0000 1111 1010 0000 Whoever is the receiver will handle the rest from there. '''Inputs''' In the App Sw the Air temp is just a engineering value and so the software is written entirely on engineering values and boolean logic The App Sw wouldn´t need to care where the value comes from. Base software acts as the source of all the analog channels to the app software. * Analog input ** Physical pin on this device * CAN-BUS input value, local ADC curve applies ** Physical pin on some other device where analog >> engineering values is done * CAN-BUS input voltage ** Physical pin on some other device where analog >> engineering value is not done , local ADC curve applies * Serial protocol input value ** Physical pin on some other device where analog >> engineering values is done * Serial protocol input voltage ** Physical pin on some other device where analog >> engineering value is not done , local ADC curve applies * Virtual mathematical channel from AppSw ** In this case the value can be AppSw modelled based on other available App Sw values, value goes back out of the App Sw and comes in as a pre-defined engineering value, for instance if absolute fuel pressure is known and manifold pressure is known, then gauge fuel pressure across the injectors can be calculated(for inj pw adjustments) and returned as a engineering value (this engineering value could have come from anywhere though, not just from inside the ECU, so could have been an analog pin etc) I believe this methododoloy also allows faster updates to control strategies in the App Sw as the interface between the AppSw and BaseSw is already in place and might not need updating everytime there is an App Sw update. This also allows a big interface to be constructed between the two before some channels are even being used like, i.e. fuel injector gauge pressure doesn´t need to be used, but the "fuel injector gauge SENSOR" is constructed from the start and will therefor always be available.
Optional: Add document to category:
Wiki formatting: * is Bullet list ** Bullet list subentry ... '''Bold''', ---- is horizontal ruler, <code> preformatted text... </code> See wiki editing HELP for tables and other formatting tips and tricks.