Tesla Large Drive Unit Support Thread

[retrEVnoc]

Questions:

How to calibrate accelerator pedal when potnom shows no values? Using a prius pedal, should work... I get changing values on the other pot parameters when the accel pedal is pressed/released.

How does the logic board avoid overcharging batteries when coasting down a long hill? in scenario where batteries reach full charge and vehicle continues going down hill..

Can anyone describe the difference between the encoder wires that plug in to the outside of the motor, and the wires that go between inverter and motor inside the unit?

I'm having the TMPHSMAX error as well.. So I should pull the "built and tested" logic board i purchased from EVBMW and check it for errors is ultimately what wigman is saying?

I'm not able to see the gauges or the 'Messages' like on the screenshots wigman is posting; i'm connecting to board wifi using windows 10 and chrome browser. anyone else having this issue?

[cloudy]

Maybe can help on two points...

potnom I think is a calculated value after derate/maximums/current limit etc, use pot/pot2 to calculate your min/max values

I think the TMPHSMAX issue is a software one rather than hardware. Perhaps someone with a working LDU board can confirm expected behaviour (and see my posts in the small drive unit thread for context)

[wigman]

The throttle programming procedure documented is a little misleading. You don’t look at potnom to do it.

You look at pot in the spot value menu when the pedal is at resting position for the potmin number, then push the pedal and hold on full throttle and refresh the web interface to get the potmax reading.

In the parameter section of the web interface, use these two numbers for potmin and potmax and flash the board with the new values. This saves your expected min and max of the pedal you are using. The sweep is then averaged by the logic.

To get the graphs or gauges you have to select L next to the spot value you want to observe.
Then under spot values you press show gauges and that will bring up a new window with a gauge for each parameter selected. If you want to show them on a running graph, go down to plot and a graph will appear at the bottom of the screen.

[Jack Bauer]

There is indeed an error in the throttle cal procedure. I have created an open task for this to be corrected :
viewtopic.php?f=18&t=672

Regarding the temp sensor problem it is looking like a software issue. I have asked Johannes to check if anything changed in the latest firmware and created an open task for this to be tested by someone running an older version :
viewtopic.php?f=18&t=673

[Jack Bauer]

Just to address the comment " So I should pull the "built and tested" logic board i purchased from EVBMW and check it for errors is ultimately what wigman is saying?"

For 3 years now I have designed , innovated and tested as much as possible for one person on a very limited budget all the while looking for ways to make the boards more accessible (ie cheaper) for end users. Any mistakes I make along the way are aired out in public for all to see and hopefully learn from. Wigman has a broken solder joint (leaving out the possibly software related temp sensor problem for now) and he found this by his own actions. My fault? quite possibly. I do test the current sensors as part of the procedure and would have noticed this problem. And yes I do hand solder on the connectors and yes most likely the pin in question didn't get enough solder. The reason I have stood off here and will continue to do so where possible is twofold. YOU as the user need to be able to find and repair basic problems when I'm not around. What happens in 5 years if Wigman or someone else has another broken solder joint and I'm chilling on a beach having retired on the massive profits I make on these boards? The answer is community knowledge that gets passed along. Just like knowledge of ice cars.

So, is "built and tested" perfect? of course not. It's "built and tested" to the best of my ability. Not good enough ? then you are free to download the source , or indeed send the files to jlcpcb yourself, and do better. In fact I encourage YOU to do better than me. At least 50% of my sales are to the USA. Why not setup a US source for these boards? with support. I won't stop you. I'm too busy with the Model 3 and toyota stuff.

[P.S.Mangelsdorf]

Questions:

How does the logic board avoid overcharging batteries when coasting down a long hill? in scenario where batteries reach full charge and vehicle continues going down hill..

Because of conservation of energy, this can only occur if you started with a full pack at a significantly higher elevation than your destination. i.e. you live at the top of a big hill. In that case, most people set the charger to only charge the pack part way. In OEM EV's there is a setting for that exact circumstance.

[P.S.Mangelsdorf]

The throttle programming procedure documented is a little misleading. You don’t look at potnom to do it.

You look at pot in the spot value menu when the pedal is at resting position for the potmin number, then push the pedal and hold on full throttle and refresh the web interface to get the potmax reading.

In the parameter section of the web interface, use these two numbers for potmin and potmax and flash the board with the new values. This saves your expected min and max of the pedal you are using. The sweep is then averaged by the logic.

To get the graphs or gauges you have to select L next to the spot value you want to observe.
Then under spot values you press show gauges and that will bring up a new window with a gauge for each parameter selected. If you want to show them on a running graph, go down to plot and a graph will appear at the bottom of the screen.

There is indeed an error in the throttle cal procedure. I have created an open task for this to be corrected

Damien is wigman's procedure correct? If so I will add it to the wiki troubleshooting page.

[Jack Bauer]

Yes its spot on.

[P.S.Mangelsdorf]

Yes its spot on.

Added to the wiki under Tesla FAQ.

FYI, I have added a Trouble Shooting and an FYI page to the Tesla section. FAQ is for general questions and set up procedures, Trouble Shooting is tracking down/fixing issues. If anyone has a better idea on how that should be split up, feel free to edit it.

FAQ: https://openinverter.org/wiki/Setup_FAQ

Trouble Shooting: https://openinverter.org/wiki/Trouble_Shooting

[Jack Bauer]

Excellent. Thank you very much for that.

[P.S.Mangelsdorf]

Excellent. Thank you very much for that.

Not a problem, most is just copied from forum answers.

Trying to be what help I can until I actually get a drive unit in. This virus is screwing with my progress.

[retrEVnoc]

Questions:

How does the logic board avoid overcharging batteries when coasting down a long hill? in scenario where batteries reach full charge and vehicle continues going down hill..

Because of conservation of energy, this can only occur if you started with a full pack at a significantly higher elevation than your destination. i.e. you live at the top of a big hill. In that case, most people set the charger to only charge the pack part way. In OEM EV's there is a setting for that exact circumstance.

Driving from Reno/Tahoe to CA coast (descending the sierra nevada), driving in to Denver from the west (descending the rockies), driving from eastern to western Oregon (descending the cascades) are real scenarios with 50-100+ mile descents.

If you crest a mtn pass at say 75% SOC, you could easily reach your 100% threshold, whatever that may be, while still descending the other side of the pass. Understanding when there is risk of this happening is helpful, yes, but knowing the logic board/software manages this scenario appropriately is much better, considering that overcharging via regen while driving could be very dangerous.

[retrEVnoc]

There is indeed an error in the throttle cal procedure. I have created an open task for this to be corrected :
viewtopic.php?f=18&t=672

Regarding the temp sensor problem it is looking like a software issue. I have asked Johannes to check if anything changed in the latest firmware and created an open task for this to be tested by someone running an older version :
viewtopic.php?f=18&t=673

Thanks wigman and Damien, I suspected this but wanted to confirm before accidentally messing something up.. I will try and figure out how to change the calibration document and repost..

[P.S.Mangelsdorf]

Driving from Reno/Tahoe to CA coast (descending the sierra nevada), driving in to Denver from the west (descending the rockies), driving from eastern to western Oregon (descending the cascades) are real scenarios with 50-100+ mile descents.

If you crest a mtn pass at say 75% SOC, you could easily reach your 100% threshold, whatever that may be, while still descending the other side of the pass. Understanding when there is risk of this happening is helpful, yes, but knowing the logic board/software manages this scenario appropriately is much better, considering that overcharging via regen while driving could be very dangerous.

Certainly there are circumstances when you are starting significantly higher than your destination that this can occur, as I said. How much is "significantly higher" depends on your vehicle's drag coefficient. A car that's got the aero of a brick will need to start at a much higher elevation compared to destination than a slippery car will to have the regen exceed the pack capacity.

There is a parameter bmslimlow that provides regen limit on BMS over voltage. I believe the bms needs to communicate to the drive unit over CAN but I don't have experience with it.

Anyone that has set this up have input?

[retrEVnoc]

Just to address the comment " So I should pull the "built and tested" logic board i purchased from EVBMW and check it for errors is ultimately what wigman is saying?"

For 3 years now I have designed , innovated and tested as much as possible for one person on a very limited budget all the while looking for ways to make the boards more accessible (ie cheaper) for end users. Any mistakes I make along the way are aired out in public for all to see and hopefully learn from. Wigman has a broken solder joint (leaving out the possibly software related temp sensor problem for now) and he found this by his own actions. My fault? quite possibly. I do test the current sensors as part of the procedure and would have noticed this problem. And yes I do hand solder on the connectors and yes most likely the pin in question didn't get enough solder. The reason I have stood off here and will continue to do so where possible is twofold. YOU as the user need to be able to find and repair basic problems when I'm not around. What happens in 5 years if Wigman or someone else has another broken solder joint and I'm chilling on a beach having retired on the massive profits I make on these boards? The answer is community knowledge that gets passed along. Just like knowledge of ice cars.

So, is "built and tested" perfect? of course not. It's "built and tested" to the best of my ability. Not good enough ? then you are free to download the source , or indeed send the files to jlcpcb yourself, and do better. In fact I encourage YOU to do better than me. At least 50% of my sales are to the USA. Why not setup a US source for these boards? with support. I won't stop you. I'm too busy with the Model 3 and toyota stuff.

As someone with little electronics/software experience, I'm in awe of your accomplishments and so appreciative of what you do and your commitment to open source! One of my goals from the beginning with my EV conversion project is to learn more in these areas, and I already am learning a lot. As a n00b, I don't have the troubleshooting expertise to know when to look for hardware issues vs. software issues, so asking, and learning that while one person with similar error had a hardware error but my issue may well be a software issue is extremely helpful. I'm glad to hear the TMPHSMAX error is likely a software issue and look forward to updates on this. I will continue tinkering, and continue asking many questions so that I don't inadvertently fry my inverter. I'm happy to support the work that you do by buying built and tested boards, and I will likely continue to do so. Thanks and keep up the great work.

[wigman]

I have some updates-

1. I soldered the current input 5V connection and now have equal voltage on all test points and no more maxcurrent stop code.

2. I tested continuity between every pin on connector 10 and the corresponding devices on the schematic. No bad solder joints, everything checks out.

3. I tested voltage on the three pins 8, 16, 24 on connector 10. Those are the three temp inputs from each heatsink. Each gave a reading of 1.39VDC. Since each incoming voltage is equal I would assume they are giving the correct temperature signals so the toggling to a spike in temp reading causing the temp code is probably a software issue related to interpreting those temps.

4. I started the inverter with high voltage and without high voltage. In both scenarios a currentlimit derate code appears. Can we add this to the software checklist with the temp code? Does a different parameter that isn't ocurlim create the currentlimit code? If so what is it?

5. Attached is the max amps with the inverter running with and without high voltage. In the high voltage scenario I add throttle and get a max of 40 amps or so.

Hoping to get the software worked out so I can start the actual car install. Coding is out of my realm of knowledge so I can only help troubleshoot with runability tests if there are software updates to flash.

Thanks!

[retrEVnoc]

I have some updates-

1. I soldered the current input 5V connection and now have equal voltage on all test points and no more maxcurrent stop code.

2. I tested continuity between every pin on connector 10 and the corresponding devices on the schematic. No bad solder joints, everything checks out.

3. I tested voltage on the three pins 8, 16, 24 on connector 10. Those are the three temp inputs from each heatsink. Each gave a reading of 1.39VDC. Since each incoming voltage is equal I would assume they are giving the correct temperature signals so the toggling to a spike in temp reading causing the temp code is probably a software issue related to interpreting those temps.

4. I started the inverter with high voltage and without high voltage. In both scenarios a currentlimit derate code appears. Can we add this to the software checklist with the temp code? Does a different parameter that isn't ocurlim create the currentlimit code? If so what is it?

5. Attached is the max amps with the inverter running with and without high voltage. In the high voltage scenario I add throttle and get a max of 40 amps or so.

Hoping to get the software worked out so I can start the actual car install. Coding is out of my realm of knowledge so I can only help troubleshoot with runability tests if there are software updates to flash.

Thanks!

wigman, it seems johannes did find and correct something in the code; he posted a new draft of the firmware for testing in the Open Tasks thread that damien linked in earlier post.

[wigman]

I got it and tried it. Below is what I posted in that thread. I'll add it here for LDU users following this thread-


I just tested this verison-

1. The temp codes are gone and the graph reading looks normal!

2. One spot value changed from OK to ERROR- din_mprot. I tried my starter switch and even though I could see the signal incoming on a graph, the control board would not close the main relay. I went back to my previous version and verified that spot value was OK and my relay was still in working order. Something about the new code changed this.


Also, I posted in the other thread, but I was previously having currentlimit derate codes even when no HV was connected. Can I put in a task request to look at that issue as well. I can't tell if the new version has it or not because the relay won't close so it never goes into run mode.

[wigman]

I did some testing today and got some strange results.

Since I've been trying different software versions and different parameters, I decided to start from scratch and get a baseline for comparison.

The version my board came with was 4.71. With the stock parameters the motor would not spin. With Jon Volk's parameters it would spin in version 4.71.

I compared the stock parameters and Volk's and went through each parameter until I could get the motor to spin. The combination of Volk's fweak fconst udcnom fslipmin and fmin values allowed the motor to spin. Everything else I kept with the stock settings except for udcmin and udcswitch (to match my test battery- 70V chevy volt battery) and my accelerator potmin value.

I tested each version of the software with my setup to compare and contrast the differences.

V4.56- The first time I loaded this software I got the motor to spin. udcnom had to be 80. Error codes were PMWSTUCK CURRENTLIMIT ENCODER

V4.71- Spins the motor when udcnom is 390. Error codes were PMWSTUCK TMPHMAx CURRENTLIMIT ENCODER

V4.76- Spins the motor udcnom 390. Error codes were PMWSTUCK TMPHMAX CURRENTLIMIT ENCODER

V4.79 (the test version on the MUX temp thread)- Spins the motor. udcnom 390. Error codes were PMWSTUCK CURRENTLIMIT ENCODER

I should mention that when I say the motor spins, it spins when adding throttle. When throttle is let go, the motor continues to spin and very slowly winds down, takes a minute or so to stop. If fslipmin is decreased then the motor will decelerate slightly slower, but if it's too low the motor won't start. If it's too high (at the stock value) it will actually cause the motor to run away slowly increasing speed with the pedal at potmin.

The first time I did these tests, V4.79 started spinning the motor like it should be spinning. It ramped up nicely with throttle and as soon as throttle was taken away the motor pulled back to a stop after a couple seconds in a smooth fashion.

I thought I had solved most of my issues with V4.79 when the motor started to spin correctly. I turned the ignition on and off and tried this version a few times and every time it worked. I went to clean up my shop from another job and came back to the setup 5 minutes later to show someone the progress of the correctly spinning motor. When I flipped the start signal nothing happened. The contactor did not close like my attempts previous to today. I switched to all the other versions. 4.56 would not close the contactor either. 4.71 and 4.76 would close the contactor and spin the motor but the motor would have the original extremely long lag after throttle to get back to stop the way it was previously. Nothing changed in those 5 minutes besides having the ignition turned off. Once again, I can graph my start signal and see it come through but the board will not activate run mode.

Now I'm stumped, why would a correctly running motor not even go into run mode just from sitting? I originally thought this was a software issue but the different versions seem to always act the same. I'm back to thinking maybe it's a partially bad board component or intermittent connection on the board.

As usual, any help is appreciated.

[jon volk]

Can you post the full parameter file? It doesnt seem like any of those errors would cause a hard stop.

[wigman]

Here are the last set of parameters I tried. They worked in all versions the first test and ran the motor correctly in V4.79. Now the main contactor won't close in 4.79 and 4.56, the motor will spin in 4.76 and 4.71 but the throttle hangs on even when the pedal is released.

[jon volk]

FIrst thing that jumps out is the encoder type should be set to 1, not 0.

Try that first.

Also, try bumping fmin to .6 or .8

[jon volk]

Also, Im not sure if anything changed, but il1 and il2 gain show as -1 in the parameter files located in Damiens Github. Yours are at 4.68. My values are hidden since I got rid of anything that might accidentally get changed.

[wigman]

Gotcha. I will try to change the encoder. I have written down that you had it at 0 and my built board came with 0, that's why I didn't try changing it yet.

I did play with fmin, at the value the board came with, it would not start the motor. I'll try it with slightly higher settings.

I see what you are referencing in damien's file for ILgain. My board came with 4.68 value.

Also, just out of curiosity, when I upload your or other parameter files does that contain every parameter or just some? If only some, that could be the reason the board maintained some stock values, though you would think a built board for this application would have stock values to match the tesla platform.

I'll try these changes and report back.

[jon volk]

My parameters are missing a bunch that are flagged as hidden. If you only changed what I have in the wiki, you likely have a mix of defaults and Tesla parameters.

This should cover all of them I believe.
https://github.com/damienmaguire/Tesla- ... arams.json