[paul3112]

Now that's funny...

No, his driver is missing steps and I've tried to help him but he doesn't seem to have the time to fix it now so he'll have to find someone else who can work with his lethargic time schedule and his failure to communicate in a timely manner.

I just cant understand why the stm32F4 has not been looked at. it has sooo much to offer
STM32F407/417 - STMicroelectronics
STM32F4/29 Discovery with CMSIS library in Keil uVision - STM32F4 Discovery

and I am not trying to derail this project, just an observation.
I follow this thread while looking for 3 phase ac servo torque control drivers

Paul

[dwalsh62]

I just cant understand why the stm32F4 has not been looked at. it has sooo much to offer
STM32F407/417 - STMicroelectronics
STM32F4/29 Discovery with CMSIS library in Keil uVision - STM32F4 Discovery

and I am not trying to derail this project, just an observation.
I follow this thread while looking for 3 phase ac servo torque control drivers

Paul

The STM32F4 does not appear to be available in a 32 or 36pin package, having more unused pins than used is a waste of a device in this particular application.

What does that STM32F4 have to offer that would be beneficial to this project as I don't see it?

If you're interested in an AC servo application project you should be looking at something like the STMBL project and not a DC servo application project like this one.

[tandel]

Now that's funny...

No, his driver is missing steps and I've tried to help him but he doesn't seem to have the time to fix it now so he'll have to find someone else who can work with his lethargic time schedule and his failure to communicate in a timely manner.

sorry for lated reply i apologize for that i already sent you a massage
anothother thing is i can see that jfstockton is working on code section so i think i have readed the mihais code and he is using using single loop pid loop only containing position loop processing as this : http://elm-chan.org/works/smc/rcc/zblock2.png
but we can improve this by cascade pid with position loop +velocitiy loop +tork loop so we we can get better performance which is look like as follows :
http://elm-chan.org/works/smc/rcc/zblock3.png

if you wanna go more further then you can go for feed forward control (i still trying to lern it)
what i know about feed feed forward is motors velocity and accelaration caractristic should known to us and we need to use this value in velocity feed forward and accelaratio feed forward
so alone feedforward is open loop system and it does most of all control and pid have work little so overall performance will be cool !
so cascadepid +feedforward=great perfomance
but let me tell u one thing only cacade pid can give us better performance then single loop pid which is we are currenty using
the reason behind proposing cascade pid and feed forward here is that i think this stm32 arm is fast enough to do all calculation (obviously too much faster then 8 bit avr elm chna attiny2313 (actually great work !) comparing at frequency but also with calculation becuse i think they are calculating at 32bit so faster calculation )

[tandel]

i have a quastion why we dont code this stuff in mbed so its pretty easy to code and easy to implement and understand
is code generated by mbed will be executed slow ?(especily in this appliction where spped is needded)

https://developer.mbed.org/

[dwalsh62]

i have a quastion why we dont code this stuff in mbed so its pretty easy to code and easy to implement and understand
is code generated by mbed will be executed slow ?(especily in this appliction where spped is needded)

https://developer.mbed.org/

Unless you have working code to put into mbed someone would need to write it all from scratch and this wold take a considerable amount of time and I'm not for anything that causes further time delays.

While we have the ability to achieve a 92% efficiency with the recommended pin changes, it starting to look like the only product that will be available will be subsequently less efficient (68%) and cost more and this kind of nonsense only pisses me off.

I think this project as much as it is desired and needed, will go nowhere based on the lack of any real progress, I've pushed to make things happen and despite any efforts I've made, the resistance to completing the project is what prevents a product from becoming available and this is extremely frustrating and disappointing.

At this time, reducing the recommended pinout from STM to a single current sense line, dropping back-emf, dc-link and forgetting about the encoder index signal is about the only way to get this project completed provided that someone fixes the code and I can't see this happening any time soon based on the lack of progress for the time already passed.

sorry for lated reply i apologize for that i already sent you a massage
anothother thing is i can see that jfstockton is working on code section so i think i have readed the mihais code and he is using using single loop pid loop only containing position loop processing as this : http://elm-chan.org/works/smc/rcc/zblock2.png
but we can improve this by cascade pid with position loop +velocitiy loop +tork loop so we we can get better performance which is look like as follows :
http://elm-chan.org/works/smc/rcc/zblock3.png

if you wanna go more further then you can go for feed forward control (i still trying to lern it)
what i know about feed feed forward is motors velocity and accelaration caractristic should known to us and we need to use this value in velocity feed forward and accelaratio feed forward
so alone feedforward is open loop system and it does most of all control and pid have work little so overall performance will be cool !
so cascadepid +feedforward=great perfomance
but let me tell u one thing only cacade pid can give us better performance then single loop pid which is we are currenty using
the reason behind proposing cascade pid and feed forward here is that i think this stm32 arm is fast enough to do all calculation (obviously too much faster then 8 bit avr elm chna attiny2313 (actually great work !) comparing at frequency but also with calculation becuse i think they are calculating at 32bit so faster calculation )

Yes the PID code could use an upgrade and cascading makes it more efficient but stability will be in question if the remainder of the code doesn't properly handle the generated interrupts, mask and reset them.

The current PID is running in constant torque mode by positioning, there is no ramping so constant velocity which is not needed in a step/dir type drive which has no analog input to allow operation of the drive in constant torque or constant velocity, the drive is step/dir only and the motor is operating at constant torque and this causes confusion but step/dir is not a constant torque or constant velocity capable drive.

Yes, you can do a hybrid positional, step/dir system but then time to code it would take a long time based on the available knowledgeable people who are working on the code so we should not at this time pursue this avenue as a main goal of the project.

The big question is, and there really is no way getting around it, is to decide if you wish to settle for the less efficient and more costly drive or a more efficient less expensive drive that has commercial qualities and characteristics, personally I choose the more efficient and will be utilizing this design myself regardless of the decision of the collective.

If the decision is to go with the less efficient and more costly drive I will contract someone to write the code for the drives I will use and unfortunately since it will bear a significant cost, this code wont be available for general use, the purpose of a public project is for everyone to benefit and the design and code based on publicly generated work.

Actually, I've already decided to go ahead and have code generated, I'll be finalizing the details of the contract later today but this does not deter me from this project, it's much needed and shouldn't be abandoned like every other project of it's kind.

[Khalid]

dwalsh and all the guys working on this project...My salute to you all... Can't add anything due to lack of knowledge but learning from you great guys...keep it up and buck-up guys..

[tandel]

i really happy with pekka's code which is based on mihai actually he is using serial interface instead of usb and his code is really readable that may help you to go easy (great work pekka also mihai )really clean good written code i think he doesnt used HAL
i think he is still working on current limiting part

https://github.com/pekkaroi/bldc-drive

i also compiled in loded this code in stm32f103 board and i got no warning and i had success with his intial startup massag shows up but i dont know how to go ahead so i leaved it but it may be helpful to you aspecially for coding
till then keep up good working

[tandel]

Yes the PID code could use an upgrade and cascading makes it more efficient but stability will be in question if the remainder of the code doesn't properly handle the generated interrupts, mask and reset them.

ya cascade pid there three loop instead of single loop so cascade pid may be problematic but i think feed forward will fits here because its only need to be calculated here are some :

http://images.machinedesign.com/imag...0000038819.gif
http://support.motioneng.com/downloa...00-0184_08.gif
Getting the most out of servocontrollers | Archive content from Machine Design
Scaling PID Tuning Parameters for Different Controller Sample Rates

so i think only we need to just fit the velocity and acelaration equation in code and we are on !
every motor has different velocity and accelaration due to its differnt mass inertian and inductance and other stuffs so we shoud be able to give this value in servo tuner software same as pid values but will not tune this we will put the values which will we got from motors company

i am not telling you to try it now but first complete single loop pid.. after that for more improvement we will go for pid+ feed forward if we need (as i heard feed forward really improves system performance)

[dwalsh62]

ya cascade pid there three loop instead of single loop so cascade pid may be problematic but i think feed forward will fits here because its only need to be calculated here are some :

http://images.machinedesign.com/imag...0000038819.gif
http://support.motioneng.com/downloa...00-0184_08.gif
Getting the most out of servocontrollers | Archive content from Machine Design
Scaling PID Tuning Parameters for Different Controller Sample Rates

so i think only we need to just fit the velocity and acelaration equation in code and we are on !
every motor has different velocity and accelaration due to its differnt mass inertian and inductance and other stuffs so we shoud be able to give this value in servo tuner software same as pid values but will not tune this we will put the values which will we got from motors company

i am not telling you to try it now but first complete single loop pid.. after that for more improvement we will go for pid+ feed forward if we need (as i heard feed forward really improves system performance)

It's not as simple as you say, first the code must be made to work with the advised pinout before any such modifications could be considered.

i really happy with pekka's code which is based on mihai actually he is using serial interface instead of usb and his code is really readable that may help you to go easy (great work pekka also mihai )really clean good written code i think he doesnt used HAL
i think he is still working on current limiting part

https://github.com/pekkaroi/bldc-drive

i also compiled in loded this code in stm32f103 board and i got no warning and i had success with his intial startup massag shows up but i dont know how to go ahead so i leaved it but it may be helpful to you aspecially for coding
till then keep up good working

This BLDC code is not based on Mihai's code, this code does dual current sensing, DC-Link sensing, A/B encoder lines and triple hall sensors but no way it will run the Mihai board without some serious modifications and pin reassignment.

This schematic design is an exact copy of the Leadshine BLDC driver right down to the current shunts and can only hit 72% and the output stage is not balanced (if you can't see and understand this don't ask).

This code does have some use for us as the dual sense lines are available and I can remove the back-emf and go with the DC-Link (all of this is quick for me) but if no one can make the code work in a reasonable amount of time then it's pointless to look at it for more than the dual current sense code.

[dwalsh62]

I had been discussing with STM about adding the encoder index signal and on thursday one of the engineers agreed to take my schematic and fix it up.

He made significant changes, added support for encoder index as well as supporting encoder errors such as open-circuit, short-circuit, over-voltage, under-voltage.

He also removed 10 resistors used for the dual current sensing and replace these with two SOIC8 current sense IC's.

Added 3 bi-color LED's so you can tell which encoder line has an error and a line to the MCU with a delay to let it know an encoder error exists to prevent any false positives.

He gave very good instructions about moving some components for optimal placement, updated traces to support 15A peak / 30A surge currents.

The design was tested in a simulator and achieved 94% magnetic saturation which equates to the 129.7% max torque limit achievable in a 3-ph induction motor.

He still recommends the 17692 PWM frequency over the 20000 that everyone else is using and the explanation while long winded, jfstockton understood why so this is what we're going with.

I've made the datasheets for the IC's and the schematic for reference available to jfstockton so he can see the IO and pin changes and hopefully get the code working soon.

The design no longer resembles the Mihai design and while I can build the design and or produce boards now, it's pointless when there is no code to test/run it so I'll be holding off until code is available.

I've sent jfstockton a small STM32F103CBT6 which has all the IO brought out on it to use as his development board and I realized I made the bottom silk screen words reversed but in the correct positions so he can at least figure out what pin is what.

As well I'm getting some STM32F103TBU6/7 development boards made up (borrowed design) which also have all the pins brought out and will probably send one to him when they're done and arrive.

I've got a small collection of 36V BLDC servo motors that I've built and tested with outstanding results and while I had a small encoder source issue, I've been able to find an acceptable inexpensive alternative that only cost a few dollars more available in 1000ppr and 2500ppr quadrature with index signal so we should really look at some way to make these publicly available since they would be the ideal motor to pair with this driver.

On another note not related to the open project, I've finalized my deal with someone for my servo driver which has some pretty impressive features.

Support for AC or DC 3-phase motors, it has an 1500W onboard quad rail, fully isolated switchmode power supply.

It can drive a motor from 12V to 160V and up to 15A settable in the configuration menu and manages current with an IPM module.

It has two STM32's which communicate on the SPI (or I2C) buss, one MCU is dedicated to just managing the PWM motor output stage and a 3.95in TFT LCD display in an LQFP32 package, absolute or incremental encoder support, full encoder with optional hall sensor support so those 14wire Tamagawa encoder are fully supported, configurable IO for step/direction, 0-10V analog with dir input or -10V-0-+10V single line analog input, encoder A/B/Z pass-thru.

Boards are being produced as we speak and I'm told the code will be done and fully tested within 14 days so I have something to look forward too, a shame this is not an open hardware/software project but I just can't rely on public support for coding time of a driver I personally need done now so it's a private personal project that I can build as I require them and I have no intentions of producing them commercially, too much money involved and not worth the aggravation.

[paul3112]

I had been discussing with STM about adding the encoder index signal and on thursday one of the engineers agreed to take my schematic and fix it up.

He made significant changes, added support for encoder index as well as supporting encoder errors such as open-circuit, short-circuit, over-voltage, under-voltage.

He also removed 10 resistors used for the dual current sensing and replace these with two SOIC8 current sense IC's.

Added 3 bi-color LED's so you can tell which encoder line has an error and a line to the MCU with a delay to let it know an encoder error exists to prevent any false positives.

He gave very good instructions about moving some components for optimal placement, updated traces to support 15A peak / 30A surge currents.

The design was tested in a simulator and achieved 94% magnetic saturation which equates to the 129.7% max torque limit achievable in a 3-ph induction motor.

He still recommends the 17692 PWM frequency over the 20000 that everyone else is using and the explanation while long winded, jfstockton understood why so this is what we're going with.

I've made the datasheets for the IC's and the schematic for reference available to jfstockton so he can see the IO and pin changes and hopefully get the code working soon.

The design no longer resembles the Mihai design and while I can build the design and or produce boards now, it's pointless when there is no code to test/run it so I'll be holding off until code is available.

I've sent jfstockton a small STM32F103CBT6 which has all the IO brought out on it to use as his development board and I realized I made the bottom silk screen words reversed but in the correct positions so he can at least figure out what pin is what.

As well I'm getting some STM32F103TBU6/7 development boards made up (borrowed design) which also have all the pins brought out and will probably send one to him when they're done and arrive.

I've got a small collection of 36V BLDC servo motors that I've built and tested with outstanding results and while I had a small encoder source issue, I've been able to find an acceptable inexpensive alternative that only cost a few dollars more available in 1000ppr and 2500ppr quadrature with index signal so we should really look at some way to make these publicly available since they would be the ideal motor to pair with this driver.

On another note not related to the open project, I've finalized my deal with someone for my servo driver which has some pretty impressive features.

Support for AC or DC 3-phase motors, it has an 1500W onboard quad rail, fully isolated switchmode power supply.

It can drive a motor from 12V to 160V and up to 15A settable in the configuration menu and manages current with an IPM module.

It has two STM32's which communicate on the SPI (or I2C) buss, one MCU is dedicated to just managing the PWM motor output stage and a 3.95in TFT LCD display in an LQFP32 package, absolute or incremental encoder support, full encoder with optional hall sensor support so those 14wire Tamagawa encoder are fully supported, configurable IO for step/direction, 0-10V analog with dir input or -10V-0-+10V single line analog input, encoder A/B/Z pass-thru.

Boards are being produced as we speak and I'm told the code will be done and fully tested within 14 days so I have something to look forward too, a shame this is not an open hardware/software project but I just can't rely on public support for coding time of a driver I personally need done now so it's a private personal project that I can build as I require them and I have no intentions of producing them commercially, too much money involved and not worth the aggravation.

Will it support;
speed vector and torque.
will it support rising and falling edge for the encoder ( say 10000)
accept external interrupts eg limit and estop.

regards

Paul

[dwalsh62]

Will it support;
speed vector and torque.
will it support rising and falling edge for the encoder ( say 10000)
accept external interrupts eg limit and estop.

regards

Paul

A step/dir type drivers usually doesn't support these modes so it is unlikely that they will be added.

The encoder signal is based on a rising/falling signal and 10000 what???

If you asking if the driver will support a 2500ppr quadrature encoder (10,000cpr), yes.

I see no reason to have support in a servo motor driver for e-stop and limit switches and I have no intentions of adding the hardware support.

The intent of this project is an upgrade path for those using stepper motors who want to change to something that gives more power, higher RPM at an affordable cost.

The driver is a step/dir type driver, no analog input support, the thought of adding any other type of input drive support when no working code currently exists is nothing shy of stupidity, modification of the code to accept other types of input modes requires functioning code and adding this support would seriously delay any code completion.

If you have already completed code that works with the updated/advised pinout then by all means do share, then it would be possible to examine possible software updates which include additional input modes, proposing a potential software feature without working code will be ignored.

[lemonbee]

I've read this code and debugged. But I have a question,in pwm.c there are always two transistors conducting at the same time, how does it transit 6 phases in one cycle? Appreciate your help.

lemon

[dwalsh62]

I've read this code and debugged. But I have a question,in pwm.c there are always two transistors conducting at the same time, how does it transit 6 phases in one cycle? Appreciate your help.

lemon

What you are suggesting is physically impossible.

In triphasic PWM, when a motor is turning there is either two (DUAL) or three (TRIPLE) FET's in an ON state and there are nine possible states in total, six are ON states, two are OFF/BRAKING states, one COASTING state and does not including transitional or dead time states.

I believe the STM32 uses a dual state but I have been unable to confirm this, these are the basic states.

ON/RUNNING STATE (DUAL)

1. A-LO, B-HI, C--- (ON)
2. A-HI, B---, C-LO (ON)
3. A---, B-LO, C-HI (ON)
4. A-HI, B-LO, C--- (ON)
5. A-LO, B---, C-HI (ON)
6. A---, B-HI, C-LO (ON)

ON/RUNNING STATE (TRIPLE)

1. A-LO, B-HI, C-HI (ON)
2. A-HI, B-HI, C-LO (ON)
3. A-HI, B-LO, C-HI (ON)
4. A-HI, B-LO, C-LO (ON)
5. A-LO, B-LO, C-HI (ON)
6. A-LO, B-HI, C-LO (ON)

OFF/BRAKING STATES

• A-HI, B-HI, C-HI (OFF)
• A-LO, B-LO, C-LO (OFF)

COASTING STATES (all FET's OFF)

• A---, B---, C--- (COAST)

[lemonbee]

What you are suggesting is physically impossible.

In triphasic PWM, when a motor is turning there is either two (DUAL) or three (TRIPLE) FET's in an ON state and there are nine possible states in total, six are ON states, two are OFF/BRAKING states, one COASTING state and does not including transitional or dead time states.

I believe the STM32 uses a dual state but I have been unable to confirm this, these are the basic states.

ON/RUNNING STATE (DUAL)

1. A-LO, B-HI, C--- (ON)
2. A-HI, B---, C-LO (ON)
3. A---, B-LO, C-HI (ON)
4. A-HI, B-LO, C--- (ON)
5. A-LO, B---, C-HI (ON)
6. A---, B-HI, C-LO (ON)

ON/RUNNING STATE (TRIPLE)

1. A-LO, B-HI, C-HI (ON)
2. A-HI, B-HI, C-LO (ON)
3. A-HI, B-LO, C-HI (ON)
4. A-HI, B-LO, C-LO (ON)
5. A-LO, B-LO, C-HI (ON)
6. A-LO, B-HI, C-LO (ON)

OFF/BRAKING STATES

• A-HI, B-HI, C-HI (OFF)
• A-LO, B-LO, C-LO (OFF)

COASTING STATES (all FET's OFF)

• A---, B---, C--- (COAST)

Many thanks for your reply and I agree with the transition method you put forward. But if you draw the table of e1, e2, e3 in the source code, I believe you can find they vary as follows:
e1: 0 1 1 0 1 1
e2: 1 0 1 1 0 1
e3: 1 1 0 1 1 0

When I debugged I found the compensation channels are always conducting, so I am doubt about whether there are only three states in one cycle. Thanks again.

[dwalsh62]

Many thanks for your reply and I agree with the transition method you put forward. But if you draw the table of e1, e2, e3 in the source code, I believe you can find they vary as follows:
e1: 0 1 1 0 1 1
e2: 1 0 1 1 0 1
e3: 1 1 0 1 1 0

When I debugged I found the compensation channels are always conducting, so I am doubt about whether there are only three states in one cycle. Thanks again.

If you have the complimentary always conducting then there is no way you wont blow up your board, it's physically impossible because the compliments are a mirror of the primary so you better check both channels simultaneously with your scope (hopefully you aren't fooling checking it with a meter).

If you don't have a scope, buy a dual channel digital storage LCD scope on ebay (they're dirt cheap).

[lemonbee]

If you have the complimentary always conducting then there is no way you wont blow up your board, it's physically impossible because the compliments are a mirror of the primary so you better check both channels simultaneously with your scope (hopefully you aren't fooling checking it with a meter).

If you don't have a scope, buy a dual channel digital storage LCD scope on ebay (they're dirt cheap).

I have observed the waveform with scope, and the motor is 8 poles, there were 2 cycle changes of the waveform in 1 power cycle . I really want to make certain of the principle, thank you for your advice.

lemon

[dwalsh62]

I have observed the waveform with scope, and the motor is 8 poles, there were 2 cycle changes of the waveform in 1 power cycle . I really want to make certain of the principle, thank you for your advice.

lemon

Motor poles have nothing to do with it and there is no way a bridge can have a channel and it's compliment activated at the same time, this is impossible.

To examine a 3-phase motor you need a 6-channel scope to see all fets simultaneously to properly map the signals and unlikely you have one.

A dual channel scope to look at one pair of fets so can see a single channel will show you that no high and low side are on at the same time but there is no way you can determine anything more and don't interpret off time or dead time as a part of the cycle.

[lemonbee]

Motor poles have nothing to do with it and there is no way a bridge can have a channel and it's compliment activated at the same time, this is impossible.

To examine a 3-phase motor you need a 6-channel scope to see all fets simultaneously to properly map the signals and unlikely you have one.

A dual channel scope to look at one pair of fets so can see a single channel will show you that no high and low side are on at the same time but there is no way you can determine anything more and don't interpret off time or dead time as a part of the cycle.

Thank you for your recommention. I am a beginner of this area, and I must say this project is really a good one, I will keep exploring above this.:wee:

[lemonbee]

Hey guys do you have any interesting idea to improve the performance in low velocity? I found there was some shaking in that mode.:wave: