ixxat USB-to-CAN compact & Sevcon DLD flashing

methods

1 GW
Joined
Aug 8, 2008
Messages
5,555
Location
Santa Cruz CA
Looking to share information around the following:

USB-to-CAN compact
1.01.0087.xxxxx
1.01.0088.xxxxx
AKA V1.5 and V1.6


Have tested compatibility around:
* Clone Boxes claiming compatibility
* USB-to-CAN V2 compact


Have found:
* Using the tools I have access to... that the V2 and Clones can brick (temporarily?) the Sevcon into a mode where it has a solid green LED with no flicker in a situation where you enter bootloader mode and attempt to flash the DLD. No CAN response. No CAN traffic. Pending testing.

EDIT: Testing has shown that the clone devices are compatible with both new and old versions of DVT. Clones some times lock up and require a USB physical disconnect cycle. Clone devices may run slower on bulk data movement than the original IXXAT (unconfirmed) or otherwise increase probability of Green-Bricking

* Clones and V2 work fine for flashing dcf files and basic monitoring (SO IF YOU ARE A HOBBYIST... CLONE OR V2 SHOULD MEET YOUR REQUIREMENTS IN MOST CASES)

* I need to be able to flash DLD files because I have advanced use cases


Key Words:
Zero Motorcycles, Sevcon Programming, Sevcon DVT, V1.5, V1.6, V2, ixxat, dld, dcf, V4, V3, V2, V1 drivers clone, ebay clone, Chinese clone


Research pointed to:
* 10uW lurk claimed a license key is required to unlock V2 compatibity with DVT. Unconfirmed. confirmed


Best Guess:
* V1 had undocumented capabilities that were exploited by Sevcon leading to legacy issues.
* Forcing old drivers (by cleaning all new ixxat drivers off of the machine) MAY allow one to emulate V1.5 / V1.6 capabilities - untested.
* Sevcon claims to be burdened by customer support issues... yet they have a clear path forward on eliminating said issues.
All incorrect

Options:
* If I had paid engineering hours I would either approach Sevcon with an argument to resolve or try every permutation of establishing a sustainable path forward as V1.5 and V1.6 have gone into extinction. It is not acceptable to need legacy parts to maintain systems in the field moving forward.

I had engineering hours and through epicly obnoxious trial and error with both old and new DVT versions we have achieved precision such that we can predict results.

-methods

New Terminology:
Black-Brick = Sevcon in Bootloader mode (solution, get out of bootloader)
Green-Brick = DLD disrupted during transfer, use command line to force into bootloader at next restart, flash DLD

Where black means no LED
Where Green means solid LED but controller does not work or respond
Where blinking LED means all good but with errors
Where solid LED with comms means you are golden
 
Update:

* I confirmed that there is in existence a version of DVT that will work with any dongle. I do not have this version (or key set) but I am told that Sevcon has addressed concerns. I have not approached Sevcon for access to this functionality.

Confirmed Sevcon has a release that is compatible with IXXAT Compact V2 for both DCF and DLF flashing. It is still buggy as hell but it is progress.

* It is my understanding that part of Sevcon's policy to ensure safety and reliability around their product is to hold tight control over who can modify DLD settings while exposing the DXF level to a wider audience.

Meh... Seems they are trying to control access by DVT version. A customer contacted me with a version that can flash... but is missing basic things like SEARCH... such that he can only modify exposed settings. Of course... one can ALWAYS directly modify the DCF if you are brave enough to get it right. I will do a tutorial on that soon.

* My experience has shown over the last 5 years that Sevcon has made it into many markets... and that although there are hardware variants... for the most part the DLD drive hardware compatibility while the DXF exposes fairly general settings. I have worked (in a professional capacity) with Sevcon's on Golf Carts and Motorcycles. I have seen a lot of them come off of forklifts and the like.

* Sevcon has been in the market long enough that we are seeing them pop up for sale. In order to utilize them cross functionally... we will eventually need the ability to load DLD files.

We have that functionality and so do you.

* UVW (hall only?) Sevcon's appear to be going for $200 on Ebay

Word is the UVW will ride fine but will take off rough - similar to how our ebikes take off... a little crunchy. Testing next week. The 75-3 has relatively few poles... which means a long distance between transitions... which must equate to a degradation in performance for direct drive applications. I am certain that for anything prop driven they will be perfect.

* Buyer Beware... but this one implies it has the more flexible interface for $200

* Confirmed - the lot of 500 are not Sin/Cos compatible... but that can be worked around. Sin/Cos is just one way to send feedback to the controller. For applications which are not motorcycles (like props in the air or water) it is much less important.

Two plug and play encoders are up for test that should screw in and supply UVW. Will test on dyno.

* TO DO: Breakdown the model number sequence to quickly identify Sevcon Hardware Base. Probably an easy task.
* Confirmed -part number ending in 3 for SIN/COS.
EDIT
Doctorbass said:
Also Are you sure the Sin/Cos and A/B sin/cos are only decoded by the last digit of the serial number?.. i tought it was the last 3.. like xxxxxxxx201 (A/B UVW) and xxxxxxxx203 (for the A/B UVW Sin/cos) ?

* From my experience at two retail companies it appears that there is about a 100% markup between Retail Consumer prices and folks buying in bulk.

* Thunder Struck is selling the old ixxatfor $850 that is capable of working on legacy software

Stop buying this. It is ruining the market for these controllers. Search Ebay and consider the clone which claims to be a drop in replacement for the ixxat. I will go back and re-test compatibility between the ixxat V2 and old DVT versions.

* Ok... off to other things. Stuck at home sick in bed. Kid brought home some sort of evil ear/nose/throat infection. Blew awesome dark brown bloody goop out of my nose this morning when I sneezed with a mouthful of cereal. Feel better now... but wondering if that was brain matter or some other useful/necessary part of my body that blew out.

Now on vacation in Washington for 3 weeks with a 2013 FX and a Gen 1 Prius.

-methods
 
Thanks for posting that Methods.. it seem that it is time now to make a merge of all valuable information regarding Sevcon controllers and programming!

2 questions: it would be also very cool to add informations regarding witch are the lastest existing availlable drivers, dld and DVT version etc for each!
I saw on thunder strunk EV that they mention that with te compact USB to CAN (V1.5 or 1.6 i guess) that Current DVT software version 24.816... i will have to veryfy witch veriso i have!..

Also, to make a place where we can share and have acces to all our working DCF! This is common problem.. no store want to share these if you dont buy their controller...

Also Are you sure the Sin/Cos and A/B sin/cos are only decoded by the last digit of the serial number?.. i tought it was the last 3.. like xxxxxxxx201 (A/B UVW) and xxxxxxxx203 (for the A/B UVW Sin/cos) ?

Btw i have alot of files regarding sevcon programming and tips that i can share.. even if you dont have all them.

I also made myself some sumarry of good information that Biff shared to me when discussing that i can share.

Finally making some tutorial about tuning and how to understand and use these variable like Id, iq etc and also field weakening!

Doc
 
Doctorbass said:
Also, to make a place where we can share and have acces to all our working DCF! This is common problem.. no store want to share these if you dont buy their controller...

Doc


It's incredibly exciting if we can provision some rudimentary algorithms for programming sevcons for various purposes (in the similar way that we can do with the phaserunner now) It's considerable more difficult, but the Sevcon is amazing and it's worth it. Truth be told I can only make basic edits to DCF files or else things tend to unravel for me :D 8)
 
From now i'm using winmerge to compare various DCF files and isolate some variable, tu understand what they do.

I succeded to rebuild my own working but not perfect DCF from multiple other DCF files.

Doc
 
I can verify that hard-hacking DCF files is actually a valid way of going about things.
If you look closely... it is a readable format... that is not CRC protected

I have (under supervision of a master) successfully modified a DCF by hand and had successful results loading it.

Now... it is MUCH EASIER to modify with a GUI
Start from a known
Change only one thing at a time
Move with caution.

I have some webspace available. Lets see if we can post up some known good working profiles.

-methods
 
methods said:
I can verify that hard-hacking DCF files is actually a valid way of going about things.
If you look closely... it is a readable format... that is not CRC protected

I have (under supervision of a master) successfully modified a DCF by hand and had successful results loading it.

Now... it is MUCH EASIER to modify with a GUI
Start from a known
Change only one thing at a time
Move with caution.

I have some webspace available. Lets see if we can post up some known good working profiles.

-methods

Yes that's good idea, if you have that place i'l have some for share (but to be verified)

I use notepad to open them and modify these, it's easy.
 
Ok
Before I post them I will need to confirm that they load appropriately and dont cause any strange artifacts.
After I test them I will post them to a public repository and you / others will have read and write access.

A while back I was building a WordPress page that would allow uploading of files... cache issues with my server flogged that up... but I figured it out (turned off caching)
Give me a few days to get the interface working and you can directly upload and share links.

Maybe I will post a spreadsheet of what is new, what has been tested, what it was tested on, etc.
Build some pedigree

After a while folks will just recognize that it came from the doc and not worry :wink:

-methods
 
methods said:
After a while folks will just recognize that it came from the doc and not worry :wink:

-methods

Hmm well i just hope :lol: .. i'm not expert.. these will eb more as "experimental"

Doc
 
I have the repository up and running but the toolset I am using is giving me a hard time with file extensions

.txt works
.zip does not work
.dld works
.dcf does not work

I dont like having to muck up file names to upload... so I am going to fix it.

If anyone does need to change file extensions... in something like Windows 10... just do the following:

Open a file explorer window
Navigate to the folder that holds your file
Go to FILE, Open command Prompt (upper left corner)
The command prompt will open in your current folder... so no need to cd, cd.., or any of that
Type: rename <oldfilename.txt> <oldfilename.dcf>
If it works you will not get an error. That is the easiest way to edit file names that I know of... AND THE REASON WHY YOU DONT PUT SPACES IN FILE NAMES!!!!

Examples:

rename fart.txt fart.dll
result: extension changed

rename fart.txt egg.txt
result: name changed, extension same

rename fart.txt egg.dld
result: name and extension changed

Anyhow... I will post links when I have the interface fully debugged.

-methods
 
I dont have time to fool with it anymore.
Here is where it is at - it is functional:


http://www.schindlerengineering.com/public/repository/

Purpose: To share workload around the safe and reliable programming of the Sevcon Gen 4 controller (specifically)


Directions:

1) You can directly upload *.dld files. To upload *.dcf files, please Zip them up first or change the extension.

2) Press upload. You will be given the opportunity to select the file from your computer.

3) Choose the subfolder you are uploading to... there are DLD and DCF subfolders. Be respectful as there is no check.

4) Upon a successful upload you will be redirected to the ES splash page. IF there is an error, the error box will describe the problem you had.


* I maintain a log of who uploads what and when.
* You may upload multiple files of the same name... they will be appended with the date/time of upload to find the "newest" (no overwrite allowed)
* If people abuse the system I will make it a login-only tool.
* Once a few files appear I will put in the time to expose those files on the repository page.
* I am going to (at first) filter the files before exposing them... if nobody abuses the tool then I will just allow anything uploaded to be instantly accessed.

If you find any bugs - other than those noted - please let me know.

This is not a tool to share pirated keys or anything like that.
There is a 50MB limit on file size

It is presumed that the files uploaded were either created or modified by users.
It is equally valid to DOWNLOAD the DCF file from your OEM vehicle... and share that. It is not protected or controlled in any way.
I repeat: Anyone can download the DCF from their golf cart or motorcycle... just as simple as pushing a button.... so its not like we are doing anything "wrong".

Live long and prosper.

thanks,
-methods
 
Doctorbass said:
Hmm well i just hope :lol: .. i'm not expert.. these will eb more as "experimental"
Doc

Lol Doc... I always thought you were doctor Bass (fisherman)... as in the best guy with a fishing pole.
It was not until much later that I realized you got your start doing big audio systems... makes a ton of sense.
I thought of you just recently when I revived my ancient Punch 500.2

After so many years sitting in an old wet warehouse... the amplifier still rocks!
The of the internal main caps corroded and fell out
All of the terminals are super corroded

That said... I hooked it up into two speakers 4ohms each... with only an 8awg wire to the battery... worked great.

Wired it up Mono, into 2 ohms (against specification) and it works MUCH better :shock:

When I first wired it I unintentionally had one speaker wired backwards... the speakers I got on a trade and someone had done it internal to the box.
I was so disappointed with the bass output... I could not believe it... they were only 10's... but they were JL... I scratched my head...
I found a Youtube THX test that runs like 1hz into the speakers and I could visually see that they were 180 out of phase...
Changed the phase selector switch...

LOL... OMG....

I started blowing the 60A fuse right away.
Switched to a 100A breaker... and... you know how the story goes.

My limitations now are simply overheating of the components... so... I limit the volume and lower the seat cushion for air circulation.

Glad you are here doc.
Keep up the good work.

-methods
 
:D

methods said:
Doctorbass said:
Hmm well i just hope :lol: .. i'm not expert.. these will eb more as "experimental"
Doc

Lol Doc... I always thought you were doctor Bass (fisherman)... as in the best guy with a fishing pole.
It was not until much later that I realized you got your start doing big audio systems... makes a ton of sense.
I thought of you just recently when I revived my ancient Punch 500.2

After so many years sitting in an old wet warehouse... the amplifier still rocks!
The of the internal main caps corroded and fell out
All of the terminals are super corroded

That said... I hooked it up into two speakers 4ohms each... with only an 8awg wire to the battery... worked great.

Wired it up Mono, into 2 ohms (against specification) and it works MUCH better :shock:

When I first wired it I unintentionally had one speaker wired backwards... the speakers I got on a trade and someone had done it internal to the box.
I was so disappointed with the bass output... I could not believe it... they were only 10's... but they were JL... I scratched my head...
I found a Youtube THX test that runs like 1hz into the speakers and I could visually see that they were 180 out of phase...
Changed the phase selector switch...

LOL... OMG....

I started blowing the 60A fuse right away.
Switched to a 100A breaker... and... you know how the story goes.

My limitations now are simply overheating of the components... so... I limit the volume and lower the seat cushion for air circulation.

Glad you are here doc.
Keep up the good work.

-methods
 
No files uploaded to the server as of this morning.
When they appear I will test them.

Today I am on Engineering Hours to configure a couple of Sevcon's for use on two different motor platforms.
We are delivering an "Engineering Use Only" setup for thrust and thermal testing.
Pretty sweet setup... Drilled and heavily modified motors, size 6 controller, clean custom harness, multiple UI's for different use cases.

Not this deliverable... but other deliverable use cases:
_Boating - prop in the water
_High Torque NEV's (snapping axles)
_Motorcycles, Tricycles, and variants
_Prop to air propelled vehicles (in this case... picture a swamp boat)
_Other Vehicles... even an Ebike to rival Luke's "Death Machine" (which make no mistake... was a motorcycle with pedals)

My years in flying RC as well as my experience power-boating tell me that tuning for a prop (in the air or in the water) is trivial in comparison to tuning for a direct drive wheel on the ground. Every aspect is easier and more forgiving.

On a motorcycle... near zero RPM performance is crucial
On a prop... its basically freewheeling

On a motorcycle... rate of change (up and down) is critical to the feel of the bike
On a prop... its a second order effect so the dI/dt can be greatly relaxed making things much easier to manage

On a direct drive vehicle on land... the Sevcon Control loop has a very difficult task
In a once-removed application (anything prop) I believe it will be much less fussy

On a motorcycle... space and weight are of the greatest concern
In a boat... meh
In an airplane... well... weight is important but space can be had
In an NEV... space a plenty

My first move in tuning will be:

* Assure compatibility with hardware
- Configure I/O's, interlocks, sequence requirements
- Set contactor voltages
- Confirm motor params
- Set battery limits (voltage/Current)
- Set temp limits (motor, controller, not battery)

* Set safety limits for testing
- RPM range
- Rate of change (slowing it down - no surprises... nobody wants 0 to 6000RPM instantaneously!)
- Thermal derating (I want to never hit the thermal limit so we will be more aggressive with the derating as temps rise)

For years I have fiddled a setting here and a setting there to meet requirements for a specific customer need.
This will be one of our first end to end deliverables for an emerging market.
Very exciting to get paid to work on something so positive.

Now... To figure out how to pay the rent and make this happen for everybody
Taller order than it sound like. Hours are hours... and I have angry ex-wives and a kid now... no longer am I the mad-man in the garage with infinite time.

-methods
 
I am on vacation for 3 weeks... sorry for any inaccurate information that floated in that time.

Corrections:

* The original ixxat is NOT required.
* I have had success with versions of DVT that will perform all functions (DLD and DCF) using the ixxat compact V2
* I have had success using the funky Ebay Chinese knockoff. It just needs to be unplugged every now and again when it hangs.
* I have learned a lot about bricking and I owe a writeup.
* We can successfully unbrick a black LED, a solid LED that is unresponsive, and pretty much get out of trouble with precision
* Our older DVT does not play nice with the compact V2... but it does play nice with the clone device! (just... DLD may take FOREVER so walk away from it)
* When flashing a DLD file just walk away... for like... AN HOUR. Dont be a patrick and brick your stuff.

* Sevcon DVT is still very buggy... but clearly Sevcon is taking feedback and making improvements. Some bugs we see often:

* Rounding Errors... be very careful here. Remember that we are converting from HEX to DEC then multiplying by a scaling factor. This must work out... and that is why you see artifacts... sometimes you need to do the math yourself (forwards and backwards) and push those numbers directly into the DCF.

* Bugs Bugs: Sometimes changing a setting in one place has totally unexpected results in another... basically... dont change anything unless you absolutely must and when doing so change ONE THING at a time, power cycle, shut down DVT, and confirm no new errors have occurred. If you see an error... cycle again... then just start over with your last known good. I have had error states which I was not able to reasonably recover from.

* Save often... every time you make a change that will stick - save it off and use that as your new branch of code.

* pat attention to the DLD firmware you are running and the compatibility with the DCF

* There are many versions of DVT... which expose many different levels of control. Make sure you get a version of DVT which has the "Search" function... as there can be fields in your DCF which do not appear in DVT. Using Search will pull up ALL FIELDS and allow you to make modifications in every spot. Sevcon does a lot of error checking... and if you have inconsistency it will steer you into the bush.

* For debricking - I will write it up later... but if you end up with a solid black LED>.. it just means you have to pop out of bootloader.
* If you brick to a solid LED but get no response (the ugly one... happens when you disrupt and upload) you need to use the command line to get out. Basically you enter the two charicter command to ENTER BOOTLOADER (a series of 4 hex numbers load into the CAN buffer) then you power cycle the controller. Upon power up it will see those 4 hex words and force into boot mode... where you can then attempt a clean flash. Again... BE PATIENT. Different versions of DVT show you different progress bars... and I always end up with an error or 4 at the end... just go take a dump or get a cup of coffee while it is doing anything DLD related. Trust me... unless you like to learn $25 lessons :D

Yea... so I am on vacation and Doug of UP Garage loaned us a 2013 FX as well as a first Gen Prius to get around. Pretty sweet.
To augment that we built 2 electric boats running on Thunder Sag cells... with a fully potted meanwell for charging.

As a thumbs up to Meanwell... I have confirmed that you can submerge their potted unit in salt water and keep on trucking :oops: (Dont tell Doug)
At DQ last night I also noticed that they had an LED sign out front powered by a potted Meanwell... it was mounted right out in the sun and rain.
Says a lot... its worth the extra cash to have a potted monolithic charger. Clearly fit for mounting on a bike in poor weather.

I usually try to break up text by posting pics... but I need a USB-C adapter for my google phone... I left it at home and only have the fast charger.
For what it is worth... The Nexus 5X is the toughest phone I have ever owned. It charges in like 20 minutes and never fails. Mine hardly even has a screen on it anymore after I have sat on it, dropped it off car roofs, skittered it along parking lots, soaked it in salt water, hammered it against table tops... The charge port is NOT designed obsolescence... and the only way I have failed it was by filling the memory all the way up with pictures and movies. Even the camera glass is broken out and it still takes killer pictures. I am running some hacked Google ROM to keep Tethering working and it is an epic phone.

-methods
 
Oh yea... big one...

I was seeing "Stale Data" errors in DVT super bad.
Correct info was burned into the controller but DVT was displaying stale. It can be a real time loss.

I am seeing a lot of trouble around manually setting RPM limit in Baseline, Profile 1, Profile 2, and Local Limits... (there are also a couple spots in Search)
I set all the values to ... say 5000RPM
Local Limits comes back (after an OP cycle) with some number which is a weird average between 4K and 6K... off by hundreds of RPM... and if I keep changing the number back to 5K it converges like it is averaging old data. Sigh.. DONT EVEN WANT TO KNOW. I tested - and in reality my limits hold on the test setup... so... so be it.

Seeing a lot of range error bugs - that report fault but flash fine.

Basically... the Sevcon does what it says it does... But DVT needs a team of 5 working on it for 6 months to catch up.
The Sevcon is like the general solution... so many ways to control it... near impossible task to capture all of it perfectly in DVT>
Whatever - it works good enough to get on the road.
No sense bashing them if we want to see improvements.
I have decided what they built is rad and that I want to support it. Thats what I am doing today... burning my $1k/mo R&D budget helping a guy get a controller up and running. Sadly I suspect it has a hardware issue... but we will see.

Does anyone know what the hardware architecture is between Vbat coming in, powering the low voltage electronics, and how that relates to the main caps?
My understanding is that the main caps should be "floating around" until such time as I precharge and hit the contactor... so I visualize a PWM circuit between the low voltage area and the high power area... and if that PWM blows out... then there is some sort of pass-thru (mosfet short circuit) which... still precharges the caps.. but causes errors around welded contactor.

Anyway... off on another adventure.
We built a transom for an inflatable boat that runs 4S 90Ah and a beefy trolling motor.
Spins in circles ok... turns like shit.

-methods
 
Thanks Patrick for the added info. this thread will become a reference for many actual and future Sevcon users i feel.

4 thing si still wonder about DCF:

1- How do we know WITCH firmware(.DLD file) a DCF config file need to work?
are all DCF config files include the DLD version number requirement?

ex: If a DCF was made and saved from a controller with a 76.08 version firmware and someone attempt to run it on a controller that have a 76.06 firmware how do we know thsi is the cause of multiple errors?


2- Is it possible to just open a DCF without the need to upload it to a controller to see parameters?
( I know it is possible to use winmerge or notepad however all value have the famous scalling and are in HEX...)

3- About what you wrote:Does anyone know what the hardware architecture is between Vbat coming in, powering the low voltage electronics, and how that relates to the main caps?
I admit it would be helpfull to know!!


4- My actual main problem with sevcon programming is: motor overcurrent that make cutout at 1/3 of the drag strip!!.. and i hate that as i feel pretty shy when it happen and it does not make any good publicity for EV!!

Apparently we need to set the torque map to full torque at every rpm and then to go for a test and record the run and then place the torque just a bit above the obtained torque on the graph... I need to make more experiement regarding that!..

I actually have all these parts to play with:

2x size 6 Sevcon controller,
2x size 4 Sevcon controller,
1x size 2 Sevcon controller,
1x 75-7 regular 6 turn Zero motor
1x 75-7 hybrid 4 turn Zero motor
1x 75-7R IPM 2016 ( new in the box) Zero motor
1x set of UVW Hall sensor set for 75-7
2x ME0913 Zero motor
1x Xu MeXXX motor Zero motor
6x ZF2.8 Zero battery
1x ZF11.4 Zero battery
3x Sevcon DC-DC 300W

plenty of TYCO contactor, BMS MBB Display wiring...

Doc


But still have tons of problem running a single sevcon properly like i wish ! :lol:


but not all the time i need!!
 
Below inline

Doctorbass said:
1- How do we know WITCH firmware(.DLD file) a DCF config file need to work?
are all DCF config files include the DLD version number requirement?

I dont know the answer to that for certain but my best guess is that it must be in the first few dozen lines of the DCF... that is where I would put it.

MY12 Bike so 76.08
ProductNumber=0x07055012
RevisionNumber=0x00010021

MY13 Bike so 76.08
ProductNumber=0x07055012
RevisionNumber=0x00010021

Known 66 DLD
ProductNumber=0x07055037
RevisionNumber=0x00010022

The first two of the above are equal... the third is different.
That is where I would start.


ex: If a DCF was made and saved from a controller with a 76.08 version firmware and someone attempt to run it on a controller that have a 76.06 firmware how do we know thsi is the cause of multiple errors?

I agree that manually moving everything over is tedious... the primary difference on a Zero DCF in 66 is the lookup table. You may need to at least include a placeholder.


2- Is it possible to just open a DCF without the need to upload it to a controller to see parameters?
( I know it is possible to use winmerge or notepad however all value have the famous scalling and are in HEX...)

Isnt that obnoxious? I was just helping a guy today and I could not pull up anything without hooking to a controller. Also... all the fuss with converting from Hex to Dec then multiplying by the scaling factor. Grrrr..... oh well.


3- About what you wrote:Does anyone know what the hardware architecture is between Vbat coming in, powering the low voltage electronics, and how that relates to the main caps?
I admit it would be helpfull to know!!

We have yet to solve that problem. The hardware seems to be faulty so next step is to try and spoof the controller into not throwing the error upon startup. I am guessing it wont work due to the tight timing expectations. MAYBE if we could get it into operational... but cant get there (chicken before the egg). Wish I could disable the Welded Contactor error.


4- My actual main problem with sevcon programming is: motor overcurrent that make cutout at 1/3 of the drag strip!!.. and i hate that as i feel pretty shy when it happen and it does not make any good publicity for EV!!

Sevcon is different... they dont want you bumping off the current limit! Set it to maximum current. Use the torque and rpm limits only. Yea... I had to learn this the hard way too...

Apparently we need to set the torque map to full torque at every rpm and then to go for a test and record the run and then place the torque just a bit above the obtained torque on the graph... I need to make more experiement regarding that!..

No... you can ramp the torque down... oh... wait... are you saying that you are bouncing off the total max current limit? Well.. the Zero bikes ramp down the torque significantly at higher RPM. Just use what they use and be happy that it works. Tuning that box is a nightmare of lost hours.

I actually have all these parts to play with:

2x size 6 Sevcon controller,
2x size 4 Sevcon controller,
1x size 2 Sevcon controller,
1x 75-7 regular 6 turn Zero motor
1x 75-7 hybrid 4 turn Zero motor
1x 75-7R IPM 2016 ( new in the box) Zero motor
1x set of UVW Hall sensor set for 75-7
2x ME0913 Zero motor
1x Xu MeXXX motor Zero motor
6x ZF2.8 Zero battery
1x ZF11.4 Zero battery
3x Sevcon DC-DC 300W

Time for more batteries! Thats a pretty good list to start with. I will not share our list :wink:

plenty of TYCO contactor, BMS MBB Display wiring...

Doc


But still have tons of problem running a single sevcon properly like i wish ! :lol:

It can be done...

but not all the time i need!!
 
Oh yea...

and some time last year I got into a position where I would have to delete one of the DCF sections to get it to load.
Something in the 0x46XX area
I can check my notes later.

If you are running this and that from here and there... and you are seeing errors around the 0x46XX block... consider that as a possibility.
Careful tho...

A thousand ways to make you sorry the Sevcon has :shock:

-methods
 
Funding, statement of intent, important notes:

This is side work for me and I am no longer in a position to fund ventures like this. I have dumped tens of thousands into R&D on projects like this but I can not currently do that.


* An OEM has invested in proper tooling and training to support Sevcon and help to head off bad PR, people having trouble, and otherwise get the ball rolling in an appropriate way. OEM has purchased a full tool set and materials, for proper crimps and spec wiring. OEM has spent a considerable amount trying to sort the bull from the bullshit with compatibility, programming, functionality, and capabilities - all while minimizing interface with Sevcon and maximizing utilization of existing knowledge base. OEM has several test stations commissioned for freewheel testing, basic qualification, encoder calibration, and even load testing (Dyno). OEM is tight on cash tho - so we are moving VERY SLOW.

* A few customers have allowed us to take steps forward. Our goal is not to support "hacking" of Sevcon equipment but rather to legitimize use of existing legacy equipment in the field for new use cases intended for volume production (Medium weight road EV and prop applications). The reality is that the equipment has been in the field for a decade now and people WILL try to use it. The equipment is very complicated and difficult to use... There is some existing tension between Sevcon and the non-OEM community and it is my belief that this can be resolved through proper education on use and a civil/professional approach.

* Any flaming of Sevcon or bitching/moaning due to lack of proper training will get a negative response from me. Any honest effort to improve relations and warm Sevcon up to working with an expanded definition of OEM will be supported by me. Companies deal with OEM's only because HOBBYISTS ARE AN EXTREME TIME SINK for people on company time. Most hobbyists are not qualified, quick to judge, and have high expectations. Sevcon was never meant to be in the hands of hobbyists, so please treat it as a privilege to even be able to run or program one.

* We will not expose any proprietary information but we will harvest and clarify existing information in the public domain. We will also work diligently to dispel myth and maximize probabilities of success for adopters.

* It is my intent to further investigate the up-cycling of New-Old Sevcon hardware that has hit the market. UVW controllers are great for anything prop related. Direct Drive road Vehicles can also run quite well on UVW ... just not quite with the polish of something like the Zero Motorcycle (which runs SIN/COS continuous encoding).

* It is my intent to prove that an expansion of market and open public dialog will REDUCE PROBLEMS AND COST for Sevcon... by incubating an knowledge depot that people can access instead of bugging Sevcon on the phone constantly. We intend to help head off this sort of support need as much as funding will allow. We will eventually converge on a point where Sevcon benefits from our work and they will appreciate us. I always welcome the edge cases, problem cases, or nightmare situations... as that is the best opportunity to learn.

-methods
 
Doctorbass said:
Thanks Patrick for the added info. this thread will become a reference for many actual and future Sevcon users i feel.

4 thing si still wonder about DCF:

1- How do we know WITCH firmware(.DLD file) a DCF config file need to work?
are all DCF config files include the DLD version number requirement?

ex: If a DCF was made and saved from a controller with a 76.08 version firmware and someone attempt to run it on a controller that have a 76.06 firmware how do we know thsi is the cause of multiple errors?

Doc


But still have tons of problem running a single sevcon properly like i wish ! :lol:

but not all the time i need!!

I was asking myself the same question and on inspecting a number of DCF's I found that a search for [100A] reveals ParameterName=Software version
ParameterValue=blah blah which in every DCF I have appears to be the firmware version. It also appears from data posted by whereswall606 that if you load a DCF ment for a different firmware when you back it up again the Software version Parameter is updated to the firmware version that is currently on the controller in question which is to be expected. The implication of this is that unless you know the original source of the DCF the software version listed could well be misleading. But in the case where the DCF has been supplied by the OEM it may be helpful to ensure that the correct firmware version is used to match the parameters set in the DCF.
 
Wish I had more time to tinker with it - I would test that theory.

I am pretty much spending my time collecting beer cans at the beach to recycle for airline tickets. :mrgreen:


-methods
 
kiwifiat said:
I was asking myself the same question and on inspecting a number of DCF's I found that a search for [100A] reveals ParameterName=Software version
ParameterValue=blah blah which in every DCF I have appears to be the firmware version. It also appears from data posted by whereswall606 that if you load a DCF ment for a different firmware when you back it up again the Software version Parameter is updated to the firmware version that is currently on the controller in question which is to be expected. The implication of this is that unless you know the original source of the DCF the software version listed could well be misleading. But in the case where the DCF has been supplied by the OEM it may be helpful to ensure that the correct firmware version is used to match the parameters set in the DCF.

I got my DCF file from the Jonescg in Aus (via the web) this came from his emax sevcon which came stock with the newer Emax bikes and was off of a size 2 whereas i bought a size 4 second hand. I saved the original files before trying to flash it. I am thinking that using the GUI for the sevcon and a complete page by page setting of all the parameters I could flash the controller which the same settings as I dont think it will try to change firmware settings. But alot of this is just me having a go and seeing what works and I've very little time devoted to this at the moment.

I am however a few weeks off converting my garage into a bigger office and garage combined which will mean i have easy access to a computer and a spare full Emax bike to test on. Perhaps my interest will be renewed at that point. I will also be on 3 month paternity which will give me some time to tinker. Also I am still waiting on a fully fledged surface mount lebowski from Bobc, but we need to get our working through hole prototype fully tested too. This is down to my lack of time, Bobc has been very productive on this front.
 
Confirmation from page 112 of the Gen4 product manual V3.3 that data @ 100A is current software version:

Identification and version
Read identification and version information at:
* 1008h – Controller name.
* 1009h – Hardware version.
* 100Ah – Software version.
* 1018h – Identity object. Contains CANopen vendor ID, product code, CANopen protocol revision, and controller serial number.
 
kiwifiat said:
Confirmation from page 112 of the Gen4 product manual V3.3 that data @ 100A is current software version:

Identification and version
Read identification and version information at:
* 1008h – Controller name.
* 1009h – Hardware version.
* 100Ah – Software version.
* 1018h – Identity object. Contains CANopen vendor ID, product code, CANopen protocol revision, and controller serial number.


Nice find!

Doc
 
Back
Top