Better be careful what kind of tape you use!

Fail.

His code checked input 2 twice.

Many fuel injected performance cars already do that. When the ECM detects you are at WOT, it will shut off the A/C compressor to get a few extra horsepower.

My 5.0L Mustang had A/C cut. I used to drag race it (:Yes with the A/C on:) and 12 seconds later, when I got to the "Big End" of the 1/4 mile it would be blowing warm air out of the registers, but as soon as I let off the gas, it would cool down again!

I tried running it with the A/C turned off as well, but it made no difference in my elapsed times. Changing to a shorty belt that bypassed the A/C and power steering was good for a tenth of a second or so, but it was not worth the hassle of changing the belt all the time, and sweating my butt off while I was having fun.

Cheers!

Ahhh the fun I've had in a Chinook...

You are correct, with a CV joint the rotational angle in = rotational angle out, this is not the case with a traditional U joint. If you've ever been in a 4wd truck, and taken a tight turn, you can feel the lurching as the U joints change the wheel speeds. This is not what is at play in this case.

The issue is due to the geometry of the front wheels, and the fact that they want to "flop" outwards when torque is applied. Normally one wheel would counteract the other, but the uneven angles in the drivetrain cause an additional imbalance that can be felt in the steering wheel.

Wikipedia to the rescue again...
  The main component of torque steer occurs when the torques in the driveshaft and the hub are summed vectorially, giving a resultant torque vector around the steering pivot axis (kingpin). These torques can be substantial, and in the case of shafts making equal angles to the hub shafts, will oppose one another at the steering rack, and so will cancel. These torques are strongly influenced by the position of the driveshaft universal joint (CV joint) in relation to the steering axis, however due to other requirements such as achieving a small or negative scrub radius an optimum solution is not generally possible with simple suspension configurations such as Macpherson strut.

From: http://en.wikipedia.org/wiki/T...

Cheers!

No she's a spreadsheet.

Many front wheel drive vehicles already have a torque imbalance going to the front wheels because the CV axles are different lengths, and therefore are at different angles. This causes torque steer under acceleration. I'd venture to guess that it must not be that big of a deal because cars continue to be built that way.

Most front wheel drive "performance" cars have equal length CV axles to eliminate the issue.

If you had a failure of a wheel motor, you could just reduce the max power you allowed the other wheels to make so the car was drivable, and not too unwieldy during acceleration.

I agree that wheel motors are too much unsprung weight, and impractical for a number of other reasons though too. I worked on a diesel hybrid project that had large rare earth magnets mounted behind the flywheel, and that thing was downright dangerous to work on. Pulling tools right off the bench, and out of your hands. If you held on to them, you learned very quickly that it was a bad idea! Blood blisters galore! The amount of force in a large ring of rare earth magnets is incredible. We had to be very careful assembling it because if it got away from you, someone was getting hurt! You could stand them on edge, and feel them trying to jump off the wood cart and smash your tool box 4 feet away. Walk by an I beam in the shop, and it would leap right off the cart. It then took a small army with non-metallic pry tools to get it off the beam.

Not something you want to work on in the driveway! You don't just put it back together like installing a brake drum.

Cheers!

The cheap brushless motors used in fans are switched by the magnetic field of the commutator, so putting more current to them will cause them to reach a higher peak voltage in the windings, and spin faster. They are very much like a DC brushed motor in that respect.

The larger higher powered motors are synchronous to the field applied to the windings, and putting more current to them will produce more torque, but the RPM is dependent on the frequency being sent by the drive electronics. If the frequency does not change, the RPM will not change either (besides perhaps 1-2% less slip).

If the motor has position feedback, you can use the encoder to tell the drive when to switch the field based on the position of the armature. In this mode, the large motor, will behave much like the small fan, or a DC motor, and vary the frequency, and resulting torque according to the power being sent to the armature, and the load on the output shaft. The RPM is simply the result.

There are also hybrid modes that allow for keeping very tight control on RPM, while allowing you to adjust the torque output for applications such as tension control, where you want one motor to pull something at the same speed as another motor, but want to keep a certain amount of slack or tension between them.

Example: unwinding a roll of paper, cutting it to width, and rewinding it. The drives keep the outer surface speeds of the two rolls matched as they change diameter, and keep perfect tension on the paper through the change in torque due to the changing diameters so the slitting operation works properly.

There are so many ways to make a motor turn, you can get exactly the properties you want from it.

My ramblings were only about the synchronization of motors.

I'd agree on the differential being simpler (although not the modern computer controlled torque splitting design) but I'd also expect Tesla to have some top notch motor controls.

It's funny, I've been sent in to fix problems with our control systems to find the only problem to be a multi million dollar machine running for 2+ years without maintenance. I've often asked the plant managers if they'd treat their cars like that:) Production lines are there to make money, and shutting them down for maintenance (for some people) doesn't seem to make sense. They just run them, till they won't run anymore, then blame the electronics because the drive has a fault, but the drive is only faulted because it is trying to turn a gearbox that has gear teeth floating around in (what's left of) the gear lube.

When I was 17 I built a go-kart with a snowmobile engine, and a hydraulic (swash plate) transmission, ooohhh how I wish I could get one in my car... Lots of maintenance, if you consider twisted axles maintenance, which I soon did;)

I've seen lots of people struggle with their hydrostatic lawn mowers though, and we had a forklift with a hydrostatic transmission that has claimed it's fair share of walls too:) although Case should never have put the shifter pedal where the creeper pedal is on every other fork lift in the world...

Cheers!

Then how do all of the millions of CD and DVD players out there manage to properly play the discs, or VCRs play tapes without the TV losing sync?

Matching motor speeds is easy, even without encoder feedback. If a motor is turned at a different speed than it is driven it distorts the waveform going to the motor. Modern drive electronics can sense that, and adjust accordingly.

I've worked on machines that produce fabrics at 10 - 15 feet per second, and they contain multiple motors that are perfectly synchronized. If not, you would quickly have piles of fabric on the floor, or huge gobs of fabric getting wound up in the various stages of the machine. Getting them all tuned so they change speed at the same time takes a little bit of know how, but once they are properly set, they run trouble free.

Modern control systems are that good.

I've seen systems demoed with motors that have large triangular, square, and pentagon shaped metal plates mounted on them with slots cut in them barely wider than the plates. They start and stop so the plates can pass through the slots in perfect synchronization. You watch hypnotized as the different sided plates ratchet through each other at about 10 RPM, then the thing ramps up to a blur, and you watch in amazement as the other half of your brain tells you to run like hell in case one of those plates misses the slot, and the whole thing goes BAM, and comes flying apart.

Mitsubishi had a multi-master synchronized motor demo with some small servo motors mounted facing shaft to shaft about 3 inches apart driving parallel metal discs with pieces of lead from a mechanical pencil stuck through tiny holes in both of them. They had little levers mounted above the discs so you could push down on them to slow down or stop the discs. The goal was to try and get them out of synch enough to get the pencil lead to break while they went through a little cycle of ramping from about 50 to 1000 RPM. If you broke the lead, you got a real nice Mitsubishi mechanical pencil. I didn't see anyone manage to get one though.

Trade show demos are the coolest:)

I'd imagine you would have to allow them to NOT be in synch enough to go over bumps without creating additional jerkyness in the ride.

Cheers!

(&BuckFeta)

Where I used to work had a policy like that, and you are right, the number of post-it notes with !t$Feb2014 or similar you could find stuck around was incredible.

Sounds like they need a little piece of duct (500 MPH) tape to put over the vent!

I have had that same thought. I'm sure ATM's could record the numbers, as well as the counting machines that are used when you bring in lots of bills to the bank.

My old bank put in an automated counter that dispensed your with withdrawal to the teller, and it didn't give me the correct amount and the cashier called in back and they verified the transaction and gave me my missing money.

I asked her previously why they didn't count the money back when they gave it to me out of the machine, and she said they didn't have to anymore.

They didn't have to come count what was left in the machine, so they must have reviewed what went out to me and counted every bill it dispensed to find out. The part of the machine that dispensed the money thought it did the right thing, so there had to be another way for them to remotely verify my transaction that was independent from the counter mechanism. What better way than to independently take a picture or record the serial numbers of each bill dispensed. With how terrible the BETA site is, I mean after what we've learned from Edward Snowden, just imagine what that system is all connected to!

I'm sure there's a list of bills that are known to still exist from a time before they could record everything that get heavily scrutinized when they finally show back up at the bank. Who had these and how did they get them, because there's 99999 more of those $100 bills have been hiding (likely in sequential order) somewhere for 20+ years.

sorry replying from my phone...

" But the latter is because of the former, isn't it? It's easy because you can operate at the abstraction level of the problem instead of having to deal with low-level implementation details."

I agree.

" Does it really matter all that much that people do already know it? It's not exactly my area of epertise, but in my world, the underlying concepts are far more important than the specific language you are using. If you do know what classes, closures, pointers, references, higher order functions, ... are and how to apply them to solve problems, you just pick up a new language that has those features if needed."

Most of the people who they had using Simulink very successfully, would never be able to code in any low level language. Pointers would kill them.

" But revision control by changing file names? At least in the general software world, that's close to a reason for being fired :-)"

The controls group managed releasing code, and they used a VCS (Subversion I believe) When doing development, they would get the latest version of production code:
Example:
2014_prod_V8_SCI_014.XXX
and make it:
2014_dev_V8_SCI_014_Project#_New_Knock_StrategyX_Your Name_Today.XXX
That would be sent to the engine guys and used for development, and when they were happy with it, they sent it back to the controls group who checked back into VCS and possibly merged it into the production code.

We would make 3 or 4 versions on the dyno, and take them to the water to test. The test data would reflect the name, and all the versions would be kept in the VCS to recreate the test.
Meetings were held to review the data, and a choice was made as to which version would get merged into the production code and when.

Many times 5 or 6 different sub-projects would contribute changes to a final new model engine, so one group would add cooling system updates, another base engine control updates, another knock system updates, and all of these little changes get merged back into the production code by the controls group and that then gets tested on endurance and verified against the data from the original tests.

With anybody and everybody making code, you had to have a way to identify what was what, and having some of the info in the filename made sense. The projects were all tracked in Oracle, and Teamcenter, so finding the details of a test by the project number was easy. Having 100 different versions of code floating around with the same filename would be crazy.

There was a final build script for production code that built every version for every engine (50 or so V4, V6, I6, V8, 2 stroke, 4 stroke, Supercharged, turbocharged, catalyst, Direct Injected,) at once, and then those were distributed to the various teams for use in production. That way bug fixes, and updates made it to every version they made.

Cheers

Have you looked at:
www.mathworks.com/products/hdl-coder/

From the above link:

HDL Coder generates portable, synthesizable Verilog and VHDL code from MATLAB functions, Simulink models, and Stateflow charts. The generated HDL code can be used for FPGA programming or ASIC prototyping and design.

HDL Coder provides a workflow advisor that automates the programming of Xilinx and Altera FPGAs. You can control HDL architecture and implementation, highlight critical paths, and generate hardware resource utilization estimates. HDL Coder provides traceability between your Simulink model and the generated Verilog and VHDL code, enabling code verification for high-integrity applications adhering to DO-254 and other standards.

Just curious if it works or not.