Axiom: a 100kW+ motor controller

mxlemming said:
Like I said, only PDFs. Am I missing something? Is my browser not rendering correctly? I don't consider this to be open source if all I would have to do is open up kicad, copy the pdf into the schematic editor, replace and re code from scratch the obsolete fpga and lay it out from scratch.

Re. The effort. I'll be frank. I'm on endless sphere because I really love watching people's projects, I get genuinely really excited and happy for them when they succeed, I love helping to the extent I can.

I've been rooting for axiom, I thought it's super cool, love it... Want to have a go building my own igbt based board (got absolutely nothing to do with it but I still really want to...) But now it's really feeling to me like you are just bumping it onto the first page of this forum every time it falls off with a nothing post. "Get ready for something big" picture of your logo. Etc. "Btw, power designs do consultancy work".

There's that expression about people not liking it when their heros fail them. That's where I am with this. I want you to succeed and share the videos of axiom propelling an earth mover up a hill or hitting 200mph or whatever. I want to know the technical challenges hit and how you overcame them. I'll be really excited and happy for you. I want you to sell this and make profit from it.

We did not share the PCB design you are correct. The biggest reason is we don't want the risk of someone doing something wrong then blaming us for a fire or a death. Everything else is there.
All of the rest will come. Remember we are also dealing with chip shortages. The main control board cost us 10x more to produce 5 months ago then it did just 2 years ago. FPGA is for us to add options in the future but it was not obsolete just 6 months ago. I believe we have a direct replacement for it. And we do have 10 boards here for the first run that were populated with FPGAs just 3 months ago. The main goal for us from this is to build a reputation and it has worked, Too well in fact, as we are getting more work then we can handle at this point. The second biggest goal is to build awesome stuff like the CRX. Axiom is coming together the first 2 machined enclosures are to be delivered at my house this Friday. Yes I will admit I don't work slow like this and its killing me. What has taken years should have taken months in my mind. But I can't complain as I am working 3 jobs and own 2 houses 1 we just purchased with my inlaws and with big renos going on as well I have 2 young kids. Most people would never be even remotely close to doing this much stuff but I/we are pushing though and the whole team is as busy as I am! The goal is to get organized and cut back on work for others and do more for myself and the team asap. The whole team is multi tasking as we try to grow PD organically. Its not abnormal for a company to seem like its not moving forward fast enough (remember the model 3 ramp with tesla?) I can tell you I plan for less divorces than Elon which does meen I need some time with my family as well... :lol:
 
amberwolf said:
I'm not sure if it's helpful, but the "original" files (5 years old) should be here
https://github.com/paltatech/VESC-controller
but I don't know which ones would be PCB files, if there are any. :oops:

be careful that layout has errors
 
I think we need to address this. Not open source=not open source and you're waving the open source flag pretty hard.

A pdf schematic is NOT open source, it's output, documentation. The other day I downloaded with ease the schematic for my Yamaha hifi. Does that make it open source? No. It means it's available under the US right to repair bill... And it was really useful after my 3yo smashed a button on it

I'm well aware your primary goal is to market yourself.

But you make exceptional claims of your ability and you're not handing back much evidence.

IMO, if this isn't open source and you're not sharing technical details... This thread is simply vendor advertising and should be moved to the vendors section of the forum. That's what happened to the nucular controller iirc.

The licences attached to open source things typically say clearly "here it is, you're on your own if you dare build this".
 
mxlemming said:
I think we need to address this. Not open source=not open source and you're waving the open source flag pretty hard.
.....
The licences attached to open source things typically say clearly "here it is, you're on your own if you dare build this".

I think there is no reference of Axiom as opensource here. I have seen reference to VESC which is opensource though...
 
arber333 said:
mxlemming said:
I think we need to address this. Not open source=not open source and you're waving the open source flag pretty hard.
.....
The licences attached to open source things typically say clearly "here it is, you're on your own if you dare build this".

I think there is no reference of Axiom as opensource here. I have seen reference to VESC which is opensource though...

Arlo1 said:
mxlemming said:
If you've not engaged a notified body yet... Are you really planning on selling this? Really?

Whoa whoa whoa... All in time. I don't think you know who you are talking to or what all the members of our team are able to accomplish and do for a living on a daily basis! This is an open source motor controller. You can go to hackaday and download it all then open up a PCB editor and design a PCB which should only take you a few min based on the last response you sent. Then you can take that and get all the regulator testing you want done and do with it what you will.

Truth is this has taken much longer then we wanted like WAY longer. But we are all at a handicap with kids and other work to put money on the table etc. If you want to do something ground up faster be my guest. Getting a motor spinning only took a month or so TBH but the rest....
I think I'm done here. My point is clear. It's advertising masquerading as open source. As someone who contributes all the things I talk about on here to real open source (I have paid client projects that are closed, I don't reference them) I find this slightly grating.

This doesn't directly affect me, I'm more than capable of making my own 100kW igbt drive from scratch as and when I need to so I'm going to bow out now.
 

Attachments

  • Screenshot_20220615-181010.png
    Screenshot_20220615-181010.png
    179.1 KB · Views: 1,622
  • Screenshot_20220615-180005.png
    Screenshot_20220615-180005.png
    238.6 KB · Views: 1,622
It’s reasonable to choose path now: can’t say ”it’s open source!” and realise you don’t want to or have the time to share all of it. Same if the pcb schematic work isn’t done publicly - even if it’s due to workload. That’s missing the whole point of open source, right?

So: are these open source or vendor posts?
 
mxlemming said:
This doesn't directly affect me, I'm more than capable of making my own 100kW igbt drive from scratch as and when I need to so I'm going to bow out now.

Well go ahead now, i still would like to hear what those guys have to say when testing at such power.
I have built more than 100kWh inverters and from experience i can tell you robustness is key and key to robustness is testing. After a year every inverter i built has had a problem of one kind or another. Every single one except when i used OEM power section. So i took that PS and hijacked the brain with mine. I posted the files on my github. Does that make it opensource? Even though i took anothers hard work and implemented it into mine, reverse engineering? Some could call it piracy even. :shock:
 
larsb said:
So: are these open source or vendor posts?

These are not VENDOR POSTS at all!

All files have been shared including an early PCB file. But many changes have been made and we are likely to make a few more.
-Code 100% all open source and we have been the biggest contributors to the code other than Benjamin himself.
All parts of this have been shared but the latest PCB has not for good reason we are not dealing with E-bike power here.
Someone messes this up will cause a fire and or death.
PDF is the most common way for anyone to review the schematic but if that is not enough we can share the Kicad SCh. files. That is no big deal. A early BOM was shared as well. All the stuff is there.

I don't understand the negativity. We have all worked crazy hard on this but if you like we can stop posting and we can all leave ES and delete all of our content as well. <- Maybe have a look at the contributions to the forum we have all put in over the years including another open source controller I put together which I only know 1 person who tried to build their own boards and had 1 failure very close to a fire because they missed something.
 
arber333 said:
mxlemming said:
This doesn't directly affect me, I'm more than capable of making my own 100kW igbt drive from scratch as and when I need to so I'm going to bow out now.
i still would like to hear what those guys have to say when testing at such power.
I have built more than 100kWh inverters and from experience i can tell you robustness is key and key to robustness is testing. After a year every inverter i built has had a problem of one kind or another. Every single one except when i used OEM power section. So i took that PS and hijacked the brain with mine. I posted the files on my github. Does that make it opensource? Even though i took anothers hard work and implemented it into mine, reverse engineering? Some could call it piracy even. :shock:

Did you see any of my dyno videos? I have almost 2 years of dyno testing with this and I have pushed it VERY hard never had any failures. I did do a LOT of things that would have made my other early controller fail and Axiom just faulted and shut down like intended saving everything! Anyways I just received the new housings on Friday and will be assembling them for final testing.
 
Arlo1 said:
larsb said:
So: are these open source or vendor posts?

These are not VENDOR POSTS at all!

All files have been shared including an early PCB file. But many changes have been made and we are likely to make a few more.
-Code 100% all open source and we have been the biggest contributors to the code other than Benjamin himself.
All parts of this have been shared but the latest PCB has not for good reason we are not dealing with E-bike power here.
Someone messes this up will cause a fire and or death.
PDF is the most common way for anyone to review the schematic but if that is not enough we can share the Kicad SCh. files. That is no big deal. A early BOM was shared as well. All the stuff is there.

I don't understand the negativity. We have all worked crazy hard on this but if you like we can stop posting and we can all leave ES and delete all of our content as well. <- Maybe have a look at the contributions to the forum we have all put in over the years including another open source controller I put together which I only know 1 person who tried to build their own boards and had 1 failure very close to a fire because they missed something.
I said I'd bow out, but since you're threatening to delete previous knowledge shared because of me, I'll come back in.

My opinions are mine (and Lars' are his) and may not be representative of the opinions of endless sphere. Choosing to delete your posts on the basis of my opinions may not be what others want, as unlikely as I find your suggestion. I am unwavering in my opinion however that if you wave the open source flag, you should be sharing the source. For hardware, my opinion is that this includes the necessary data to modify and or create the item and i believe your concerns about dangers are unfounded - the licences I've seen for OS hardware explicitly disclaim responsibility, and anyone who downloads something from the internet, pays to have it built, wires it into 400V without taking sensible precautions and understanding it properly and then hurts themselves has only themselves to blame:

Quote Wikipedia:
"The term usually means that information about the hardware is easily discerned so that others can make it – coupling it closely to the maker movement.[1] Hardware design (i.e. mechanical drawings, schematics, bills of material, PCB layout data, HDL source code[2] and integrated circuit layout data), in addition to the software that drives the hardware, are all released under free/libre terms."
https://en.m.wikipedia.org/wiki/Open-source_hardware

I've read a lot of your old posts and found them very interesting. I was very happy for you when your crx first rolled out of the garage and was impressed when you dyno'd 300hp. Even more so, I've followed Marcos' progress with his previous open source controllers and have deep respect for what he's shared. But that doesn't change my perspective on this case.

I'm not a zero contributor to VESC either. Next time you make a VESC beta build have a look at the observer options and HFI options. Peanuts compared to the immense overall effort Benjamin has made but that stuff didn't come out of nowhere. It came from an absolute ton of thinking really hard and I'm really happy to have shared it.
 
integrated heatsink for liquid cooling shown in picture
on the opposite side, where the IGBTs are mounted, we have a flatness spec for CNC <= 30um and for roughness Rz < 10um
It was really tough to design enclosure so that the total height stayed less than 4"
The chassis and top/bottom lid (no components, no screws, no sealant) weighs just over 21lbs. wow!
 

Attachments

  • Heatsink.jpg
    Heatsink.jpg
    224.1 KB · Views: 1,438
Was there a heat / coolant flow analysis done? Looking like the first 2-3 channels will get most of the coolant flow as pictured.
What's the 21 pounds referencing? Heavy duty / lightweight? What's the size / volume of the enclosure?
 
One of my worse sides is that i have a hard time to let go until i see some logic and here there’s an obvious hickup. Sorry for this.

If the old/dated pdf with the pcb layout has ’beware, issues’ like highhopes wrote then the motivation to not update the pcb layouts being that you might get sued for damages isn’t really valid, right? It’s already out there in troublesome form? Then i’d guess it’s a 10 minute job to upload something of better status?
 
HighHopes said:
where the IGBTs are mounted, we have a flatness spec for CNC <= 30um and for roughness Rz < 10um

Are the meeting surfaces of the igbts equally flat? That’s impressive if they are. (Seems like overspecing with those tight tolerances if not)
 
you mean on the IGBT itself? Yes there is even better smooth finish. also the large format modules have a slight bow to them so they flatten out when torqued down which is why manufacturers have a torque spec and also a pattern to apply the torque. furthermore, you can (and should) test the fit by removing the IGBT after greased & torqued, pulling straight up to remove and then look at the pattern left behind of the thermal grease both on heatsink and IGBT. this pattern will tell you if you have any major issues.

just so you know, world record was broken with a heatsink MUCH worse than this.
 
the 21 lbs is the weight of the aluminum enclosure
 
i should also mention that the flatness spec of heatsink is not arbitrarily chosen. its an industrial norm build from decades of practice working with manufacturers directly.
 
larsb said:
HighHopes said:
where the IGBTs are mounted, we have a flatness spec for CNC <= 30um and for roughness Rz < 10um

Are the meeting surfaces of the igbts equally flat? That’s impressive if they are. (Seems like overspecing with those tight tolerances if not)

This isn't tight. Rz10 is like Ra 1.75um which is what I'd expect from a generic drawing boarder tolerance for machining. 30um over the size of an igbt is also entirely unremarkable. The machine shops around me achieve this routinely without request.

Of course there's no real need to do better because the tiniest amount of thermal paste will bridge any gaps.

https://www.cnccookbook.com/surface-finish-chart-symbols-measure-calculators/
Here's a link to a page with the standard, frequently cited tolerances expected. It's pretty out of date, commercial CNC machines have improved a lot.
Edit: Here's a more modern one.
Surface-Finishing-Chart-Ra-ISO-Finishing-V2.png
 
arber333 said:
Lebowski said:
This is why I never went into making commercial controllers. Especially, what when accidents happen and you get sued for selling an uncertified controller ?

Hah! And you could be held an example of coding and interface application. DSpic30 is so robust i never had any failed chips while in use.
I still get some conkout on highway at 130km/h, mostly because signal relay control issues (another arduino controler and EMI) and EVERY time Lebowski will revert back to highway RPM. I couldnt get it to revert back above 130km/h, but then i simply slow down untill throttle control is established. I never had to stop for reset... ever.
My car is TUV approved...totaly legal. I am approaching 2 years of use, so i assume some 1000 times of operation (workdays driving to and from work). This makes its robustness at 10exp-3 without any major difficulties. This is way less than 10exp-9 which is required for production EVs, but getting there.
Nice to hear your car is working good with the Lebowski controller IC. It cannot recover past 130kph because at those speeds with your specific motor and battery voltage it needs field weakening. Field weaking requires synchronised currents to flow, which it cannot do because it is not synced . Thats the whole point of recovery mode, its trying to recover sync...
 
Lebowski said:
arber333 said:
Lebowski said:
This is why I never went into making commercial controllers. Especially, what when accidents happen and you get sued for selling an uncertified controller ?

Hah! And you could be held an example of coding and interface application. DSpic30 is so robust i never had any failed chips while in use.
I still get some conkout on highway at 130km/h, mostly because signal relay control issues (another arduino controler and EMI) and EVERY time Lebowski will revert back to highway RPM. I couldnt get it to revert back above 130km/h, but then i simply slow down untill throttle control is established. I never had to stop for reset... ever.
My car is TUV approved...totaly legal. I am approaching 2 years of use, so i assume some 1000 times of operation (workdays driving to and from work). This makes its robustness at 10exp-3 without any major difficulties. This is way less than 10exp-9 which is required for production EVs, but getting there.
Nice to hear your car is working good with the Lebowski controller IC. It cannot recover past 130kph because at those speeds with your specific motor and battery voltage it needs field weakening. Field weaking requires synchronised currents to flow, which it cannot do because it is not synced . Thats the whole point of recovery mode, its trying to recover sync...
Is this a fundamental limitation, or is it possible to measure the phase voltages, track the rotor position, calculate the field weakening current required and restart the controller?

I've got auto recovery working on my firmware, but I've never experimented with this while deep into field weakening regime, or with a battery attached to clamp the voltage (PSU builds up to the equivalent voltage in field weakening).
 
Lebowski said:
Nice to hear your car is working good with the Lebowski controller IC. It cannot recover past 130kph because at those speeds with your specific motor and battery voltage it needs field weakening. Field weaking requires synchronised currents to flow, which it cannot do because it is not synced . Thats the whole point of recovery mode, its trying to recover sync...

Yes and FW starts around 110km/h for me, so i am cheating a bit because i am giving the chip more time to scope for sync. I extended time when it looks for recovery to about 0.7s and it works with some other minor changes. But when i extend time further it will not sync no matter what.
Do you think of a parameter that would require more special treatment :)?

OTOH 130km/h is really enough speed, my primary concern is i am able to recover before 90km/h so i dont get stranded inside truck traffic. They do not understand i would need to drive slower... :eek:
 
mxlemming said:
Is this a fundamental limitation, or is it possible to measure the phase voltages, track the rotor position, calculate the field weakening current required and restart the controller?

I've got auto recovery working on my firmware, but I've never experimented with this while deep into field weakening regime, or with a battery attached to clamp the voltage (PSU builds up to the equivalent voltage in field weakening).

For safe operation in FW you need to have battery attached. :shock:
I have tried the same on the car with "sensorless" supported by sensors and it backfired. I could never get a good recovery above 90km/h. If i decoupled sensors i was able to recover at much higher speed. This showed me sensored mode is not developed really well (or i have EMI on its lines at high speeds) and sensorless is really the way here.

Do not forget i dont use actual 120(60)deg hall sensors but RLS sensor with angular magnet on motor shaft.

EDIT: How is VESC now with FW code? Do you recommend resolver with it or another kind encoder?
 
arber333 said:
mxlemming said:
Is this a fundamental limitation, or is it possible to measure the phase voltages, track the rotor position, calculate the field weakening current required and restart the controller?

I've got auto recovery working on my firmware, but I've never experimented with this while deep into field weakening regime, or with a battery attached to clamp the voltage (PSU builds up to the equivalent voltage in field weakening).

For safe operation in FW you need to have battery attached. :shock:
I have tried the same on the car with "sensorless" supported by sensors and it backfired. I could never get a good recovery above 90km/h. If i decoupled sensors i was able to recover at much higher speed. This showed me sensored mode is not developed really well (or i have EMI on its lines at high speeds) and sensorless is really the way here.

Do not forget i dont use actual 120(60)deg hall sensors but RLS sensor with angular magnet on motor shaft.

EDIT: How is VESC now with FW code? Do you recommend resolver with it or another kind encoder?

The field weakening works well enough for the cases I've been able to test. VESC tends to swap into sensorless mode whatever settings you use... Sure it's possible to force a sensor only mode but I've not dug into this much.

Bear in mind I'm on my own journey for FOC and controllers, my project is an entire code base written by me with not a single line borrowed from VESC. My goals are portability to other mcus and simplicity to integrate into more product like devices, but mainly learning.

Benjamin integrated my sensorless observer and a HFI method me and a Dutch guy called Elwin came up with into VESC. I don't actually use VESC that much. Not because there's anything wrong with it, I actually think the ecosystem Benjamin's created as a whole is amazing, just... I'm on my own journey.

The best encoder for VESC seems to be the as5047. Interface with resolvers requires external hardware AFAIK.
 
"This isn't tight." no worries, people been saying that to me my whole career. I just ignore the naysayers and keep going. I worked with the manufacturer of the large format modules, at the die level to assembly. every process, every step. i then stress tested the modules from several supplies and ranked them. all done in a military qualified lab with experts in every field available at any cost. so i'm happy with my approach, it has proven to work for over 20 years and the manufacturers agree too.

you can always make it flatter, there's nothing wrong with that.
 
Back
Top