Rawze's VGT turbo controller box

[Rawze]

The plans are not public, however, I do not mind discussing any information verbally on how things work towards someone who is wanting to make something for themselves.


Here are just some basic things that I keept in mind or had to endure ...

*========
* I started out with a simple idea of having a completely self-contained "control box" for these turbo actuators so they could be tested, calibrated, etc.. all on their own + have its own self-contained battery power and everything. Something that did not need a computer attached to it at all, completely stand alone, quick and convenient to use whenever and wherever needed.

I wanted to be able to ...

-- manually control the actuator with a simple knob.

-- have the ability to calibrate the actuator to the turbo fully, so that a laptop, etc. is not needed.

-- have an oscilliscope graph readout on screen showing the resistance on the motor thru its travel range so that I can test turbos to see if the control arm was hanging up or worn out, all without having to remove the actuator from the top of the turbo.

-- be battery powered with enough "umph" to run the actuator/turbo stand alone, so that it did not need a bunch of wires and cables, etc. - I wanted it simple and clean with only the one connection just like it is done on the engine.

Those were the goals to reach on how I wanted it to work.



Then came the nightmares ...
*========
* The turbo actuator needs a constant steady stream of information flowing between it and its host (the arduino in this case) on the J1939 data-link to and from it at all times, non-stop. Otherwise it will not run correctly, fault out, and/or constantly jump to a default position.

*========
* Because of the steady flow of data needed to control it, MOST arduino boards are not nearly fast enough in processor power to keep up with the actuator full time + at the same time, be able to deal with any user interaction, display screens, etc. ... even if someone cut the programming to the absolute assembly-language bone to try to keep up. I found all this out the hard way. I have an entire grave-yard worth of failed attempts, or attempts that just were not fast enough in the end.

The Uno, Micro-Pro, Mega, and most all the rest of the normal Arduino boards just cannot keep up properly. I even resorted at one point to using multiple boards networked together to share the processing load, this worked, but it was a messy way to do it that way and the oscilliscope-display was not responsive enough for my tastes.

*========
* Because most arduino boards cannot keep up with both the actuator and user interfacing, the bare minimum Arduino needed is a Teensy-3.6 controller set on 128MHz clock speeds. This is only after writing all 100% optimized custom libraries for the screen and for the J1939, it then does ok.

*========
* Any project involving the J1939 where a constant stream of information is needed non-stop ... like the turbo actuator needs ... and an Arduino board is involved, means that the Arduino is going to have to fully multi-task. Arduino processors are not capable of this on their own, not even the NXP processor in the Teensy3.6, which does have its own built in J1939 capabilities. This means that I had to write my own task manager for the processor to handle fully multi-tasked operations correctly.

*========
* I also had to write my own custom libraries for the display completely from scratch using the engineering data-sheets, including the text to pixel-placement translation tables, routines, etc., as all of the pre-made libraries that came with it were nothing but bloat-ware garbage that slowed down the processor too much to be useful.

*========
* Unlike cummins engines where the J1939 is at 250kbps, Detroit actuators use J1939 at much faster 1mbs buss speeds. Because of this, I also had to completely re-write all of the J1939 and can-buss front end driver libraries from scratch, again using the engineering data-sheets for the chip-sets, because the pre-made ones from NXP.. the chip-maker themselves... were absolute garbage and too slow to be useful when the J1939 buss speed was running +1MBs and Detroit actuators were connected to it.


*========
-== As someone can see.. There was a whole damn lot of sweat and tears and failed attempts + re-works and re-writes of low-end driver libraries, and digging thru chip-set data sheets to squeeze the program hard enough for it to all work smoothly .. but I finally got it.

At first i thought it would be a fun, easy project.. but as it progressed, I ended up taking the whole project on as a personal challenge in remembrance of those days not too many years ago when I had to regularly deal with logic control processors that were just not fast enough, or smart enough to do what you wanted them to... but somehow, you know it could do it if all the tricks were used to get it there.

It is like when someone knits a custom sweater from scratch .. every stitch by hand, months of work, intricate patterns, etc. .. and then others comming along and saying, that looks simple enough.. "I want to make one too". -- My response at this point so far is .. your more than welcome to make your own. I am not sharing the exact pattern specifically, but I am willing to tell you all about what I did, saving you most of the headaches I had to endure along the way.