Adamw

I had just made some changes to your first file so give this a go. If no good ill have a look at your 2nd one tomorrow. Also, your ECU firmware is quite old so you should update that too. Brad PDM V2.pdmc

There is not im sorry. The Ign Sw pin disconnects the main power inputs. You would have a significant parasitic draw if the micro and pull-ups etc stayed live all the time. What most refer to as "24hr circuits", typically for security, hazards and park lights etc needs to come direct from the battery with a conventional fuse.

What is the ignition system?

Note GT86 CAN is only going into G4X, not G4+. I dont think you would be able to do it with the user streams in G4+, there is some fairly complex CAN in the 86.

Ok, cant tell much from those pics, but I would start by peeling that tape off where I have marked and confirm you have >2.5V on the lambda white wire and <2.5V on the green.

Did you do this yet?

What ecu and car?

None of your files are accessible. You need to go into the sharing settings and set it to "anyone with link".

Can you attach a log and the tune. There is no difference in terms of bottom board requirements. Did Link modify the board?

Your MAP is not working in the first log but it is in the second one. I suspect the wideband isn't working as it shows 0V on AN Volt 4 in both logs. But you should now be able to get it running better by adjusting the master fuel now.

The ECU already has freewheeling diodes built-in on aux 1-8. It possibly could be damaged, but that is not common. I wonder if the main power supply to the ecu is missing? Can you check these runtimes in your log to see if either is abnormally high:

The ACD ecu needs a TPS signal to pin 39, typically you dont need to do anything if you use the original TPS wire to the throttle body.

Ok, so two things to try. The first one is change the trig 1 filter level to 1. If you are still getting trig errors with the filter reduced then I would next try a stronger pull-up resistor, these sensors get a bit slow if the pull-up isn't strong enough. The ecu's built-in pull-up is 4.7K to 5V, ZF's datasheet recommends 1K if powered by 5V or 2.4K if powered by 12V. Turn off the ecu pull-up when you do this. Dont worry about the cam sensor, just the crank due to the tooth count.

I think if you set up antilag enable to very high RPM so it never activates, set cyclic mode to sys armed, then use the cyclic ISC override table instead, this will still allow overrun fuel cut to work.

The ecu is showing transmit errors on CAN 1 so this means it is not seeing any response from the other devices. This would usually indicate a bus wiring issue. Note CAN 2 should be set to 350Z mode, but that is not going to cause your issue. Can you attach some pics of the CAN wiring.

There are 4 spots in that log where you get a trigger error and the RPM spikes very high, this trips the RPM limit. Its always at fairly high RPM, about 7000 is earliest it happened. I see you have a 36-2 crank trigger with a hall effect sensor, do you know what specific sensor it is using?

It is a little worse than typical, but my initial feeling is its probably not bad enough to cause a real tuning issue. Your TPS delta at WOT doesnt go about about 5 very often so that is still low enough to not be considered a transient for most functions. Accel deadband would need to be around there. Your "TPS" may look stable since it only has a 0.1% resolution and the calibration span tops out at 100.0, but if you look at the raw voltage you will see a different story. In the short WOT blast shown below your TPS voltage varies from 3.55 to 3.47V (80mV) when you would expect the throttle should be hard against the mechanical stop. Nissan, like many others around that era had pretty horrible grounding design with some sensors grounding through chassis ground etc, so it could potentially be a grounding issue, but if we compare the AN volt 1 and AN temp 1 at the bottom of the pic, they only vary by about 10mV over the same period, so that gives some hope it is not a wide spread ground issue. The first thing I would look at is the mechanical coupling of the TPS sensor, from memory the RB26 sensors arent spring loaded, so if there is any backlash in the "D" drive then the sensor can bounce backwards and forwards with vibration. I have a vague recollection of one doing this on a car I tuned years ago and I pulled it off, put a blob of silicone in the D cavity, then refitted it and let it dry.

Your MAP sensor is not seeing any vacuum, do you have it connected to the manifold?

I think Vaughan is probably thinking the same as me, your trigger signal looks perfectly fine but the status runtime suggests your trigger settings are wrong. I suspect you either have the tooth count wrong, mutlitooth position wrong, or you have sync mode set to cam pulse instead of crank pulse. You can look at our FD basemap for the correct settings.

The latest software is 1.699 and latest firmware is 1.645 so start by updating both those. If you still have issues after that then go to >help >application log and attach copies of those log files here. https://linkecu.com/software-support/pdm-link-downloads/

Can you attach a copy of your tune.

I have rarely seen G4+ PC Link crash personally and I see very few reports of it through tech support or in the forum, so I dont think it is a common issue. The only theme I have seen a few times over the years on the forum here seems to be related to a monitor going to sleep or if a secondary monitor is connected while PC Link is open. I've never been able to reproduce that in-house though. Most of us at link have ecu's connected full time and PC Link open 24/7 on our office PC's, most with multiple monitors too. When you say "sitting there in the background", what other apps are running? Do you have a map and log open, or just the program? What's the display adapter listed in windows device manager?

Ok, files updated. NOS conditions ECT>60C, Gear>2, CAN DI3 on (Nos keypad button), TPS>90, No engine limiters active, RPM between 3500 & 5500. When these conditions are met the request is sent to the PDU and the 4D fuel and ign tables are activated. Both done. Keypad buttons set up as overrides, so the water pump will run when ECU is requesting it or when you press the button. Fan is set up the same, with the temps you specified (set temps in ecu Engine fan settings). Fuel pump will only run if the ecu is requesting it AND the keypad key is on. Charles racecar CAN to PMU V3.pclr charles sa14 CAN from ECU V3.pmu

Ok, I have attached a fixed config. The problem with your one is it was an empty config from an early software version, ie it contained settings only, but no awareness of hardware. Recent software has been changed so I dont think this trap exists anymore. The most recent software is 1.6.99, so confirm you have that on your PC. Make sure PDM firmware is up to date and this one should load correctly. You may get some errors after loading that multiple functions are connected to a pin, you can ignore these. Oat DCV fixed.pdmc

Ok, some examples set up in your configs. The ECU is sending Virtual Aux 1-7 and coolant temp to the PMU. Fuel pump and fan request are included in these. The PMU is sending 3 keypad button states to the ECU, these are received as CAN Dig 1-3. G4+ cant send PWM output signals via CAN so we cant do the PWM fan directly. The ECUmaster PMU generally cant PWM a fan anyhow. But just incase you wanted to do PWM fan, I have sent ECT to the PDU so you can do a PWM table at that end. last V2.pclr charles sa14 CAN from ECU V2.pmu