mapper

Yes updated pinouts will be in the next release of PCLink which I believe is not far away.

On a Link G4+ ECU no not yet. Luckily the cars we run Thunders in both have Motec dashes with SLM shift lights fitted so we flag a warning before there is a cut from a GP limit.
It does need some more work I agree but the guys are moving forward but they need a little kick sometimes to hep them long the way...
 

We have used the latest Ecumaster unit with very good results.
Honda Civic Drag car running Plug and Play Link ECU together with link canbus lambda and ECUmaster Can EGT.
Making some good numbers so far
 
 
IMG_0283.TRIM.MOV

Hi 
To speed up wiring and diagnostic I would like to have a function that outputs a list, a schematic, and a picture of the connectors with all labels of all configured (assigned) in- and outputs. On top of that many smart things could be implemented like an auto updated complete wiring schematic in an easy understandable format(e.g MS Visio style). These things can speed up install time and wiring a lot, which sets barrier lower to switch to a standalone ECU.  
possible examples attached. 

Was logged at 25Hz. Changed to 40Hz and it now looks as it should, thanks Mapper 

check at what rate the knock treshold is logged. Try at least 25hz or more. Think a slow longging rate could be your problem

Since a 12 injector ecu may never be a big enough mover to justify a new hardware platform, another option might be firmware/software based solution that allows 2 ecus to be linked together in a master/slave configuration.  2 x Storms linked together would be a relatively cost effective option for those that need 16cyl sequential?

Hi 
To speed up wiring and diagnostic I would like to have a function that outputs a list, a schematic, and a picture of the connectors with all labels of all configured (assigned) in- and outputs. On top of that many smart things could be implemented like an auto updated complete wiring schematic in an easy understandable format(e.g MS Visio style). These things can speed up install time and wiring a lot, which sets barrier lower to switch to a standalone ECU.  
possible examples attached. 

Cell size was a criterion many years ago to compare ECU's. The VE modell Does a great job. Sometimes you want to move brakepoints arround, but I never felt that there are too less cells in a real world application. You can spent days to tune every cell perfect on the dyno (which needs anyway much more time if you expand the number of cells) and on the track you will find that transient AFR can vary alot depending how boost kicks in. 
I personaly found that I get more stable transient lambda readings (or less lambda error) if I tune TPS vs RPM in the main table and use a 4D overlay with boost compensation (MGP vs RPM). 
That virtually makes your Map even bigger than what Haltech has! And it will make a great job even with 10bar of boost.

Hi agree that there is some space for improvements on Accel enrich. 
If you enrich enought that you don't see a lean spike at the begining of rappid TP change, AFR's goes usually to low. Even if you set decay rate to 100% and enrich only on one event. 
I can only explain that with fuel film which is built up during extra accel enrichment injection which is then sucked aways on the follow engine cycles, because flow goes up with RPM. 
Some kind of asynchron enrichment may help to built up a fuel film. Or a full fuel film modell. 

Hi agree that there is some space for improvements on Accel enrich. 
If you enrich enought that you don't see a lean spike at the begining of rappid TP change, AFR's goes usually to low. Even if you set decay rate to 100% and enrich only on one event. 
I can only explain that with fuel film which is built up during extra accel enrichment injection which is then sucked aways on the follow engine cycles, because flow goes up with RPM. 
Some kind of asynchron enrichment may help to built up a fuel film. Or a full fuel film modell. 

When full time closed loop lambda is used, the mixture map isn't useful, because lambda is controlled to target.
I would like to have an option to plot CL lambda correction im the mixture map. 

Hi Llewellyn
Development will continue on the G4+ for some time to come. But to keep improving in an electronic environment there will always be a point at which the platform has to be updated.
The G4+ range is coming up on 4 years old now and I expect us to continue with it for some time to come (years not months)
So don't panic the support is still there.
 

Hi Jared,
Unfortunately no real way to make both methods work together at this time.  Although without thinking about it too deeply you could possibly use the launch control function for "latched launch" only and then use a GP RPM limit table to give you some effect quite similar to the "single RPM launch mode".
As Simon says it is on the working list but so are a million other important features so I suspect it is still some time off yet.

Ok, I agree this is not elegant and you will still miss some features such as decay rate, but there are a few ways you can add some retard to your GP limit.  Depending on which ignition tables you have left you could possibly use the dual ign table (nicest option) or the 4 or 5d ign table, set the activation to either the same DI as activates the GP limit or use a virtual aux to activate it with some other conditions such as timers thrown in for extra complexity... 

Thats usuall. What I've seen, on most cars pressure drops by 0,25 bar at higher injector duty cycles. Even with new fuel pressure regulator and big fuel Pumps. 
If you setup modelled fuel, you can choise FP as a load source, so pressure is compensated by the fuel modell.

Hi Mapper,
This bug wouldnt affect the common multi-fuel setups.  It is only when the dual fuel table mode is set to "overlay table", in this case no matter what value is in the table, the pulsewidth drops to zero and stops the engine.  This mode is rarely used so we think it shouldnt effect too many users and for those that it does effect it will be very obvious.
For multi-fuel setups the dual fuel table mode is "interpolate between" and this works as expected.
We have this fixed in the next release but it is still a little way off at the moment.  

Hi Mapper,
i have done a lot of race boats etc with MoTeC sports dashes using ViPEC ECU'S when you purchase the dash the 2 options for the GPS are a 10 and a 15 Hz and believe me we get mega data with them and no time issues.
But point taken.
Regards
Dave.

How about adding something like I originally posted
RSS feed link to the download file location?
Or how about you always edit the same post that people can subscribe to?
Or how about you build a simple routine into the software to do a check when you open it?
 
Sorry for nagging but going to check is so last century, it is 2017!!
 

Tunning without a knock device is crazy. There not that expensive. If you post your map and a log file I'm sure someone will be able to help you. 
Remote tuning maybe another option.
 

Hi mapper,
One possible solution is to set the ECU logging up so that it is logging all the time. When the customer detects a fault they can turn off a switch, which turns off the ECU logging.
This won't suit every install, as putting a switch in is extra work, but could be good for customers trying to track down intermittent problems.
Scott

I'll see what I can get happening on this.
Scott.

Iecku, I just thought I would mention a little bit of info that many people miss.  These kits appear to use the Honeywell 1GT101 sensor, these sensors are much slower on the rising edge than the falling edge.  The datasheet quotes a 15µs rise time Vs 1µs for fall time.  So for at least trigger 1 (that controls the timing) it would be more correct to set the trigger edge to falling. Even though 15µs is only like 0.9 deg at 10000RPM, if you can get extra accuracy just by a simple setting change - then you might as well use it...

A picture will probably explain better:

This picture is not scaled well to what I normally see in real life but it still shows you the idea.  The green arrow is pointing to roughly where I would normally initiate the gear cut based on system using gear lever force.  The red arrow shows where I would have to initiate the cut if we where using barrel position.  You will notice the gear pos volts is a "flat line" in the preload area so we cant get the cut to trigger in the ideal location.
As for your "shift times" question, unfortunately there is probably not a typical answer - you will see huge differences between cars, vehicle weight, gearbox type, etc.  All I can say is I only have one example of similar cars I have played with using the two methods, if I were to take a guess based on feeling and incomplete data I would say the total shift time is about 25% longer on the car that uses barrel positon.

Hi Mapper,
I have some experience with both methods.  Strain gauge based cut initiation gives the absolute best result but obviously comes with a price tag.  Barrel position cut initiation actually still works pretty reasonable but you need a longer, more noticeable cut event and the actual shift is slower.  I guess this more prominent shift cut event may also have traction consequences to consider in some disciplines.
The difference is with a strain gauge your cut doesn't initiate until a preset shift force is reached - this preloading removes all mechanical backlash from the gear linkage/barrel/shift forks etc so the gears are basically ready to "pounce" as soon as the torque reduction is activated.  With a barrel position based system you initiate the cut basically as soon as movement of the barrel is detected so you are already cutting power when you still have all the backlash to "use up" and the gears havent even thought about starting to move yet...