Compact Field Oriented Controller, ASI + Grin, limited run

MrDude_1 said:
If anyone here is capable of and willing to do a post mortem on my dead phaserunner so we can tell why it failed, I would be willing to ship it. Im kind of curious.

I'm curious as well. I've been running three Phaserunners (two on non ebike projects) for nearly a year now, and just haven't had any hardware problems with any of them (yet!?!). I've autopsied several Infineon type controllers however, and have found that failures, in my environment at least, are caused by human errors. My only reservation for volunteering to dig into your Phaserunner is that if it's the model that's completely 'potted' (embedded in epoxy), I'm not even sure that it's physically *possible* to get down to the components or the circuit board. This is one of those "What would Justin do?" kinds of issues. His previous pronouncements on this issue -- and I may not be presenting his views accurately -- is that the potting adds more reliability to the device than is offset by giving up the ability to repair it if and when it fails. Of course, we're looking for the failure cause here, not necessarily any kind of repair. With this in mind, I'd be willing to give it a shot.
 
Has anyone else had trouble with the new v2 Phaserunner? I've had two die within two hundred miles. The unit passes power to the Cycle Analyst but the status light doesn't come on it, doesn't send power to the motor, and I can't access it via the com port. I'm using a Crystalyte 3080 and a 52v battery from Em3EV. I wonder if there is a problem with the new model. Very strange to have both die in the exact same manner so quickly. Still waiting on Grin to get back to me on the second RMA. For the brief intervals it does work, the controller is awesome. I just hope they get the issue sorted out. I love how quiet the system is and the variable regen.
 
rowbiker said:
My only reservation for volunteering to dig into your Phaserunner is that if it's the model that's completely 'potted' (embedded in epoxy), I'm not even sure that it's physically *possible* to get down to the components or the circuit board.
It's possible to dissolve epoxy--you just have to find out which kind Grin used to pot that unit. If Grin hasn't already tried stuff to dissolve it, you can contact the company that made that epoxy and see what they recommend. Keep in mind it is possible that whatever dissolves that epoxy might also dissolve other plastics used on components of the controller.


Failing all that, you could try ATF, it's been used to dissolve some epoxies. No guarantees....
 
Good suggestion, amberwolf. For the purposes of doing an autopsy, damaging some of the parts may be acceptable, unless it prevents useful test results revealing the original failure of parts in the controller.

One thought I had is that the bottom (non-component side) of the controller, which faces the heat sink base, might be more accessible. If so, it might allow access to more 'test points' on the circuit board, which (assuming one had access to the schematic and knew what he was doing) might reveal the failure(s).
 
tomjasz said:
As i’m still learning about advanced controlers, the BAC800 and phaserunner. Can anyone help sort and compare the function of each? Advantage Grin?

I'm also interested in this. As I understand they are the same thing in different packages, or is the phaserunner running another firmware that enables it to be more customized?
 
MrDude_1 said:
with the software connected I could immediately see some faults.
Code:
Faults[0]: Controller over voltage
Faults[1]: Filtered phase over current
Faults[9]: Instantaneous phase over current
Faults[11]: Throttle voltage outside range
Warnings[7]: VdcLowFLDBK
Warnings[8]: VdcHighFLDBK
Warnings[12]: HiSOCFLDBK


So, after more than one year with my PhaseRunner I also get some terrible faults, inhibiting me from riding my bike.

Code:
Faults[0]: Controller over voltage
Faults[2]: Bad current sensor calibration
Faults[9]: Instantaneous phase over current
Warnings[12]: HiSOCFLDBK


Only when I completely redo the Autotune, I can get the PhaseRunner to work again. Very irritating, and I have already ordered a new PhaseRunner. However, it would be great if anyone can give me some advice how to manage these faults.

My system: Front Grin-Through-Axle hubmotor, EM3EV 14S pack (58V HoC), CAv3, Throttle on CAv3, PhaseRunner initially connected with Hall sensors, but in the process of managing the faults now running without the Hall sensors connected.
 
justin_le said:
Also, please just leave the rated system voltage alone (at 48V) after you've done the autotune etc. it says so clearly in the manual and on the tooltips, there are lots of dependencies with other parameters that get affected and then clamped when you change this setting after the fact.

I just borrowed a friend's 72V battery and went to tweak the settings in my phaserunner, of course I didn't hover over any tooltips and cranked up the Rated system voltage up to 72V from 52V.

It was confusing why there was no wheel spin at all when I brought it outside for a test ride, luckily I had saved the previous settings in an xml file so I re-imported them and things were working again. I ended up figuring out by trial and error to just leave it and change the regen settings and max power etc.

I don't see any reference to leaving the System voltage alone in the Phaserunner manual in either the 1.0 or newer 2.0 manual pdf.. unless I missed it?

Could you add a note in there under section 4.2 about leaving the system voltage alone?

Thanks for the great product! :)
 
Hello, I'm looking for a controller that can let me handle the cutoff (the time for how long the motor temporary turns off) when I switch gears. What I'd like achieve is that the more power I'm squeezing out of the motor (the faster I'm going), the faster the gears get switched. My current motor (Bafang BBSHD) has the problem that there is just a default value set inside the controller for all gears and that is not configurable via software, while I'd like to link this "cutoff" time to both the speed and power so that I don't get sudden "strokes" while switching gear at high speeds.

Is this something already possible with current PR software? Do you think Justin would be available to add such feature? :roll:
 
racingame said:
Is this something already possible with current PR software? Do you think Justin would be available to add such feature? :roll:

Nope.
Nope.
The gear change feature is provided by the CA3 via a configurable fixed length minimum time ebrakes are applied. You can trigger it either by tapping the brakes or by installing a gear change detector that drives the CA ebrake input. You can use the brakes normally to stretch the brake application to be longer than this minimum for regular braking or slow-shift situations.

The automatic variable-length delay you describe is not available.
 
teklektik said:
racingame said:
Is this something already possible with current PR software? Do you think Justin would be available to add such feature? :roll:

Nope.
Nope.
The gear change feature is provided by the CA3 via a configurable fixed length minimum time ebrakes are applied. You can trigger it either by tapping the brakes or by installing a gear change detector that drives the CA ebrake input. You can use the brakes normally to stretch the brake application to be longer than this minimum for regular braking or slow-shift situations.

The automatic variable-length delay you describe is not available.

So, provided that I've already mounted a gearsensor on my bike, I can make its signal intercepted by CAv3, right? This signal is just a true/false thing or can actually bring data within it about what gear I have actually selected so that I can cutoff the motor by the amount of time I desire based on 1) what gear is selected and 2) what speed I'm going? Is this thing feasable for the features the CAv3 already provides? I need to make the cutoff time as short as possible for high gears, currently I'm really not satisfied by the amount of time it takes, since it's exactly the same one for every gear. I'm sure Bafang could have just added some extra parameters to his controller firmware and thus software interface to let you handle the time for each Assist Level and Gear selected, but they didn't.
 
This controller doesn't allow you to have 2-3 profiles like any bike controller out there? I couldn't find any options in the software.
 
racingame said:
This controller doesn't allow you to have 2-3 profiles like any bike controller out there? I couldn't find any options in the software.
Most common ebike controllers dont' have profiles either (most dont' even have software to program them at all--you buy them the way you want them and if they don't do what you want you either modify their hardwrae (if possible) or toss it and buy a new one that does it instead (possibly losing other features the old one had in the bargain).
 
All of them including this one can have profiles if you have a cycle analyst v3
 
Quick question on PR behaviour regen, h3540 and new em3ev 14s7p samsung 33g pack with bluetooth bms.

When I am braking from higher speed and regen climbs above 12A, I'm getting the following behaviour - does it sound like BMS or the PR I need to check?

1. Motor brakes as regen climbs
2. At >12A regen (I think), the power to the motor cuts out and no braking from the motor i.e. as though the controller is powered off
3. CAv3b13 is still powered up and volts display climbs to 60V and is steady, CA battery symbol goes to full capacity (its a 14s battery)
4. After slowing down, releasing the brakes and giving motor some power everything returns to normal

Throttle out is set to 0.1 for regen.
 
hjns said:
So, after more than one year with my PhaseRunner I also get some terrible faults, inhibiting me from riding my bike.
Code:
Faults[0]: Controller over voltage
Faults[2]: Bad current sensor calibration
Faults[9]: Instantaneous phase over current
Warnings[12]: HiSOCFLDBK
Only when I completely redo the Autotune, I can get the PhaseRunner to work again. Very irritating, and I have already ordered a new PhaseRunner. However, it would be great if anyone can give me some advice how to manage these faults.

Hi Henk, this is a bit troubling for sure. Can you tell me if the onset of these errors/warnings happened after you had been programming or connected the PR to a computer, or did it just suddenly go from working to having these errors (which are a sign of some parameter corruption)? Normally this would happen only if power was interrupted on the phaserunner while it was in the middle of having data saved to flash memory, so for instance if a BMS or power supply trips and shuts down during the autotune sequence.

In most cases you can restore normal operation just fine by following the tips here for reflashing all the deep settings to their defaults with level 3 access:
http://www.ebikes.ca/product-info/phaserunner.html#default-parameter-file

We are nearly ready to release a V1.0 of the phaserunner software suite which should hopefully make the overall communications more robust and also better deal with various idiosyncrasies that have been confusing people. For instance
Alan B said:
They should move the "system voltage" settings to an advanced tab. It is not something one changes lightly.

Has been done. We've also got it so that all the hall and phase reporting are in colours of Yellow, Green, and Blue, rather than UVW. And if there are hall failures during autotune it will tell you specifically which ones are and aren't toggling rather than always saying hall error.
 
Hello

I tried to install the phase runner with my leafmotor, it shows initially fault with hall sensor.

Then I tried autotune with 23 poles and the motor spin and stop and spin:
https://www.youtube.com/watch?v=1x2B-vZj8n8

On throttle it does the same thing....

Then it has this error "Fault 7: POST stating gating test."

Any idea what's wrong?

Thanks
 
Now it says 'motor not deteted' please ensure the 3 phases are connected to the motor and try again.

However the 3 phases are connected and the motor spin and stop during the static test

What's wrong?
 
Has been done. We've also got it so that all the hall and phase reporting are in colours of Yellow, Green, and Blue, rather than UVW. And if there are hall failures during autotune it will tell you specifically which ones are and aren't toggling rather than always saying hall error.

Whoa! This will be awesome in trying to troubleshoot why my Phaserunner can't read the halls in my Q100H.
 
OK everyone, we've finally ironed out what should be the last of the kinks in the V1.0 Phaserunner Software. The windows build is accessible from here
https://www.dropbox.com/s/df14ev8940az95l/Phase%20Runner%20Software%20v1.b3.exe?dl=0

We will have the MacOS and Linux release candidates available very soon too. On the surface this will look fairly similar to the previous Phaserunner 0.9X software, but there is a lot that is improved under the hood which we hope will smooth out the setup process.

First and foremost on these is that the communications behavior has been made much more rugged and tolerant of communication glitches while the device is hooked up. There are many additional bounds and sanity checks taking place during the autotune routines to ensure that the initial parameter inputs are sensible, and much more meaningful error messages when there are problems during the tune process.

PhaserunnerSW Main Screen.jpg

On the main screen, the only thing you'll really notice is that the rated system voltage is no longer present. We've moved this over to the advanced tab and added more clear language that in general there is never any need to change this from the default value of 48V. In its place, we've enabled a checkbox for the fault-tolerant hall feature, which allows the Phaserunner to continue running fine in sensored mode when one hall sensor stop working. It will also allow it to revert to sensorless mode if you power up the Phaserunner with the halls connected and then unplug them. However, if the phaserunner is powered on without halls attached, it won't automatically start in sensorless which is (admittedly) a bit silly.

PhaserunnerSW BaudRate.jpg

In the advanced tab, there is also a setting now (requiring level 3 access) to change the communication BAUD rate. This setting only kicks in after you have turned the Phaserunner off and on again. Once the phaserunner has been power cycled, then you'll need to change the software to run at this new Baud Rate by going to File->Preferences->Communication Speeds.

PhaserunnerSW ComSpeeds.jpg

In general there's no need to change things from 115KBaud, but there have been cases where people have managed to have eeprom corruption that reset their Phaserunner to 9600 baud and this gives the means to communicate with it and then revert things back to 115KBaud.

zro-1 said:
Has been done. We've also got it so that all the hall and phase reporting are in colours of Yellow, Green, and Blue, rather than UVW. And if there are hall failures during autotune it will tell you specifically which ones are and aren't toggling rather than always saying hall error.

Whoa! This will be awesome in trying to troubleshoot why my Phaserunner can't read the halls in my Q100H.

Yes, so in addition to the autotune process reporting which specific halls are not toggling, and whether they are stuck High or Low, there is also a preview of the 3 hall signals themselves in the dashboard view

PhaserunnerSW Hall Signals.jpg

This allows you to rotate the wheel by hand and watch the halls toggle. I'm really not sure why we didn't include this in the initial software spec since it's incredibly useful in any kind of hall troubleshooting.

The Graphing process also has a number of improvements. You'll see if that it plots the data at a faster rate and with smoother lines. But most importantly, it doesn't hang anymore during long plots if there is any communication glitch, and you can switch back to other tabs and then return to the dashboard tab and it will automatically resume graphing where it had previously left off. A dashed vertical line on the graph shows each time there was an interruption like this.

So please any active Phaserunner users who want to try this out and give us feedback let us know. We're especially keen for those who have struggled with occasional communication issues to try this release and see if it solves the problem. A number of those were MacOS users and we hope to post the B3 MAC version within the next couple days for you too.
 
Back
Top