Jump to content

cj.surr

Members
  • Posts

    71
  • Joined

  • Last visited

  • Days Won

    3

Posts posted by cj.surr

  1.  

    On 5/2/2019 at 4:17 AM, tarlo said:

    I would love in the future if you could step up virtual logic to be programmable perhaps in function block or text with Boolean (and and or if etc) to allow lots of flexability to the end user. the virtuals are great but can be limiting.  Thanks 

    +1 

    If not in virtual logic, it would be nice to at least have functions available for log viewing and dash gauges. For example, I would like to be able to log/gauge AFR error (afr - afr_target) or water injection flow ({water pressure - map} * coef}).

  2. As far as I can tell, this is not possible with the G4+. It would be nice if there were a few options for smoothing sensitivity on analog input signals to suppress noise and spikes. For example, my water injection pressure sensors that are being driven by a 20hz solenoid, I can see every time the solenoid opens (150 kpa spikes - see image). Another sensor I am planning on adding is exhaust manifold pressure, and I am anticipating I will have the same problem. 

    image.thumb.png.e5d536134d8f61b06ab120ce2b2430a5.png

    Thanks

  3. On 6/28/2019 at 8:21 PM, Stevieturbo said:

    I never stated to try and delay the main rev limiter.

     

    I said you can delay the onset of the generic gp rev limits.

    I was referring to using the main RPM limit as a safety for additional parameters, as was suggested below. 

    On 5/20/2018 at 5:25 AM, Adamw said:

    Note you can also make your main RPM limit table 3D to add extra parameters.  Fuel pressure protection for instance if you use Differential pressure it should be relatively constant under all conditions so you dont need a full 3D table - you could just put it on one axis of the RPM limit table. 

     

  4. On 7/7/2019 at 5:50 AM, Adamw said:

    I dont know what you are up to here, you said earlier your engine doesnt have infinitely variable VANOS, just the on/off "two state VANOS".  You dont need to mess around with any of the VVT stuff, this is just what we call a switched cam.   VVT should be set to off and the aux output should be set to "CAM - Switched".  The generic missing tooth + Cam pulse 1X or Cam level sync is all you need for the trigger.  You cannot control the camshaft in any other way than on/off, fully advanced/fully retarded.

    Ok, that's what I was thinking originally... So I still have the question - why does using "cam level" cause an erratic engine rpm reading, when "cam pulse 1x" seems to work fine (but shows errors)?

    Thanks

  5. On 7/4/2019 at 8:28 AM, cj said:

    This is probably why your trigger 1 offset is different. Looks like BMW moved the missing teeth 240* relative to TDC at some point. This in itself isnt a major problem as the rest of the trigger pattern will still work fine with the offset changed. Yours is technically 240* different, plus another 360* to get the intake/exhaust on the right strokes. As long as the value you have a) gives you a solid reading on the timing light, and b) is on the right 360* cycle to fire up then your trigger1 offset is fine. Note that if you change this from multitooth to a predefined s52/m52 trigger mode, you need to re-check you timing with a light and the offset may change (because the "zero" position may be different on the OEM mode). You can change trigger type from VR to hall without "breaking" the trigger mode. I think your best bet is to set it to the S52/M52 mode then adjust timing etc until it fires up (try add/remove 360 if the timing light is good but it wont fire at all).

    http://m54megasquirt3.blogspot.com/2011/09/timing-settings.html

    Thanks, I wasn't aware of that difference. I will try the S52 and M52 settings. I am not sure how this would be any different than a generic 60-2 and cam level sensor though? 

    On 7/4/2019 at 8:28 AM, cj said:

    Did you copy the trigger2 offset from the help file or check it yourself with a vvt cam test? if you have just used the help file, it may be wrong for your engine. Have the engine idling, then go to VVT -> Setup, and change "cam pulses" to 1 (or try 2 if the numbers jump around when set to S52 trigger mode). You may also need to set VVT mode to single vanos - i've never tried running cam test with vvt set to off now that I think about it. Now press F12 and go to the VVT tab, Cam angle #1 (and maybe 2) should show stable numbers. The lowest stable number (or the only one), is what you should set you trigger 2 vvt offset to be. Your scopes look ok so i'm now thinking either this offset being wrong or not using the OEM trigger mode is causing that inlet trigger error. You need this offset to be correct so that when VANOS advances, the ECU has a reference point of "normal" and can then tell how far advanced the cam is.

    I don't understand what the "cam pulses" means. I believe I turned cam test on, then disabled the vvt control and I was able to get a solid reading of 290deg so that's what I set the trigger offset to. But, like I said, this was with "cam pulse 1x" in trigger 2 settings, because "cam level" caused erratic engine rpm. So like Adam said, I think this is why I was getting the cam error.

    So Aux 3 that my cam is on should be set to "vvt cam solenoid" instead of "cam-switched" if I am using VVT control, correct?

    On 7/4/2019 at 8:28 AM, cj said:

    A circuit diagram of how that VANOS solenoid works would be the best place to start figuring out how to wire + control it. I've found some docs that line up with what you've said about it being on/off, but it looks to me like that might be just because of the slower computer that was installed from factory. The system itself looks to function like a hydraulic variable VVT system with no locking pins etc, and so the link may be able to drive it as such. If you are happy with all or nothing advance, and the wiring doesnt need to be "special" then yep just an on/off switch is fine.

    Yeah, it works fine with the Link (I've tested it), it's just a basic solenoid valve. I would bet that it could be driven with pwm for variable control, but I wonder if the lifetime of the valve would be compromised from the rapid open/close.

     

    Thanks

    CJ

  6. On 7/2/2019 at 2:40 AM, cj said:

    Did you re-check the trigger 2 offset when changing from rising to falling edge? I believe cam-level is just looking for high/lo voltage, but on cam pulse it will be looking for the edges of the transition from hi/lo and so rising & falling numbers will be 360* apart on a cam like this, also if either edge is really close to the missing teeth then you can see errors if it moves about slightly. The LH Inlet cam is reporting an error state of "extra pulses" for that entire log. Trigger scope at idle would really help as it sounds like some additional edges are being seen by the ECU. At idle, the error counter is increasing by about 1 count per 5 rpm, so you may need to run a few captures and look for change between them or something that only occasionally pops up. 

    Trigger 2 has always been set to rising edge. I took the cam angle from "Intake/LH" parameter and put it into the offset in the "Trigger 2 VVT" menu. I am not really sure what the purpose of that angle setting is. I recorded a handful of trigger logs (attached). I can't figure out how to view them without being connected to the ecu to open the trigger logger. They looked OK at quick glance when I was recording them. I also have the datalog from when I took the trigger logs.

    On 7/2/2019 at 2:40 AM, cj said:

    Is there a reason you are not using the S52 trigger pattern? It sounds like this might be 60-2 + cam level under the hood anyway, but there might be something else special in it. I assume trigger 2 is on your intake cam and not the exhaust?

    I tried the S52 trigger pattern with the same crank angle offset and it wouldn't start. There were some weird settings preloaded with it that I changed to my current settings and it didn't help. By default it had the 1/2 triggers as reluctor/reluctor (stock is hall/optical). Also the crank angle offset was 275 vs the -325 that I found. I don't know why these would be different, my 60-2 wheel is the same that is on all of this style engine. 

    On 7/2/2019 at 2:40 AM, cj said:

    I thought these engines were VVT/phased cams - the older ones intake only and the newer ones on both cams, but your config has it setup like a switched cam (eg vtec). If i'm right, then you would have your cam advance solenoid full open (subject to oil pressure) whenever that AUX3 output is triggered - but it will never trigger with the current config because the criteria is <4500rpm & >7500rpm - it cant ever be *both* these criteria at the same time 

    There is only cam phasing on the intake cam for the S52B32. It is controlled with a simple ON/OFF from the ECU. The cam phasing was not continuously adjustable until the next generation dual Vanos M54 and M52TU. 

    I have those settings because I want to tune without VVT first, then add a 4D map to trim fuel based on cam angle because the Vanos is slow to react and makes a big difference in VE.

    On 7/2/2019 at 2:40 AM, cj said:

    I suspect it also doesnt help having incomplete VVT setup. You have it kind of disabled by not configuring it, but your log still shows 1-2* of VVT advance happening at anything about ~3k rpm. I cant tell if this is actual cam advance due to oil pressure or just slop in the cam belt/chain. At least set VVT up so the ECU knows to expect it, then set the target table to all 0 if you want it disabled to start with. (switch aux 3 to VVT solenoid & vvt control type to single Vanos, cam angle test = off, test pulse = 1)

    1-2deg is not signficant in my mind, I'm sure that's just from slop in the helical gearing of the Vanos. It will advance over 20 degrees, IIRC. 

    Should a simple ON/OFF VVT be configured in the VVT settings at all, or just in the aux output?

    On 7/2/2019 at 5:27 AM, Adamw said:

    This is not an engine I know well, but if the cam has the "half moon" type wheel and it has the "infinitely variable VANOS" then you need to use the BMW M52 trigger mode (and also the M52 VVT mode). To improve the resolution of the "single cam tooth", these modes instead uses both the rising and falling edges to effectively give the ECU two teeth per cam rev.

     I was kind of confused by that part. Obviously there should never be a square wave going to the solenoid. 

    On 7/2/2019 at 5:27 AM, Adamw said:

    This is not an engine I know well, but if the cam has the "half moon" type wheel and it has the "infinitely variable VANOS" then you need to use the BMW M52 trigger mode (and also the M52 VVT mode). To improve the resolution of the "single cam tooth", these modes instead uses both the rising and falling edges to effectively give the ECU two teeth per cam rev.

    The S52B32 is indeed half moon, but not infinitely variable, and only one cam has VVT. The M52TU is in fact infinitely variable, but that's also a dual VVT motor. So which setting should I be using? Like I said, chosing "cam level" causes an erratic RPM signal. 

    Log 2019-07-3 12;25;54 pm trigger test.llg Trigger Scope Log 2019-07-3 12;24;46 pm.llg Trigger Scope Log 2019-07-3 12;25;00 pm.llg Trigger Scope Log 2019-07-3 12;25;08 pm.llg Trigger Scope Log 2019-07-3 12;25;15 pm.llg Trigger Scope Log 2019-07-3 12;25;20 pm.llg Trigger Scope Log 2019-07-3 12;25;31 pm.llg Trigger Scope Log 2019-07-3 12;25;42 pm.llg

  7. The engine is a BMW S52B32 US. I am using  an M54 camshaft sensor because the stock one is not a standard vr/hall. It seems to be working well - trigger logger shows what I believe is a "cam level" style - high for one rotation, then low for next rotation. Cam angle #1 shows the proper angle and I have that offset in the "trigger 2 VVT" menu. However, if I set trigger2 to be "cam level", i get a lot of noise on the rpm signal (~100rpm jumps several times per second). Filtering did not help much. When I set trigger 2 mode to "1x cam pulse" my rpm signal is perfect and cam angle still shows the correct value. The "inlet/lh cam error counter" does increase about +1 per second with either mode. It seems like everything else is working fine, I'd just like a way to confirm that the engine is actually firing the injectors sequentially before I spend the time tuning the fuel map.

    Also, I don't think it's related, but I had to set my trigger 1 to "falling edge", even though it goes high when there is a missing tooth. If I use "rising edge" I get occasional blips to sky high rpm randomly. The timing was checked and adjusted. I had to change the ignition delay down to 60 us (e36 base map was 115! - caused at least a few degrees of retard) to get the timing to be consistent to redline.

    I attached my tune and a driving log with those settings 

     

    Thanks!

     

    E28.pclr Log 2019-06-28 11;55;02 pm.llg

  8. Have you checked that all ignition outputs are wired to the correct coils? In other words, doing an ignition test on coil 3 actually fires coil 3 and not another coil. If this is wasted spark, then my comment doesn't apply...

  9. 13 hours ago, Stevieturbo said:

    You can set a time delay before it activates.

     

    It would seem sensible in the engine protection section....to actually have basic engine protection features though.

    I don't think you can set a delay on the main RPM limit. And even if you could, you wouldn't want that. That's your main RPM limiter. 

     

    +1 to improvements in the engine protection side. At least a couple extra GP tables would help a lot. I'd rather see tables with the Z axis being your protected variable; with engine protection coming in if that variable is exceeded, with a delay for engagement and disengagement. Doing that would allow for user defined variables on the x, y and z. But I realize that it would be a lot of work to go away from RPM limiter method. 

    Also, I am missing the AFR Error (Actual - Target) parameter that I am used to on other ECUs.

  10. On 5/20/2018 at 5:25 AM, Adamw said:

    Note you can also make your main RPM limit table 3D to add extra parameters.  Fuel pressure protection for instance if you use Differential pressure it should be relatively constant under all conditions so you dont need a full 3D table - you could just put it on one axis of the RPM limit table. 

    Wouldn't there be an issue with using the main RPM limit with an input such as fuel pressure? I could see that a small, momentary dip in fuel pressure would cause the limiter to be activated. And when the fuel pressure returns, the limiter would be very quickly deactivated. In other words, you would want a delay for entry and deactivation of a limiter based on any analog input. I haven't tried this, but I would like to, which is why I am curious. I see that using a GP limit allows for a delay and "Exit Decay Rate" that could work those out. 

  11. I am trying to drive a PWM water injection solenoid that draws about 4.75A max. It would be rare for this output to see more than 50% DC. Aux outputs are only rated for 2A, Injector outputs are rated for 5A but I am not seeing the option to use them as a general purpose PWM. Is there any possible way to do this? I'd rather not set up an external transistor. 

     

    Thanks

  12. I'm seeing now why that limit is there... 500hz max frequency. 

    Is there an internal fuse for the +5v supply? I just got my unit in and I don't like how the +5v wire is split to go to different sensors right near the ECU connector. Unless there is an internal fuse, then that would be alright. 

     

     

  13. Also a comment... I am configuring a turbo speed sensor for a Borg warner EFR. 

     

    Per the manual - 

    image.png.c9914365640732dcc0567df8c44ad56a.png

     

    The divider for the EFR sensor is 8 

    That gives me 6000 * 14 Teeth / 8 = 10,500

    PCLink is telling me the max value is 10,000. The limit close enough for my sensor, but doesn't make a lot of sense.

  14. I have been reading that Virtual Aux can be stacked to gain additional conditions. I am planning to have multiple levels of engine safety and I believe I will need to stack multiple Virtual Aux. However, when I am going through the available switch conditions, I only see Virtual Aux 1 as an option. I believe I will need at least one more Virtual Aux to be selectable as a switch condition. Am I missing something here or is only the first Virtual Aux meant to be stacked? 

     

    image.thumb.png.ba88ec9db50ad16256f16ba96fa4bb93.png

    Thanks

    CJ

×
×
  • Create New...