Adamw

There is a "user lockout" setting for LTFT coming in the next release, so you could use a GP output to set whatever conditions you like for disabling it.  This lockout will disable both the learning functionality and the trim.

There is a "user lockout" setting for LTFT coming in the next release, so you could use a GP output to set whatever conditions you like for disabling it.  This lockout will disable both the learning functionality and the trim.

Yeah this is what I call "daisy chaining" and is actually preferred as the stub length is then zero.  Just not too many good connectors allow you to squeeze 2 wires into the one terminal and the environmental seal is compromised so not the best option in all scenarios.  I typically use 24AWG when I want to go that way. 

Yes, set a virtual aux to "engine fan 1", Change aux 2 function to a GP output, the GP output is then set up to activate when the virtual aux is on or the DI is on.  

Unfortunately no, although PC Link is basically unchanged at this point, the processor and much other hardware is too different for the G4x firmware to ever be cross compatible. 

The throttle oscillation isnt from cruise, it looks mostly to be just poor E-throttle PID tuning.  I would start by putting the E-throttle integral gain back to our base map setting of 0.07, you may even be able to go back as far as 0.05, I have never seen any throttle want as much as the 0.20 that you have it set to now so I suspect that is the main issue.  
The cruise PID looks like it needs a bit of tuning also, it is not really causing any issue in that log but you can see it is making the throttle target quite noisy which will make it use more fuel than normal as accel fuel will be working much more than normal.  Drop the cruise control Integral gain down to 0.02 and the derivative down to 1.0 should tidy it up a bit.   
 
 

If I understand what you want correctly, you dont need a math block.  You can scale the DC directly to -4095 to 4095 with the CAN multi/div/offset. 



 

So do you want 0 output between 49.1-50.9%?  or only 0 output between 49.9 & 50.1%?

At present no.  Im pretty sure there is a user lockout for LTFT coming in the next firmware release.  

At present no.  Im pretty sure there is a user lockout for LTFT coming in the next firmware release.  

I dont see any problems in any of those scope captures, they all look good an trigger 1 state shows the ecu has synced.  
Do you still have starting issues?  If so, can you try to get another log of a start attempt where it does not fire.

You will need to set up a custom CAN message to send EGT to the dash.  I can do that for you if you like.
Attach a copy of your ecu map and dash config file.

You will typically see small/short spikes of error accumulator during heavy foot work - maybe up to about 15, maybe 20 worst case and it should recover to zero within a 10th of a sec or so.  
Log I just pulled from my car below, the worst TP error spikes reach a count of 6.  You can see E-throttle target, TPS sub and TPS main barely deviate from each other at all, you cant even see the green or yellow TPS traces...
  

You will typically see small/short spikes of error accumulator during heavy foot work - maybe up to about 15, maybe 20 worst case and it should recover to zero within a 10th of a sec or so.  
Log I just pulled from my car below, the worst TP error spikes reach a count of 6.  You can see E-throttle target, TPS sub and TPS main barely deviate from each other at all, you cant even see the green or yellow TPS traces...
  

You're going to have to give us some more info then.
How is the module powered?
How are the CAN wires connected to the ECU?
Share a copy of your .pclx configuration as it is currently.
 
They're very simple devices, that only require 4 wires connecting, and a pretty simple configuration if you follow the well-written instructions. There's got to be something obvious that's being missed somewhere.

Typically you would use CAN if you needed multiple EGT's, so you dont use all of the analog inputs.  If you only need 1 EGT then analog is probably better value.

Yes, something like this example:

It is good practice to have both ends of a CAN bus terminated, but we have tested the Link CAN lambda seems to still communicate reliably with only the internal ecu terminating resistor, we havent tested the Haltech one.  
Set up instructions are in the help file under CAN>Device Specific CAN Information

That will be a Storm based plug-in ECU.  It has AN Volt 1-6 and AN Temp 1-3, and DI 1-6.
The IAT sensor can connect to AN Temp 2 (main header pin 36) or AN Temp 3 on the expansion connector.  
Fuel press and wideband can connect to any spare AN Volt inputs.  There is AN Volt 2 on the expansion connecter, or AN Volt 4/5/6 on the main header that probably arent being used (these were originally connected to the airflow meters and narrowband oxy probe).  
A flex fuel sensor can be connected to any spare DI, there is DI 5 &6 on the Expansion.  Note G4 doesnt have true flex fuel capability, cold start and some other fundamentals will be bit of a compromise with flex fuel using this ecu

You dont need traditional, modelled will work exactly the same.  Modelled makes more sense for blended fuels.
 
Really you dont even need RPM as a general comment, load is the main factor that needs to be referenced.  However, RPM can be useful for situations such as a modified engine that doesnt like to idle at lambda 1.0 but will cruise happily at that.  Or when you have something very knock limited you can use a richer target right around the peak torque RPM to reduce knock risk, then lean it off once past peak torque so you arent giving away too much power from being excessively rich.  
 
Read the flex fuel set up and tuning guide in the help file.  If you are using modelled mode then your fuel table represents VE (air flow), so in theory it shouldn't change when you change fuel.  In reality however it sometimes does change a little due to egt differences and scavenging effects etc.  I have only done a few full flex tunes as E85 is only available as an expensive race fuel here now but I found provided you have good injector data you usually dont need a 2nd fuel table enabled.  For ignition tables yes, you would typically set up 2 tables that are blended between, one is tuned on straight petrol the other on straight ethanol or at least the highest concentration you will run.  With ignition however the blend isn't linear like it is with most fuel related stuff, so you need to check it at a few concentrations in between the extremes.  For example you will have a big difference in Ign timing going from E0 to E50, but from E50 to E100 there will be little difference.
Multi fuel blend is generally the better option as then 0-100% matches your min and max ethanol content.  So for example if you tuned the first table with E0 and the second table with E80, then you want to be using 100% table 2 when you are running on E80.  If you had ethanol content on the axis then when you had E80 in the tank you would be pulling numbers only 80% of the way between table 2 and table 1.  

In traditional equation the open loop lambda multiplier is optional, in modelled mode open loop is always in effect.  CLL is not relevant, it uses the same table as a target, but it has no effect on the open loop lambda multiplier in the background.  
A rough example of what the open loop multiplier does; 
Lets say your lambda target was 1.00 and you had tuned the fuel table so that the measured lambda was sitting bang on target at 1.00, and lets say at a particular operation condition the injector PW to achieve this correct lambda was 10.0ms.  Now say you change the target to 1.05 (5% leaner), with open loop on, the ecu knows that the new target requires 5% less fuel to achieve so it reduces the injector PW to 9.5ms.  The measured lambda should follow the target with no other user adjustment.  In contrast if open loop was off and you changed the target by the same amount, the inj PW wouldnt change at all as the target is no longer part of the fuel calculation, you would have to manually go to the correct cell in the fuel table and reduce that by 5% to get the measured lambda to match the new target.
 
 

I dont even know what a M50NV is, but from a quick google image search of the cam sensor (12141726548) it looks very much like it is a reluctor since it has something that looks like the pole piece poking out the tip.  Whereas the M50TU has a hall effect sensor so wiring and trigger setup in the software will be different, trigger offset may be different also as the M50TU uses a level sync type cam wheel which would not be possible in your engine if it has a reluctor sensor.  There is also a 3rd possibility - the e36's with the siemens ecu had a weird active cam sensor.  So, first step is to confirm what type of sensor you have, Measuring resistance accross pins will possibly give some clues - a reluctotor will usually have a resistance of less than 1500ohm between 2 pins, a hall will be kiloohms or megaohms.
Setting sync mode to none means the ecu wont know if it is on TDC compression stroke or TDC exhaust stroke so will have to guess, that means it will only be sparking on the correct stroke approx 50% of start attempts.   

Export/import the dwell table from our 350Z base map.

On the M3.1 non vanos ecu, pin 16 is the cam sensor ground and pin 44 is the cam sensor signal.  There is only one cam sensor.
On the Vanos ECU, connect the cam sensor ground wire to any sensor ground - pin 43,44, 45 or 71 would do.  Connect the cam sensor signal wire to pin 17.