Adamw

If its been sitting a while with ethanol in it I would first suspect the injectors are stuck. You can use the injector test function to turn each injector on individually while listening for the clicking. Unplug the fuel pump relay first so it is not spraying fuel when you are testing. Similarly you can use the ignition test function to check there is a spark on all 4 plugs. Pull the plugs out and rest them somewhere so they are grounded. Ign 1 test should make #1 & #4 plugs spark, Ign 2 test should make #2 & 3 plugs spark. Nothing looks too out of place in your log.

Your trigger setup looks ok assuming they are the 3 wire hall sensors, so there should be a signal. What you can do to diagnose is unbolt the crank sensor (leave it plugged in), and with ign on, while watching trigger signal runtimes you can wave a spanner or some other iron object past the sensor and the trigger signal runtime should show yes. If no joy with that then check with a multimeter there is 12V at the sensor and you can also check if there is a 0-5V signal coming out of the sensor when you wave the metal past it.

No, you are making it more complicated than it actually is. It is simple - the absolute only way Aux 4 can backfeed is if there is some voltage on the other side of the boost solenoid. According to your diagram there is only two ways this could happen - either there is 12V coming out of the flexfuel sensor (via the DI pull-up) or that flex fuel relay is staying engaged. If it still happens with flex sensor unplugged then that rules that path out. The only 12V source left is from the flex relay. So this is why I say to unplug or snip pin 85 on that relay. So this proves the voltage is coming from that relay. If that relay really was already "off"/open then unplugging it would do nothing.

The only way the solenoid can click is if there is still 12V on the feed side of it when the ecu is off. So for whatever reason either that Ethanol sensor relay isnt shutting off or the wiring isnt like you draw it. Did you try with the flex sensor unplugged? Another quick test would be if you snip/disconnect the 85 wire off the ethanol relay when it is back feeding does it then all shut down?

This.

Ive had a quick look over the tune and nothing leaps out at me as obviously out of place. What I would do initially though is change fuel mode to modelled (rather than multi-fuel) treat it just like it is running on a single fuel, as that then takes a whole lot of settings out of the equation which will make it easier to diagnose. Can you give us a short log of it running? How come the fuel tables in the attached map dont have 100%VE in the idle area like you say but it appears it was idling when you saved that map?

If it feels like it is shutting down, I would start by setting set up ECU logging, record battery voltage, a few other common variables as well as trigger stuff at 100Hz. That should at least show if there is any shutdown going on due to lose power connection or if it is just a misfire.

Or just put the resistor at the furtherest end right from the start. The only thing that is required is a resistor at the far end of the bus, there is no need for it to be close to a device.

The bottom one is the only one showing correct polarity. So for it to work you will need to find why the cam sensor disappears. It suggests to me that the cam sensor is only getting a ground through the crank sensor wiring somehow, so you either have some wires crossed or the pinouts of one of the sensors is wrong.

If you want help with anything you need to attach your tune and a log.

Unfortunately no - at least it is not functionality we had planned for the near future.

If the coils are wired wasted spark then yes you could run it with no sync to get a capture. Otherwise you can run the engine fully sequential as I mentioned earlier using the cam window sync mode. This will at least give you the home position scope, it may freak out when the cam is moved but Im not sure.

Need a scope capture at crank speed and one at fast idle as many of the mazda sensors flip polarity around idle speed so if it does flip we need to know which edge doesnt move in relation to TDC/spark. If you cant do one with cam fully home and another fully advanced, then just a capture at home and a mechanical measurement of how far the cam can advance will be sufficient.

Ok, sorry I cant help with a Mac, I have never touched one so dont have any experience to offer. G4+ used an old silicon labs VCP where as G4X uses a FTDI chip that does both VCP and a direct native USB, so the fact G4+ worked with a similar setup is not really relevant. I have however seen some other users claim that G4X can work with a mac but I have no idea what emulator system they are using. You may have to experiment with various different VM systems before you find one that works. The error you have suggests the VM is not passing the USB commands through to the real ports correctly. Edit: Yesterday on the facebook group "Link ECU Tuning and Tips" there is some discussion about this subject. Some claim it works, others claim it only works on older macs and not the latest. Parallels and VMware fusion are the two options that are mentioned.

This is an error that I havent come across before. Are you using the latest PC Link V6.19.65? Is it windows 10? Do you have an entry in both the com port section and the Universal serial bus section like my pic below? Which one is showing the error?

Unfortunately the VVT is still not controlling well. You are going to have to go back to custom PID and experiment a little to see if you can improve it - otherwise leave it for the tuner. Generally I would set up a time plot like below with cam position and target plotted on top of each other, they should generally follow each other reasonably well. You can see in this pic below exhaust is not too bad, but inlet is bouncing around +/-5deg when its trying to target 20deg. This is probably too much proportional. Your DBW calibration still doesnt look right. Are you using the TPS calibration in the E-throttle section where it moves the throttle automatically?

No, there will only be a fault reported if there s a bus problem. This would be things like incorrect bit rate, wiring, or wrong ID. There is no way the ECU can know if the steering system is happy with the data format or not. I suspect it will likely just not work.

I think the answer to the first one is it was probably designed to only allow a valid number to be entered, and a decimal point (or a comma for some europeans) is generally not considered a valid way to start number, it would usually have a zero in front of it. I have seen some discussion which says if the range of numbers never exceeds 1 then the leading zero can be left off, but it is not common - at least in my world. It might be an American thing to leave the leading zero off and not something I had ever considered people would try. I will ask Vaughan if it can be made to work without the zero when he is back from holiday. The table axis setup one I cant quite understand what you mean, I will attach a video at the bottom to show how I use it and how it works for me and maybe you can elaborate after seeing that. As far as I have noticed it is similar or the same as how it worked in G4+. The search has definitely slowed down a bit since G4+ as the way the sorting works in the background had to be sacrificed since it was bogging down slow laptops too much with all the extra parameters that G4X has. As for the AFR target tables: Most basic core functionality that every/most users will need has a hardcoded table that is always there and always being processed in the background but any "extra" functionality that only select users will need will be allocated one of the "GP tables" only when/if they turn the function on. This way you dont have the micro working hard all the time processing hundreds of tables that no one is using. Recent firmware gives all users 45 of these GP tables (FYI, You can see how many GP tables you are using by clicking the Table Allocation wrench down the bottom of the ecu settings tree). AFR target 1 is a core hardcoded table and AFR target 2 is allocated to a GP slot when you turn on multifuel. So that is some background of why they are different - but I dont actually know why they originally choose a different size for AFR target 1 - I suspect it may be for legacy reasons so that G4+ maps can be imported easier or something - or it could just be they didnt think that resolution was needed for AFR target. But I will again ask Vaughan about that when I can. Video: https://1drv.ms/v/s!AiYbYlZQuRHPvS6HtlMCowX3PXbj?e=MrYxLN

Hi Brad, Thanks, I had already reported this as a bug a couple of months ago but in my testing I had only noticed it on some of the less commonly used tables and I stated the fuel and ign were working correctly so it possibly didnt get the attention it deserved. I see it is planned to be fixed for the next release. I will update the task so that we look at fuel and ign as well. I just gave it a quick try but cant reproduce the problem with the ignition table. Sometimes I see a very small amount of movement but cant get it to do anything too weird. If you find any steps that make it obvious please let me know. But Im hopeful the more obvious problem tables will give them the clues they need anyhow.

Since none of the messages on the opengarages page use "Byte 0", Im assuming they are naming the first byte "Byte 1", whereas we call it byte 0. They say engine speed is in Byte 1/2, but the CANdo example has data in byte 1,2, 4, 7 & 8, so there maybe something else beside engine speed that is needed. They also do not say which is the high byte, and what bit rate is used, so you'll have to make a few assumptions. I would start with a bit rate of 500K. Set up like this and see if anything happens:

Yeah, looking closer. Control on the intake cam is a bit erratic. I notice you have PID setup set to custom, did you try it on the defaults? It looks like you need to do a TPS calibration as your TPsub shows 97% when your TP main shows 4%. And if you set your E-throttle target and idle base pos and idle ign tables to something like below it will probably improve your idle alot.

Are we talking for an auto trans? How does the ECU receive the signal? Is the signal just on/off or some sort of message that contains info on how much the torque needs to be reduced by? Is the signal active for the whole time the TR is required, or is there some timer and ramp functionality required after the signal? Is it turbo or NA? How much does torque need to be reduced by (maximum percentage)? What ecu do you have?

It is a long way off, only in early development. It will be a year or more at least.

Reading through the notes of the recent changes to temp input capabilities it does look like the intent was to allow the temp inputs to be used in this way, but I think pressures may have been overlooked. I will get this on the list to have another look at. In the mean time the work around would be to do it via a GP input and math block like below. I know, a bit of a ball ache...

That doesnt sound right. Might pay to return it to be tested. Have you tried both extension cables and both knock sensors to rule those out as the culprit? On mine the noise level it is pretty uncomfortable on full volume. And to confirm - this is a Knockblock right? Not a Knock Link.