That is crazy .. I thought Dynatrac was doing well from themselves. Sucks that of all people they got purchased by Randy's .. I guess money speaks.
Ya'll ever just get tired of dealing with one company's crap?
- Thread starter mrblaine
- Start date
That is crazy .. I thought Dynatrac was doing well from themselves. Sucks that of all people they got purchased by Randy's .. I guess money speaks.
The three major parts that are custom consists of the axle stub, wheel hub and spindle so pretty much no way to junkyard your way into it.
OP
The biggest issue I've seen are the stub shafts are not heat treated or they are not good material that can be so they are very soft comparatively and break much easier than they should. MM has a hub issue in they aren't very stout for what we need them to do. Warn had an issue early on with the 5.5 spindles being soft so they heat treated them and bumped up the wall thickness to help. What would happen is when the spindle nuts were tightened, it would collapse the tube where the groove for the tang on the spindle washer(s) is and then the spindle nuts wouldn't hold torque.
OP
I can sorta cost effectively solve two of those, the stub is the hard one. The problem with spindles is you need to pony up for a forging near to net size to slow down just how much machine time there is on one. The bearing hub can be cast iron and very easy to get that close to net to save machine time there.
Reid had the Junkyard special with that conversion knuckle but that still wasn't cheap by the time you got it working.
OP
Doing well wouldn't be the sole criteria. That just costs more.
OP
OP
Wasn't the original Warn kit based on the Ford Ranger? That had locking hubs and a 5 x 4.5 bolt pattern for a while.
OP
Which they improved with a stronger housing. Warn certainly had some growing pains with the small conversion. I know of at least 3 iterations of spindle nuts over the years one of which I'm pretty sure me, a couple of members of the public and a few folks at Warn ever got to deal with. The outer had some small set screws you tightened down against the tanged washer to lock it in place. Pain in the ass if you didn't figure it out and they were buried in grease. Then they went to the inner, washer, outer with both nuts the same thickness and a very thin washer. They finally got it right with the hardened nuts, washer with holes in it for the pin on the inner nut, and the thinner outer nut.
Actually, it can be done with only a custom knuckle by adapting existing an spindle, brake, etc. to a Dana 44/Dana 30 inner C. Reid was doing this exact thing but stopped producing the knuckles so they are now unobtanium.
With the Reid knuckles, all the parts except the knuckles are available off the shelf and are basically what you might find on a mid-70s Chevy or Ford pickup. I am lucky (IMO) to have this setup recently installed and also fortunate to have 1 of the few BBKs @mrblaine made for these knuckles but the conversion can also be done with off-the-shelf brake parts.
If only someone made a similar knuckle. Maybe Reid would sell the tooling? Or maybe there is a better spindle/hub option to adapt that would work with the larger UJoints?
I believe the YUKON 5.5 kit has a custom spindle, hub and stub shaft. Not sure if t the locking hubs are custom for that kit or not. Yukon's design appears to have some advantages over the Reid option but apparently, their QC and customer service are a joke.
I think the Yukon kit adds less width to the front axle than the Reid knuckle conversion.
If Yukon makes the stub shaft, you should be able to run the larger axle Ujoints which will not fit through the Reid knuckles.
Last edited:
Oh I remember all too well. I remember the Dana 35 small hub full float kit and all the horrors associated with it from broken hubs (worse than the front conversion), the oil leaks and the random hub disengagement that would happen under load that was blamed on the housing supposedly pulling forward under load.
To answer the original question, yes.
There's a prominent valve manufacturer in my industry who, as the industry had evolved with technology over the past decade, has gotten heavily into electronic controls. They have a particular line of valve controllers that all use essentially the same hardware but different software for different applications. The problem I have is that it seems like each application got handed off to a different coder, and sometimes changes hands during its life cycle with no consideration for interoperability or backward compatibility. The comms spec that a German fan manufacturer takes 120 pages for gets compressed into a 1-2 page table and leaves it to the reader to fill in the blanks.
Example. First time I needed to communicate with one of these things over a serial line I had to trial-and-error which values they pass as signed (-32768-32767) and which are unsigned (0-65535). The next one I set up in exactly the same way, but the devices were a few years older than the first group I encountered...despite being the same application, my values were coming in off by a factor of 10. Apparently in the past they scaled the values (so 73.8psig = 738), but then they decided that wasn't necessary and just started rounding it to the nearest integer.
I recently got another application on this hardware that wouldn't respond. Turns out that I was writing a value to it that was outside of its allowable range, and unlike the previous devices which would just ignore it but otherwise still work, this one shuts communication down entirely. We got another one from the manufacturer that had a different software revision, tried that one, and it actually responded with an error code that told me enough to figure out what the problem was.
I've got another one of their products in my office that I still haven't gotten to talk to my stuff.
Unfortunately their salesman is very likeable and lives in the same town with the corporate HQ of my biggest customer, so I'm expected to deal with them a lot, and probably will forever. I could code circles around them but I can't replace their devices without the R&D budget of a multi billion dollar company.
There's a prominent valve manufacturer in my industry who, as the industry had evolved with technology over the past decade, has gotten heavily into electronic controls. They have a particular line of valve controllers that all use essentially the same hardware but different software for different applications. The problem I have is that it seems like each application got handed off to a different coder, and sometimes changes hands during its life cycle with no consideration for interoperability or backward compatibility. The comms spec that a German fan manufacturer takes 120 pages for gets compressed into a 1-2 page table and leaves it to the reader to fill in the blanks.
Example. First time I needed to communicate with one of these things over a serial line I had to trial-and-error which values they pass as signed (-32768-32767) and which are unsigned (0-65535). The next one I set up in exactly the same way, but the devices were a few years older than the first group I encountered...despite being the same application, my values were coming in off by a factor of 10. Apparently in the past they scaled the values (so 73.8psig = 738), but then they decided that wasn't necessary and just started rounding it to the nearest integer.
I recently got another application on this hardware that wouldn't respond. Turns out that I was writing a value to it that was outside of its allowable range, and unlike the previous devices which would just ignore it but otherwise still work, this one shuts communication down entirely. We got another one from the manufacturer that had a different software revision, tried that one, and it actually responded with an error code that told me enough to figure out what the problem was.
I've got another one of their products in my office that I still haven't gotten to talk to my stuff.
Unfortunately their salesman is very likeable and lives in the same town with the corporate HQ of my biggest customer, so I'm expected to deal with them a lot, and probably will forever. I could code circles around them but I can't replace their devices without the R&D budget of a multi billion dollar company.
OP
Gotta love that. Evidently no standards in that industry? Reminds me of an oceanographic instrument (serial interface) that required BREAK to wake up. BREAK isn't a character, it doesn't transmit over packet switched networks or radio links, so we had to program the local controller to translate ^B to BREAK so we could operate this thing remotely. The mfg. is otherwise a great company, but I pounded on them every time a rep was in-house over this. It was fine in 1965, in the 90s and beyond, not so much.
A few that ran them with 33 inch or smaller tires. And because of what it would cost Warn would not make a solid drive flange.
standards only to the extend that Modbus RTU is standardized. So the data structure is pretty well standardized but there are still a lot of options within Modbus. Some manufacturers publish a huge modbus manual with every register described in detail so you can set up the client end just based on documentation. not these guys...gotta set something up and have a physical example of their device to try it out on to figure out the rest...and hope the one you're talking to in the field works the same way.
The HVAC industry has it's own standardized communication protocol called BACnet. It's extremely detailed and makes it really easy on the client side, but the server side is incredibly onerous. It includes a discovery feature where the client can poll the server and the server responds with every available point, all of it's properties (including a name, description, unit of measure and about a dozen more) so the integrator doesn't have to match it all up in a table. Normally it's not that big of an issue but my biggest customer has their own standard of how they want every variable to be named and described, and I can't use their variable names because they have spaces, so I have to do a manual overwrite operation to meet their requirements. I have a section of my program that has 1200 lines of code just to write strings to the BACnet server. It's a slow write process, so it's a user-triggered operation that only has to happen once, and I only write 20 values per program cycle to keep from slowing it down, and as a result it takes 75 program cycles to complete.
OP
That was much smarter than it appears on the surface. I made prototype steel body Ranger style hubs with a drive flange set up for Superior.
I took a simple broken hub repair for 75 bucks at the time and turned into full blown catastrophic failure of practically the entire hub kit with the exception of the rotor. When the stub failed, it was typically a green stick fracture that then allowed the two ends to bypass inside the spindle. That ruined the spindle, the bearings, and the bearing hub. It was a total and complete abject failure. Oddly, the drive flange is basic 1018 CR round bar with no other pre or post material treatment and they survived without a single failure as did all the hub bodies. I employed a unique manufacturing method for them in that I turn the round splined body out of basic DOM, built in a 10 thou press fit, pressed that into a hole in the flange with a nice deep V groove at the juncture which we tig welded. Not a single failure of that joint.
Works for Inner C's pressed onto axle tubes, why not a hub body? I was right, it worked. I learned a fair bit from that experiment, the best lesson was painful.