R32 GTST - 600KW+ RB28/CD009 Build

[joshuaho96]

2 hours ago, TurboTapin said:

Well some mostly good news and some slight bad news. 

Good news is cylinder 6 did in fact only require a honing and I'm good to run my 86.5mm pistons again. I should also get the block back by end of week. Bad news, had a few surprises pop up.

First, main and rod bearings were trashed. No sign of any heat damage. I knew right away what caused this... I had not packed my oil pump originally and spent a lot more time than I would have liked cranking the motor to get oil pressure. It sounded fine once started so I chucked it up to luck and forgot about it. Luckily rod and crank are fine and just need new bearings. Engine builder agreed that this was the cause. 

 

Another surprise that carbon covered up very well that I didn't catch, something got sucked up and went through cylinder 1, 2 and 3. Luckily this was no cause for concern, just needed a bit of cleaning up. Valves look fine but he will vacuum test the head this week to confirm. I'm presuming this was something left over from welding my intercooler piping, but we'll never know. I'm going to thoroughly reclean everything. 

 

So all in all, happy the motor is fine, and I'll get it back much sooner than expected. I'll also be taking the time to convert my WMI system over to direct port. I'll snap some pictures of that when the parts come in. 

Is this preventable by priming the system with external oil pressure? I've seen the speed academy folks hook up an external oil priming system to the oil pressure sensor port with an air compressor to check for oil leaks before putting an engine back in a car. Something like this: https://www.jegs.com/i/JEGS/555/23550/10002/-1?gPromoCode=SPRINGINTOSPEED_APR25_5Off&gQT=1

[TurboTapin]

4 hours ago, Duncan said:

It may not feel like it to your wallet....but sounds like this was one of those "lucky you did it" rebuilds.

Hopefully you have better luck this time

That's exactly what I told myself. I'm happy it came out. 

[TurboTapin]

3 hours ago, joshuaho96 said:

Is this preventable by priming the system with external oil pressure? I've seen the speed academy folks hook up an external oil priming system to the oil pressure sensor port with an air compressor to check for oil leaks before putting an engine back in a car. Something like this: https://www.jegs.com/i/JEGS/555/23550/10002/-1?gPromoCode=SPRINGINTOSPEED_APR25_5Off&gQT=1

Besides packing it, you can also fill your pump through the oil filter inlet port. After cranking for what felt like an eternity without pressure, i fed a tube in through there and filled it with oil. Cranked for a few seconds after that and had pressure. 

[Dose Pipe Sutututu]

On 03/04/2025 at 6:06 AM, TurboTapin said:

WMI system over to direct port.

This would be interesting, would you feed it via a 2nd row of injectors? Or just usual WMI nozzles?

[TurboTapin]

53 minutes ago, Dose Pipe Sutututu said:

This would be interesting, would you feed it via a 2nd row of injectors? Or just usual WMI nozzles?

There are a few different ways of doing it. I'm currently running two 1000cc pre-TB nozzles and PWM the pump for control. I'll be moving over to a constant pressure system and direct port. I'll run the pump off a regular relay, have it cycle on roughly 5psi before I start injecting to build pressure and then PWM a WMI solenoid (It's basically an injector that can take a lot of pressure and not corrode with water and meth.) The solenoid feeds the 6 direct port ~200cc nozzles. I'll also keep one ~250cc pre-TB nozzle to help keep IAT's in check. 

Safety will be a little different as well. I used to use a pressure switch but will be moving over to a pressure sensor between my solenoid and nozzles. I'll trigger my solenoid and if I don't see specific pressure within a specific timeframe (e.g 100psi within a second, 175psi within 2 seconds), I kill it and revert back to non WMI maps the same way I did it before with 4D in Haltech. I was just figuring out the timers in my ecu last night. They made that a little more complicated than I would have liked... I wish Haltech offered a larger set of logic/math functions like other ecu's do. I can't do very much with just AND's and OR's. 

I've been asked to do fuel/ignition mapping on a medium bore engine at work in May (192L V16). Being the only programmer in my region and having went and opened my mouth about knowing the ins and outs of fuel/ignition mapping, I have now been deemed an expert. Fun fun. The entirety of the logic and algorithms are programmed in C on a PLC. As I spend more time figuring it all out, I like what I see and eventually I may consider doing the same as a pet project to replace my ecu. 

 

Edited April 4 by TurboTapin

[Dose Pipe Sutututu]

Thanks for the explanation, sophisticated WMI setups aren't  too common here in the land drop bears so. Only reason I'm curious is because I feel that the end of bowser E85 is coming. Just a matter of time.

[MBS206]

10 hours ago, TurboTapin said:

There are a few different ways of doing it. I'm currently running two 1000cc pre-TB nozzles and PWM the pump for control. I'll be moving over to a constant pressure system and direct port. I'll run the pump off a regular relay, have it cycle on roughly 5psi before I start injecting to build pressure and then PWM a WMI solenoid (It's basically an injector that can take a lot of pressure and not corrode with water and meth.) The solenoid feeds the 6 direct port ~200cc nozzles. I'll also keep one ~250cc pre-TB nozzle to help keep IAT's in check. 

Safety will be a little different as well. I used to use a pressure switch but will be moving over to a pressure sensor between my solenoid and nozzles. I'll trigger my solenoid and if I don't see specific pressure within a specific timeframe (e.g 100psi within a second, 175psi within 2 seconds), I kill it and revert back to non WMI maps the same way I did it before with 4D in Haltech. I was just figuring out the timers in my ecu last night. They made that a little more complicated than I would have liked... I wish Haltech offered a larger set of logic/math functions like other ecu's do. I can't do very much with just AND's and OR's. 

I've been asked to do fuel/ignition mapping on a medium bore engine at work in May (192L V16). Being the only programmer in my region and having went and opened my mouth about knowing the ins and outs of fuel/ignition mapping, I have now been deemed an expert. Fun fun. The entirety of the logic and algorithms are programmed in C on a PLC. As I spend more time figuring it all out, I like what I see and eventually I may consider doing the same as a pet project to replace my ecu. 

 

What logic functions do you feel are missing from the Haltech that others have?

Is there a limit to how much logic you can string together? By limit, I mean it's like only a single level or two levels of Boolean logic.

Realistically, AND, OR, and NOT, is really the only logic you need and realistically, you can also do away with another logic gate of the three above . With those three you can build the full functionality of any Boolean logic you want.

[GTSBoy]

51 minutes ago, MBS206 said:

Realistically, AND, OR, and NOT, is really the only logic you need and realistically, you can also do away with another logic gate of the three above . With those three you can build the full functionality of any Boolean logic you want.

Unless things that you want to do include reference to time. Simple Boolean logic is only good for digital inputs or analogues that have been thresholded into digitals. But unless you also have a timer function available (which would more ideally be located inside the program, rather than being forced to implement a timer outside the ECU and bring it in as a seperate digital for every time delay you want to implement), then you can't do some of the things that you might want to do.

My PLC ladder logics are obviously littered with program blocks, because that's easier than building it all in ladder gates, but the most frequent of those program blocks is a simple timer, because you actually can't otherwise do that in ladder at all.

[TurboTapin]

2 hours ago, MBS206 said:

What logic functions do you feel are missing from the Haltech that others have?

Is there a limit to how much logic you can string together? By limit, I mean it's like only a single level or two levels of Boolean logic.

Realistically, AND, OR, and NOT, is really the only logic you need and realistically, you can also do away with another logic gate of the three above . With those three you can build the full functionality of any Boolean logic you want.

All of them are missing. You do not get much done with just AND, OR and NOT unfortunately. Ecumaster for example has a text based editor with at least 60+ math and logic instructions. 

Edited April 5 by TurboTapin

[TurboTapin]

1 hour ago, GTSBoy said:

Unless things that you want to do include reference to time. Simple Boolean logic is only good for digital inputs or analogues that have been thresholded into digitals. But unless you also have a timer function available (which would more ideally be located inside the program, rather than being forced to implement a timer outside the ECU and bring it in as a seperate digital for every time delay you want to implement), then you can't do some of the things that you might want to do.

My PLC ladder logics are obviously littered with program blocks, because that's easier than building it all in ladder gates, but the most frequent of those program blocks is a simple timer, because you actually can't otherwise do that in ladder at all.

I just try to entirely stay away from ladder now unless it's something basic maintained by electricians. Even then and to your point, it mostly ends up being blocks I wrote in structured text. 

PLC's are slowly going towards C, C++ and C#. I just wish Allen-Bradley would jump on the bandwagon. 

[MBS206]

37 minutes ago, TurboTapin said:

All of them are missing. You do not get much done with just AND, OR and NOT unfortunately. Ecumaster for example has a text based editor with at least 60+ math and logic instructions. 

All other (Boolean) logic functions though, are just built on those blocks above. Which does give you a lot of functionality in logic.

It is basing that on using thresholds with analogue signals like GTS alluded to.

 

Not having things like timers will make it less useful for some of the ramp up logic you'd want, and again, on Haltecs capacity specifically, I'm not across anymore what you can / can't do with different tables.

 

I'm assuming, with your logic you want to implement, not only do you want your timing safeties, you're wanting to be able to derive the duty cycle for your solenoid, to maintain I'm assuming 175PSi?

Or are you using a standalone WMI controller to maintain the DC correct, and you just want the Haltech working out which fuelling maps you should be on?

[GTSBoy]

57 minutes ago, TurboTapin said:

Even then and to your point, it mostly ends up being blocks I wrote in structured text. 

PLC's are slowly going towards C, C++ and C#. I just wish Allen-Bradley would jump on the bandwagon. 

Structured text and other high level PLC programing languages are not allowable in Functional Safety. They are very difficult to audit.

My PLC stuff is almost exclusively oriented towards Burner Management Systems which are a particularly pernicious form of Safety Instrumented System, when implemented in an SPLC. Even the part of the code written to work in the non-safety logic part of the PLC, like with a Siemens S7-1500 series, still needs to be treated as if it was safety code, with access restrictions, code fingreprints and the like.

And Allen Bradley can go EABODs. They ae full of shit. They have this whole lie going on where they say if you use a ControlLogix controller and its IO, and then just duplicate the IOs (ie, run in series or parallel depending on type, to try to make it "fail safe") and "use these programming styles and place these restrictions on what you do" that you can achieve SIL2. What a load of crap. They just get away with it because no-one in the US seems to understand the first thing about Functional Safety and carries on as if all they have to do is buy only SIL2 rated equipment and hey presto, it's a SIL2 system. Idiots.

/rant

[TurboTapin]

18 hours ago, MBS206 said:

All other (Boolean) logic functions though, are just built on those blocks above. Which does give you a lot of functionality in logic.

It is basing that on using thresholds with analogue signals like GTS alluded to.

 

Not having things like timers will make it less useful for some of the ramp up logic you'd want, and again, on Haltecs capacity specifically, I'm not across anymore what you can / can't do with different tables.

 

I'm assuming, with your logic you want to implement, not only do you want your timing safeties, you're wanting to be able to derive the duty cycle for your solenoid, to maintain I'm assuming 175PSi?

Or are you using a standalone WMI controller to maintain the DC correct, and you just want the Haltech working out which fuelling maps you should be on?

To your point, boolean logic. We're not only working with bools in ecu's, so it's very limiting.

I wanted to setup a low WMI pressure alarm. After 1 second I want WMI line to hit 100PSI, 2 seconds 175PSI, etc. and trigger an alarm if it doesn't meet those thresholds. This would of taken me one very short line of text, but instead I had to bugger around with generic timers, conditions, etc. and so forth.

Edited April 5 by TurboTapin

[TurboTapin]

17 hours ago, GTSBoy said:

Structured text and other high level PLC programing languages are not allowable in Functional Safety. They are very difficult to audit.

My PLC stuff is almost exclusively oriented towards Burner Management Systems which are a particularly pernicious form of Safety Instrumented System, when implemented in an SPLC. Even the part of the code written to work in the non-safety logic part of the PLC, like with a Siemens S7-1500 series, still needs to be treated as if it was safety code, with access restrictions, code fingreprints and the like.

And Allen Bradley can go EABODs. They ae full of shit. They have this whole lie going on where they say if you use a ControlLogix controller and its IO, and then just duplicate the IOs (ie, run in series or parallel depending on type, to try to make it "fail safe") and "use these programming styles and place these restrictions on what you do" that you can achieve SIL2. What a load of crap. They just get away with it because no-one in the US seems to understand the first thing about Functional Safety and carries on as if all they have to do is buy only SIL2 rated equipment and hey presto, it's a SIL2 system. Idiots.

/rant

I've done a few BMS systems. Code in Canada use to force us to have any safety components outside of the PLC but with a code change back in 2018 I believe it was, we can now use safety PLC's to control everything. Sadly to your point, AB Guardlogix safety instructions for example are only available in ladder. 

Machine safety is a very big thing here though, you're constantly forced to migrate to the next best thing by OSHA. I honestly prefer safety plc's, including anything from AB more then I do working with old school safety monitoring relays. PLC is only one portion of it, the rest of the electrical still has to follow to meet SIL (Mechanically linked dual contacts, bla bla) 

Now tell me how to feel about safety over comm's (e.g Ethernet/IP CIP) on a unmaintained network haha

[GTSBoy]

4 hours ago, TurboTapin said:

Now tell me how to feel about safety over comm's (e.g Ethernet/IP CIP) on a unmaintained network haha

Safety network should be dedicated, duplicated, disparate physical route.

If it's not that, it was never good enough, even with maintenance.

[MBS206]

5 hours ago, GTSBoy said:

Safety network should be dedicated, duplicated, disparate physical route.

If it's not that, it was never good enough, even with maintenance.

When I worked at BlueScope Steel, we had an Ethernet network, with every switch setup with a duplicate switch.

Even when looking at all the primary switches, they had duplicate links, there was then also duplicated links between the primary in section A, to the duplicate in section B. So for each location that had networking, there was 8 network links.

This was all back around 2007. That setup caused sooooo many issues, as many of those links were fibre. The network guys ran everything with Spanning Tree Protocol. And then we had great joy... The FOC Transceivers were slowly dieing, but in an intermittent way. And a lot of the time as they started to die, they'd drop offline for about 30 seconds... Spanning Tree Protocol was requiring 45 seconds to "rewire" the network... And by the time it was mostly finished, it had to start again as the transceiver was back online... Queue entire production network being constantly spammed with the spanning tree protocol messages...

 

My god I do NOT miss working in huge environments like that!

[GTSBoy]

Luckily for safety applications, with dedicated links not being used for any other traffic, you simply run ProfiSafe (or an equivalent safety comms protocol from other vendors) over the top of ProfiNet (if that's what you're using, or Ethernet IP if you're stuck in the world of American PLCs and not verking vis ze Chermans) and the redundancy is more about being able to know that you need to cause a system diagnostic lockout because you've lost one of your comms channels, rather than not knowing that you've lost your only comms channel.

Granted, heartbeats and all that are possible and useable and all that, but some safety applications are are so time critical that you might not be able to afford a few milliseconds until the next check.

[MBS206]

20 minutes ago, GTSBoy said:

Luckily for safety applications, with dedicated links not being used for any other traffic, you simply run ProfiSafe (or an equivalent safety comms protocol from other vendors) over the top of ProfiNet (if that's what you're using, or Ethernet IP if you're stuck in the world of American PLCs and not verking vis ze Chermans) and the redundancy is more about being able to know that you need to cause a system diagnostic lockout because you've lost one of your comms channels, rather than not knowing that you've lost your only comms channel.

Granted, heartbeats and all that are possible and useable and all that, but some safety applications are are so time critical that you might not be able to afford a few milliseconds until the next check.

Ha ha ha, this stuff they had was installing Toshiba PLCs that were made some time in the 1990s, and they were replacing GEM80 PLCs.

To let those two talk (staged upgrade along a ~1.2km long building that was split into 4 sections), was a bunch of WinXP machines running Java gateways... There was no way to put something like ProfiSafe in...

Most of the HMI machines were WinXP, with Java program, with a custom button board emulating a keyboard... About the only buttons in the operator stations that went direct to the PLCs was the eStop.

There was some interesting design stuff in that place...

[GTSBoy]

2 hours ago, MBS206 said:

Ha ha ha, this stuff they had was installing Toshiba PLCs that were made some time in the 1990s, and they were replacing GEM80 PLCs.

To let those two talk (staged upgrade along a ~1.2km long building that was split into 4 sections), was a bunch of WinXP machines running Java gateways... There was no way to put something like ProfiSafe in...

Most of the HMI machines were WinXP, with Java program, with a custom button board emulating a keyboard... About the only buttons in the operator stations that went direct to the PLCs was the eStop.

There was some interesting design stuff in that place...

Yucky.

Things haven't gotten any better though. Now you have Emerson and Honeywell pushing these massive DCS/Scada things with proprietary hardware. They're not a PLC, they're not a computer, they're a...distibuted PLCish/DCSish monster of thing, that only they can program because they make the barriers to entry for anyone else so fricking high. And their developers are all located in the third/developing world (and India, in case anyone does not include that place in that category) and there are terrible failings of the ESl variety, of the care and common sense variety, and f**king forget about Functional Safety. Not a one of them has any idea what it means to comply with an IEC 615xx series standard.

[MBS206]

38 minutes ago, GTSBoy said:

Yucky.

Things haven't gotten any better though. Now you have Emerson and Honeywell pushing these massive DCS/Scada things with proprietary hardware. They're not a PLC, they're not a computer, they're a...distibuted PLCish/DCSish monster of thing, that only they can program because they make the barriers to entry for anyone else so fricking high. And their developers are all located in the third/developing world (and India, in case anyone does not include that place in that category) and there are terrible failings of the ESl variety, of the care and common sense variety, and f**king forget about Functional Safety. Not a one of them has any idea what it means to comply with an IEC 615xx series standard.

Honeywell... Ha ha ha an engineer friend left them about 18 months ago due to how bad of a shit show they were. Even she was bitching about how badly they run projects, and the programming issues they're constantly having within the projects.