FSIP working through issues

[BobBoyce]

I've been trying to help FSIP work through a series of issues with Curtis controllers that they have been selling. I discovered this when I ordered a 1206AC-5212 controller from them for someones 2Five. The controller that arrived was externally labelled as a 1206AC-5212, but internally contained the OS and VCL of a 1206AC-5202. FSIP put me in touch with the engineer that oversees the rebuilds of the controllers. Everyone in that department was under the impression that in the Curtis 1206AC series, early version controllers and late version controllers were identical. Nothing could be further from the truth...

In 2014, new OSs and VCLs were developed for the 2015 model year, to support new communications protocols that were added to the CAN Bus of Curtis controllers. Affected controllers are as follows...

Old Model # vs New Model # and affected E-Z-GO Models
--------------------------------------------------------
1206AC-5201 to 1206AC-5211 in the Fleet RXV
1206AC-5202 to 1206AC-5212 in the 2Five
1206AC-5203 to 1206AC-5213 in the Freedom RXV
1206AC-5350 to 1206AC-5360 in the 350 Amp RXV Upgrade

My first run-in with this change was when I had found an issue with the 1206AC-5212 controller in that 2015 2Five that had an internal conflict between the OS and VCL. That conflict was what was responsible for the erratic behavior that occured with all new 2015 2Fives. The solution was to replace all 1206AC-5212 controllers with 1206AC-5202 controllers, until the issue had been resolved by Curtis. Many 2015 2Fives had this done at the dealerships or factory. Apparently FSIP responded by programming all later model controllers with early model OS and VCL, while not knowing how this would affect future generations of the newer controllers.

Now FSIP has to work through their huge inventory of 1206AC-5XXX controllers and make sure that each one contains the correct OS and VCL that the particular model number is supposed to have. This could take months! In the meantime, the older controller model numbers are not affected. Only the mid-2014 and later controllers with the newer model numbers were. I fully trust that FSIP has the ability to work through this and will do the right thing.

They are still selling off 1206AC-5201 controllers on eBay for $495 + shipping. There is no core charge since they have so many hundreds of them in stock.

Bob

[scottyb]

What a mess, thanks for the info
Keep us posted.

[BobBoyce]

FSIP emailed me that the controller I ordered was on its way to me. They had given me an RMA to return the first one they sent that had the wrong OS/VCL. I guess they either loaded it with the right OS/VCL, or found one that was right in inventory. Here's hoping that it is right...

[nickdalzell1]

We have been having some quality control issues with them regarding RXV controls lately. Three times we have gotten a rebuilt back that appears to have 'silicone caulk' around the terminals where all the wires screw in. EVERY one of those controls with that tell-tale repair have lasted less than a few days and the car comes back completely dead. Send it back again, and they ship us one that looks as it should (no caulking compound) and it works fine.

It's like there are two different cooks in the kitchen there and we are playing Russian Roulette hoping we end up with the 'good' cook.

[BobBoyce]

Nick, that is a common problem with "remanufactured" Danaher controllers. The majority of RXV controller faults that we have seen on this forum have been caused by RXV owners trying to meter the voltages on the pins in the SOC meter socket and shorting the +48V wire to the +5V wire right next to it with the meter probe. Or cutting those wires to wire them to a digital battery meter and shorting the wires. A majority of the controllers have been Danaher. When these wires are shorted, the 48 volt pack voltage fries the 5 volt power supply in the controller. And that is the problem for FSIP...

When FSIP puts a controller on the bench, the method of powering the controller depends upon the controller. With Curtis, it is by powering up the controller as if it is in a cart, powered by a pack. When testing a Danaher, it is much easier to power it by supplying 5 volts to the logic section directly. While this allows the controller logic to operate, it does not test the functionality of the onboard 5V power supply that gets fried by shorting the 48V to the 5V externally. So we see a lot of "remanufactured" Danaher controllers get sent out by FSIP that still have fried 5V power supplies inside. They are a good company that stands behind their work, so they will make it right in the end.

[BobBoyce]

Now for an update on the Curtis 1206AC-5212 that I bought from FSIP...

The controller arrived, and all is good. They sent me the same controller back, and it had been reflashed as a 1206AC-5212. They also updated the OS/VCL to the latest version for the 5212.

I called FSIP and thanked them for getting back on track.

[nickdalzell1]

Actually, Bob, #3 was a Curtis. came back with caulk around the wire terminals, i uttered 'oh, this isn't good' and sure enough, it lasted exactly one day.

[BobBoyce]

Originally Posted by nickdalzell1

Actually, Bob, #3 was a Curtis. came back with caulk around the wire terminals, i uttered 'oh, this isn't good' and sure enough, it lasted exactly one day.

Yea that caulking means that FSIP had to open it to fix what was wrong with it. I've looked at the deep error logs in controllers from FSIP and can often use what I see to determine what had failed and had to be fixed. I don't think FSIP knows those logs exist or they might clear them prior to shipping controllers off. Of course when I check out a controller, I don't clear the deep error logs either. I leave them so future service guys can look them over, if they know how to access them. I only remove my entries from the access logs so there is no record of my programming station accessing the controller...

I was sent a Curtis RXV controller recently and the sender did not include a note to detail what he wanted to be done. In that sort of case, I put it on the bench, examined the deep error logs, and did simple diagnostics. I had found a grocery list of errors, with a couple of really serious ones. I reset the controller and the serious errors persisted (returned). I determined that it may have been due to memory corruption, so I reflashed the controller with the files from a compatible controller. After another reset, the controller returned no new unexpected errors. I sent a message about the issue with the results, and told him that I needed to run a working load test by installing it in my RXV. I was concerned with the prior serious errors that there may be hardware issues.

One of the persistent errors had been multiple Controller Overcurrent errors combined with Undervolt Cutback errors at the same time, which usually indicates bad FETs in the 3 phase output to the motor. That error had cleared after the reflash, so I was hopeful. But during testing in the cart, the controller did not react to the go pedal. So that indicated a hardware failure persisted that was not showing up in simple diagnostics. I am unwilling to open a controller when it has a serious issue like that, so I recommended that he send it to FSIP. I'll be sending that controller back today. There is no sense in doing performance reprogramming to a controller that does not function properly.

[Pw8961]

Bob, thanks for all the info..
I have learned a lot..
Quick question:
I bought 2017 2five with bad 1206AC-5202 5.0 (water damage)
Should I replace with the same one ,or I have other options?
If so, which one you recommend ( preferred with no need to programming, if possible)

Do I need a controller resistor? It came without it.
Thanks .