My Duinomite Mega Canview V4 equivalent Project

Exactly. If you look at transaxle crosssection in the Prius Service Manual the oil pump drive shaft is directly
driven by input shaft from the ICE (you can also observe it at 7:36 of the video). So whenever ICE rotates
and only then oil pump is lubricating the transaxle - point.
Another question is why is ICE rotating - to apply torque to the wheels or charging HV battery (running), to
assist braking (?) or burn excessive charge of the HV battery (spinning - no fuel).
And of course ICE is running only in one direction - reverse is done by MG2 alone?

Jacek.

 

I don't know if MG2 alone does reverse - or whether MG1 is involved as well. They certainly never run the ICE backwards (impossible!) - but the ICE can be running with the wheels spinning backwards (checkout the gadget above and you can drag the sliders around to show you that situation). Also, it's possible that all three gears can be rotating in the same direction - I'm not sure if that happens? It probably does.

Now, I wonder what would happen if you span the engine backwards (no fuel and no spark)? I'm just curious - don't try this at home folks! I don't think there a fundamental mechanical reason you can't. I don't think it would gain you anything useful either! Just pure curiosity!

One final question - does anyone know if the Prius does something "special" with valve timing when spinning the engine without fuel or spark? E.g. can it open intake and exhaust valves at the same time and just suck air in and blow it back out without any compression? I'm assuming that it would require far less energy to spin the ICE if you could do that.

 

Yup, this is fundamental to the motors. As they spin faster, they generate "back EMF" or voltage. This is essentially subtracted from the applied voltage, reducing output power. This is part of the function of the "boost" converter in the inverter, to extend the useful power range.

Counter-electromotive force - Wikipedia, the free encyclopedia

Starting on page 65 of the report below you can see the MG2 output vs. rpm curve at various voltages for the inverter/MG2 combo. The efficiency data is interesting, but for this purpose the data of interest is the top "max output" curve." Note that the natural operation of the boost converter has been disabled, and they are feeding the output stages directly with different dc voltages. Following that curve, you can see how power output begins to fall as you go higher in rpms. You can also see how this curve pushes to the right allowing more power output at higher rpms as the applied voltage is increased by comparing the 225V, 500V and 650V curves. You can also see from the efficiency contours that back EMF does not degrade efficiency, it just limits power output.

http://ecee.colorado.edu/~ecen5017/notes/OakRidge_2010Prius.pdf

The faster you go, the more power you need to overcome wind resistance. The faster the motor spins, the less power it puts out. Eventually those two things balance and you reach the max speed (for a given slope/wind etc). This is one reason why many EV conversions still use the mechanical transmission from the donor vehicle to allow you to drop rpms at highway speeds to preserve hill climbing / passing power and/or extend the maximum speed possible.

Rob

 

Well, it's not just a factor of back EMF - it's also a factor of the amount of work being asked. If it was just back EMF then the no load RPM would be the same as the loaded RPM. Put your Prius up on blocks and floor the accelerator in EV only mode and the speedo will read well above 70mph.

The other approach (versus a multiple ratio transmission) to widening the speed range for an electric motor is field-weakening (less magnetic field = less back EMF). I haven't looked at that report (and when you mentioned page 65 it kind of made me think I won't be reading it in detail in the next 5 minutes!) - do you know if the Prius implements any form of field-weakening?

 

Ooh - this is great! Looks like I will be reading this in detail.

They also have one for the Gen 2 Prius:

http://ecee.colorado.edu/~ecen5017/notes/OakRidge_2004Prius.pdf

Yay! Great find Rob.

 

Agreed, the load matters a lot. The point I think I was trying to make is that for any rpm above the "knee" the back EMF limits the max electric power the motor will draw, and consequently limits the max torque output of the motor. That only really matters if you have sufficient load to need max torque output, ie max EV driving speed or EV gradability.

Not that I'm aware of, though I had thought field weakening was more commonly used in wound motors than in permanent magnet motors like the Prius uses. We're definitely exceeding my limited understanding of electric motors though

These reports are definitely a lot of fun. Your tax dollars at work

Rob

 

not sure if i already posted this or anybody else

but when i drive in OOG mode and hit just 90kmph on the speedo i notice my car holding back/slowing down feels like something is breaking.
as soon i get at 89kpmh it go's away

not sure if any of you guys ever driven a car with a speed limiter on it or ever hit the rev limitir in a old fasion ice car, thats the same feeling.

 

Attached is a new version of the CAN commands. CAN TX is working - I've confirmed this on my bench setup which has the Atmel logging all bus traffic and the DuinoMite sending using CAN TX. If I send 10 messages I see all 10 show up in the log file.

However, I haven't managed to send a PID request and receive messages back. So, I'm obviously doing something wrong!

This is still considered a beta test release - but, AFAIK, everything is working. That's where testing comes in - let me know what's broken...

Note to self: If I'd set things up on the bench in the first place I could have released this about 1 month ago!

 

Update: I got the PID request working and can receive the primary frame (byte 0 = 0x10), but I can't get the remaining frames to transmit. However, this is with the bECU on the bench and it might just be the fact that the bECU isn't sending data because it's not attached to a pack...

So, I'll attach stuff to the car sometime this weekend & see what transpires...

 

No Thx
Always like to pester.

-Tapatalk

 

Update 2: I got the PID request and retrieve all frames to work. Nothing to do with being on the bench - I was just sending the wrong response.

Here's the output from the attached test program (becu.bas) on the test bench (becu is not hooked to a pack)

Code:

CAN Config
==========
 
online = 1
buffer size = 176
speed = 500000
channel flags = 0X3
Channels in use: 0 1
End of CAN Config
 
q:quit, t:0xCE, u:0xCF, v:0xD0 send pid to 7E3
SENT PID CE TO 7E3
SENT 0x30 TO 7E3
3457: 7EB :  8 : 10 26 61 CE 6E CE 20 80
3466: 7EB :  8 : 21 00 80 00 80 00 80 00
3474: 7EB :  8 : 22 80 00 80 00 80 00 80
3483: 7EB :  8 : 23 00 80 00 80 00 80 00
3492: 7EB :  8 : 24 80 00 80 00 80 00 00
3501: 7EB :  8 : 25 80 00 00 11 00 00 00
SENT PID CF TO 7E3
SENT 0x30 TO 7E3
6605: 7EB :  8 : 10 17 61 CF 66 38 80 C0
6613: 7EB :  8 : 21 7C 84 00 08 06 00 66
6622: 7EB :  8 : 22 38 66 38 66 38 00 80
6631: 7EB :  8 : 23 00 00 11 00 00 00 00
SENT PID D0 TO 7E3
SENT 0x30 TO 7E3
10455: 7EB :  8 : 10 24 61 D0 0E 00 00 00
10464: 7EB :  8 : 21 00 00 00 00 00 80 00
10473: 7EB :  8 : 22 00 80 00 00 13 13 13
10482: 7EB :  8 : 23 13 13 13 13 13 13 13
10493: 7EB :  8 : 24 13 13 13 13 00 80 00
10503: 7EB :  8 : 25 00 11 00 00 00 00 00

The first column is the Timer command output (msec since last reset). However, because of the way I structured the code it's misleading - this is actually the time it takes to empty the buffer - not how long it takes to read the PID frames. However, it appears "instantaneous", in other words, when you press a key there's no noticeable wait before the display pops up.

Note: drop the ".txt" from the filename when running on the DM - board only allows uploads of certain file types.

 

The way I have the CAN configuration setup this won't work. I set up the receive channel to filter for replies for the specific response ID. So, if you change the txID you'll need to either (a) change the filter on the RX channel to receive all messages and pick out what you want or (b) you'll need to also change the filter on RX if you change txID.

(a) should work but it puts us back to a less efficient way of interacting with CAN
(b) may work but I'm not sure my CAN commands will handle it properly or not. They're certainly not optimized for this - I'll add an easy way to change a channel filter to beta 3.

Did you change the filter on channel 1 just to accept all messages?

 

The way you're doing it is probably the best approach. How many separate channels is your CANVIEW app using?

DROID RAZR ? 2