[dwalsh62]

First let me start off by saying that this thread is not a place to post questions about the design or implimentation or to request help for your owndesign, request pictures or make feature requests and that if I feel the thread is becoming polluted with nonsense I will abandon the thread as quickly as I have started it.

When pictures are available they will be posted, if there are no pictures this is because there is nothing to take pictures of so it is best to follow the thread quietly, this development is being done for your benefit and it is well overdue.

The time you take away by asking questions will take away from time better spent working on the design itself.

During the development of this project I advise against sending PM's to those directly involved in the project development, if you have something of value to contribute or skilled in the field and wish to contribute time to the development you can make a short post here but stay on topic and do your best to not pollute this thread with long winded explanations of your qualifications.

This thread is provided for informational purposes so that you are aware that an effort is being made for something reasonably priced for the DIY'ers and hobbyists and that an available and reliable upgrade path to servo motors is trying to become a reality which the hobby community so desperately needs.

I have partnered with Iron-Man to design a DC Servo Motor Driver that is affordable and allows you to use just about any DC Servo Motor with encoder you can obtain.

The first phase of the project is to complete the design and testing of the DC Servo Motor Driver for Brushed DC Servo Motors at which time the schematic and board layout files along with any firmware/software will be made available for those who are able to roll their own PCB's.

The design will allow for a lot of part compensation so the driver can be built to suit your specific needs or based on parts you have on hand.

Shortly after the PHASE ONE completion, PCB's should be available in which you can assemble yourself and I believe populated boards will also be available for those who don't have the time to acquire all the components and assemble it or lack the skills to do it.

Yes we could roll everything into one project and complicate the hell out of it but it is our belief that simple is better and less confusion will be created if only the reliable aspect of the requirement is targeted, you are free to take the design and add all the fluff you want for your own needs but no support will be provided for your modified design.

Once the first phase has been completed the second phase will begin which is a second version of the DC Servo Driver for a 3-PH BLDC Servo Motor.

If during the course of our design work we find that making a reliable and inexpensive driver is not possible I will make a public post stating so and why we have tossed in the towel.




PHASE ONE / STAGE ONE
Taking from existing OpenSource dsPIC designs which utilize component that have strange power supply requirements, incomplete designs or are not cost effective and converting them to use affordable, easy to obtain discrete components is underway the task at hand is to make sure we can make the hardware function correctly.

Using my two phase PWM H-Bridge stage design that was modified by a MicroChip engineer to add support for enable we will be attempting to mate it with the dsPIC to run the motor, I am estimating this will take a short time to do (order and deliver parts, do the work) but can't give an exact date when this will be completed as these are done on personal time when time is available and this itme of the year has it's own set of time consuming interruptions.

PHASE ONE / STAGE TWO
Once we are able to make the general design work, time will be spent tweaking it for optiimal performance and working on a board layout will begin.

PHASE ONE / STAGE THREE
Building and documenting a production PCB version of the design so you can see it in action is a requirement demanded by most skeptic users so we will make an effort to alleviate any skepticism and post pictures/videos where applicable.


PHASE ONE / STAGE FOUR
Giving the product a stamp of approval and releasing the project to the public and at least making blank PCB's available.




Once PHASE ONE has been completed, moving to PHASE TWO and the BLDC driver should be easier as the ground work will have been completed and this ensures that a driver is available to meet up with everyones needs.





PHASE ONE - STAGE ONE HAS BEGUN!!!

[mcm_xyz]

Very nice! Keep up the good work.
However if I may suggest... You should start with driving the BLDC first. If you will make a DC drive only it's gonna be a little obsolete as BLDC's are way more reliable and nowadays more and more are available.
And if you will have a working BLDC driver transforming it to both BLDC and DC would require only a few modifications in code, all the hardware required to drive the DC motor are already there...

Best of luck!

Mihai

[dwalsh62]

Very nice! Keep up the good work.
However if I may suggest... You should start with driving the BLDC first. If you will make a DC drive only it's gonna be a little obsolete as BLDC's are way more reliable and nowadays more and more are available.
And if you will have a working BLDC driver transforming it to both BLDC and DC would require only a few modifications in code, all the hardware required to drive the DC motor are already there...

Best of luck!

Mihai

I already said this is not a post asking for features yet you found it necessary to tell me I should be making a BLDC driver first and then use it as a brushed driver by making changes to the software and this is never going to happen.

This will not be a "One Driver Fits All" and brushed DC motors are plentiful, I can find very few BLDC servo motors that are inexpensive.

The drivers will be dedicated drivers, one for brushed, one for brushless, supporting 12V to 48V motors and up to 10A continuous, simple to install/setup so even a nut-less monkey can do it.

It is not as simple as you say, most BLDC drivers have 3 or more phases and additional inputs for HALL sensors and in my opinion a poor hardware design if you need hall sensors.

Yesterday I was playing with a BLDC servo drive, the schematic, board and firmware I got off a post from this site, fixed the schematic, tossed his single layer board design and made a smaller two layer design capable of supporting 15A continous, I made changes to swap out the 74LS14 for some single SOT23-5 SMD hex inverters and the DIP40 ATMega644A to a TQFP44 ATMega1284P-AU cause I have it on hand, then made a small trip the the ER when the motor just about took my wrist off during a low power run test. and the design has no inputs for hall sensors which leads me to believe that hall sensors are not required if the firmware is correct.

Now I need to find someone who's good at AVR programming to add support for the encoder index signal and then there will be three inexpensive designs that people can obtain/build.

For around $250.00 + $35.00 shipping you can buy a leadshine ACS606+BLM57180 motor which they claim has a quadrature 1000PPR (4000PPR) encoder but the encoder only has A and B signals and isn't running as quadrature and uses hall sensors for coil phase sensing, the specs are not correct for power and torque, typical china "put what they think makes it sound powerful" specifications are never accurate so don't expect anything serious when my customer tested these they fell so short at half the specified ratings making them no better than a Nema23 stepper motor.

It's dsPIC based and using the wrong fets in the driver stage, a quick change to NDP6060L and the driver starts to come to life, you can't fix the flaws in the firmware because they don't provide the source and they set the fuse bits to prevent you from reading the code out of the dsPIC so it's really not a good buy.

My customer finally has a factory making him an OEM motor and driver package for almost half the leadshine price ($130.00), the unfinished sample was impressive at 1.94Nm of torque, STM32F103 based driver, motor has no hall sensors, tamagawa (copy) quadrature encoder running in quad mode and a basket-wound stator with a cast rotor which really resembles a hybrid AC/DC 3-PH motor more than a BLDC motor due to the lack of magnets.

[dwalsh62]

Here is the original unmodified BLDC Servo Driver, to use it you only need to fix the board layout as these are the causes for his problems although I advise you make it a two layer board so it has better signal isolation.

Once I get an AVR guru to help me with the code I'll post the updated schematic and updated code.

At this time all I can tell you is that his code works well but only supports encoder A/B lines, it's originally using a DIP40 ATMega644 but I didn't have one so I used a TQFP44 ATMega1284P-AU cause I had it, basically the same AVR just more memory.

The original design can be further modified/improved to reduce the 6 lines used to drive the 3 h-bridges to 3 lines if you make use of three of the unused inverters effectively making the IR2101 have a single input with an inverting and non-inverting output but the code would need to be modified to remove the 3 lines as they would no longer be required and only waste CPU cycles.

[mcm_xyz]

Here is the original unmodified BLDC Servo Driver, to use it you only need to fix the board layout as these are the causes for his problems although I advise you make it a two layer board so it has better signal isolation.

Once I get an AVR guru to help me with the code I'll post the updated schematic and updated code.

At this time all I can tell you is that his code works well but only supports encoder A/B lines, it's originally using a DIP40 ATMega644 but I didn't have one so I used a TQFP44 ATMega1284P-AU cause I had it, basically the same AVR just more memory.

The original design can be further modified/improved to reduce the 6 lines used to drive the 3 h-bridges to 3 lines if you make use of three of the unused inverters effectively making the IR2101 have a single input with an inverting and non-inverting output but the code would need to be modified to remove the 3 lines as they would no longer be required and only waste CPU cycles.

Hello again!

I must tell you that you are talking to the author of both the AVR and the later STM32F103 projects with no HALL inputs. And I was not asking for any feature, I was just making a suggestion based on hundred of hours of development. I am not into electronics, I am a software engineer, so yes I am pretty sure that the electronic schematic and board are dummy and can be greatly improved. And another suggestion... Drop the AVR MCU for the STM one, it's much more powerful and has exactly what you need and advanced PWM generator with complementary outputs and configurable deadtime...

Mihai

[RCaffin]

most BLDC drivers have 3 or more phases and additional inputs for HALL sensors

Um ... a lot of BLDC motors take a 2-wire input: just DC volts. The reason is that the switching is all done internally, often using tiny Hall effect senors, but you never get to see them.

If you start off with the right sort of DC servo drive, you can power both brUshed DC motors and brushless DC motors. But the industrial brushed DC motors will usually be cheaper and far more robust, with massive thermal time constants and huge overload capacity.

Cheers
Roger

[clintonedward]

I already said this is not a post asking for features yet you found it necessary to tell me I should be making a BLDC driver first and then use it as a brushed driver by making changes to the software and this is never going to happen.

This will not be a "One Driver Fits All" and brushed DC motors are plentiful, I can find very few BLDC servo motors that are inexpensive.

The drivers will be dedicated drivers, one for brushed, one for brushless, supporting 12V to 48V motors and up to 10A continuous, simple to install/setup so even a nut-less monkey can do it.

It is not as simple as you say, most BLDC drivers have 3 or more phases and additional inputs for HALL sensors and in my opinion a poor hardware design if you need hall sensors.

Yesterday I was playing with a BLDC servo drive, the schematic, board and firmware I got off a post from this site, fixed the schematic, tossed his single layer board design and made a smaller two layer design capable of supporting 15A continous, I made changes to swap out the 74LS14 for some single SOT23-5 SMD hex inverters and the DIP40 ATMega644A to a TQFP44 ATMega1284P-AU cause I have it on hand, then made a small trip the the ER when the motor just about took my wrist off during a low power run test. and the design has no inputs for hall sensors which leads me to believe that hall sensors are not required if the firmware is correct.

Now I need to find someone who's good at AVR programming to add support for the encoder index signal and then there will be three inexpensive designs that people can obtain/build.

For around $250.00 + $35.00 shipping you can buy a leadshine ACS606+BLM57180 motor which they claim has a quadrature 1000PPR (4000PPR) encoder but the encoder only has A and B signals and isn't running as quadrature and uses hall sensors for coil phase sensing, the specs are not correct for power and torque, typical china "put what they think makes it sound powerful" specifications are never accurate so don't expect anything serious when my customer tested these they fell so short at half the specified ratings making them no better than a Nema23 stepper motor.

It's dsPIC based and using the wrong fets in the driver stage, a quick change to NDP6060L and the driver starts to come to life, you can't fix the flaws in the firmware because they don't provide the source and they set the fuse bits to prevent you from reading the code out of the dsPIC so it's really not a good buy.

My customer finally has a factory making him an OEM motor and driver package for almost half the leadshine price ($130.00), the unfinished sample was impressive at 1.94Nm of torque, STM32F103 based driver, motor has no hall sensors, tamagawa (copy) quadrature encoder running in quad mode and a basket-wound stator with a cast rotor which really resembles a hybrid AC/DC 3-PH motor more than a BLDC motor due to the lack of magnets.

Actually if you work with ARM base systems like the STM32F103, I can help you with the code.

A modern BLDC driver actually doesn't need a Hall sensor to run. It can run in sensorless mode or infer its absolute location using the encoder by alignment during boot up. However, many industrial applications does not allow the driver to align blindly during bootup, that's why some high demand applications require Hall sensor.

Like mcm_xyz said, I would suggest you skip the brushed DC. The reason is it's out of date, not so safe for DIYers, since it can run amock on itself if the encoder fails or the the driver fails, or during tuning. Besides, having to change brushes every few months is annoying, especially when you have calibrated everything & not in the mood to do it again.

[dwalsh62]

Hello again!

I must tell you that you are talking to the author of both the AVR and the later STM32F103 projects with no HALL inputs. And I was not asking for any feature, I was just making a suggestion based on hundred of hours of development. I am not into electronics, I am a software engineer, so yes I am pretty sure that the electronic schematic and board are dummy and can be greatly improved. And another suggestion... Drop the AVR MCU for the STM one, it's much more powerful and has exactly what you need and advanced PWM generator with complementary outputs and configurable deadtime...

Mihai

I have no issues dropping the AVR for STM32F103 however, coding the STM32 would then require either someone to convert the existing source to STM32 or rewrite the code and test it to ensure it is reliable and coding these MCU's (AVR or STM32) is not my area of expertise.

Regardless of the MCU used, layout and making the boards are not an issue, reliable firmware and a simple dedicated design is.

The purpose of a dedicated drive for brushed and brushless motors is the flexibility of the motor itself not limiting you to specific motor, the ability to utilize an encoder that may or may not have an index signal and a flexible motor voltage stage is what will make it useful because people will buy the cheapest motor they can find on ebay and then look for a way to drive it that doesn't require a degree.

I've built and tested the previously attached BLDC drive and can say with all certainty it works and works well, although I substituted parts for better choices to minimize heat and improve performance in the motor stage, I did not alter the design because any alteration in design then makes the reliability an unknown factor and modification to the firmware not an option for me.

It has been further suggested the brushed servo motors are unsafe and I fail to see how they are unsafer than BLDC motors, quality brushes last a long time and with access to just under 6,000 ElectroCraft 250W 48VDC Servo Motors at a very cheap price, making them available with a driver for $100.00 would not be an issue but securing the motors (due to the quantity involved) without a reliable drive is a waste of financial resources I'm not willing to undertake.

Actually if you work with ARM base systems like the STM32F103, I can help you with the code.

A modern BLDC driver actually doesn't need a Hall sensor to run. It can run in sensorless mode or infer its absolute location using the encoder by alignment during boot up. However, many industrial applications does not allow the driver to align blindly during bootup, that's why some high demand applications require Hall sensor.

Like mcm_xyz said, I would suggest you skip the brushed DC. The reason is it's out of date, not so safe for DIYers, since it can run amock on itself if the encoder fails or the the driver fails, or during tuning. Besides, having to change brushes every few months is annoying, especially when you have calibrated everything & not in the mood to do it again.

If you wish to join this projects development and work on the design of the BLDC driver I would welcome you with open arms but if your schedule does not permit timely development then I fail to see the benefit of working on a design that we would like to release in the next month or two when you are unable to spend the time developing the drive.

Also, the STM32 I believe is a 3.3V device which means altering the onboard power supply to cover this voltage (not a terribly complicated issue to overcome) and this means altering the design to allow for the lower output voltages to drive components (also not a complicated issue to overcome) to make sure everything functions properly.

There is a lot of talk about what can be generated and as I previously stated there are many designs out there but most are incomplete or far too complicated for the hobbyist to utilize and the purpose of these drives is to bridge this gap but a handful of people who are more knowledgeable and capable want something more than a basic design which does nothing to help the average hobbyist make the transition on a shoe-string budget.

While you may be capable of more than the average user, the average user is the target audience because this is the audience that needs the upgrade path, in your case I would just recommend you buy industrial AC Servo Motors and Drives and drop the whole DC Servo path to make things easier for you.

It's all about helping those stuck on the bottom rung of the ladder move up and this is what people need to understand, if you want a more complicated drive and you can handle the complexity of it then an entirely different design is what you want, these drives are a transitional step from stepper motors to servo motors and will never be anything more.

[clintonedward]

Oh, actually my team develops drivers for the CNC machines; mainly step, DC Brushed & BLDC, ranging from the basic 6 steps to sinusoidal wave, SVM, FOC and DTC. So if you stuck at any point, I am glad to help but I am not going to develop the drivers for you.

Anyway, the easiest one to develop probably is DC Brushed Motor driver. Most engineering students in my university have to build one in their final year. BLDC & AC Servos are more difficult to control but you can do it.

It's ok if you cannot understand how brushed motors are unsafer than BLDC motors because you haven't developed & used them in CNC machines yet. Do it, use it & tell us about it after 3 months.

[dwalsh62]

Oh, actually my team develops drivers for the CNC machines; mainly step, DC Brushed & BLDC, ranging from the basic 6 steps to sinusoidal wave, SVM, FOC and DTC. So if you stuck at any point, I am glad to help but I am not going to develop the drivers for you.

Anyway, the easiest one to develop probably is DC Brushed Motor driver. Most engineering students in my university have to build one in their final year. BLDC & AC Servos are more difficult to control but you can do it.

It's ok if you cannot understand how brushed motors are unsafer than BLDC motors because you haven't developed & used them in CNC machines yet. Do it, use it & tell us about it after 3 months.

I've been using the Electrocraft Motors and Electrocraft Drivers in a small mill for more than a couple of years without any issues, used on a daily basis and only changed the brushes twice in this time, everything I have personally developed utilizes AC Servo Motors and Drives and for me the cost to performance is a no brainer.

The Electrocraft Drivers are simple to use and employ an auto-tune feature but the cost makes them uneconomical for the hobbyist.

A cheap and simple solution is needed, easy to implement and quick to get up and running with as little fuss as possible.

The following is based on the pinout for the TQFP44 package.

In the previously attached schematic, they tie PCINT26/INT0//PD2 (pin11) and PCINT27/INT1/PD3 (pin12) together as inputs for the A encoder signal, does it require the use of both lines for the A signal input or can I split them and use one for the A signal and the other for the Z signal?

The B signal is using only a single input pin.

If I can split them is it better to use PCINT26/INT0//PD2 (pin11) or PCINT27/INT1//PD3 (pin12) for the A signal?

I have the following pins available for use in the TQFP44 package, pin21 to pin26, pin33 to pin37 and pin40.
pin21 = PCINT18/TCK/PC2
pin22 = PCINT19/TMS/PC3
pin23 = PCINT20/TDO/PC4
pin24 = PCINT21/TDI/PC5
pin25 = PCINT22/TOSC1/PC6
pin26 = PCINT21/TOSC2/PC7
pin33 = PCINT4/ADC4/PA4
pin34 = PCINT3/ADC3/PA3
pin35 = PCINT2/ADC2/PA2
pin36 = PCINT1/ADC1/PA1
pin37 = PCINT0/ADC0/PA0
pin40 = PCINT8/XCK0/T0/PB0

For the easiest routing pin21 to pin26 (PC2 to PC7), so if I must keep PD2/PD3 tied together any of these six pins are the next best options.

If they need to be tied together, can I use PCINT18/TCK/PC2 (pin21) or PCINT18/TCK/PC2 (pin22) and PCINT19/TMS/PC3 (pin22) as the Z signal input or do you recommend other pins in this package?

Are you able to make the changes to the firmware to add support for the Z signal, I can quickly make the schematic and layout changes based on the pins you select and this would provide one of the two BLDC drivers that could be made for less than $40.00 assembled.

[clintonedward]

I've been using the Electrocraft Motors and Electrocraft Drivers in a small mill for more than a couple of years without any issues, used on a daily basis and only changed the brushes twice in this time, everything I have personally developed utilizes AC Servo Motors and Drives and for me the cost to performance is a no brainer.

The Electrocraft Drivers are simple to use and employ an auto-tune feature but the cost makes them uneconomical for the hobbyist.

A cheap and simple solution is needed, easy to implement and quick to get up and running with as little fuss as possible.

The following is based on the pinout for the TQFP44 package.

In the previously attached schematic, they tie PCINT26/INT0//PD2 (pin11) and PCINT27/INT1/PD3 (pin12) together as inputs for the A encoder signal, does it require the use of both lines for the A signal input or can I split them and use one for the A signal and the other for the Z signal?

The B signal is using only a single input pin.

If I can split them is it better to use PCINT26/INT0//PD2 (pin11) or PCINT27/INT1//PD3 (pin12) for the A signal?

I have the following pins available for use in the TQFP44 package, pin21 to pin26, pin33 to pin37 and pin40.
pin21 = PCINT18/TCK/PC2
pin22 = PCINT19/TMS/PC3
pin23 = PCINT20/TDO/PC4
pin24 = PCINT21/TDI/PC5
pin25 = PCINT22/TOSC1/PC6
pin26 = PCINT21/TOSC2/PC7
pin33 = PCINT4/ADC4/PA4
pin34 = PCINT3/ADC3/PA3
pin35 = PCINT2/ADC2/PA2
pin36 = PCINT1/ADC1/PA1
pin37 = PCINT0/ADC0/PA0
pin40 = PCINT8/XCK0/T0/PB0

For the easiest routing pin21 to pin26 (PC2 to PC7), so if I must keep PD2/PD3 tied together any of these six pins are the next best options.

If they need to be tied together, can I use PCINT18/TCK/PC2 (pin21) or PCINT18/TCK/PC2 (pin22) and PCINT19/TMS/PC3 (pin22) as the Z signal input or do you recommend other pins in this package?

Are you able to make the changes to the firmware to add support for the Z signal, I can quickly make the schematic and layout changes based on the pins you select and this would provide one of the two BLDC drivers that could be made for less than $40.00 assembled.

Hi,

I am not familiar with AVR since we are from ARM school. However:
1. Probably he ties both PD2 & PD3 together so that he can use 4x mode for the encoder (4 times the resolution), 1 interrupt for rising edge and one for falling. So it's better than 1x mode if you just keep it.
If using ARM, we only need 1 pin as the interrupt can be called on both rising & falling, don't need to waste 2 pins like this.
2. Why do you need the Z signal? If your synchronization is good, Z signal is not so important unless in critical applications.
3. He's already built the hex file Servo.hex. I believe you only need to load this firmware to the ATMega. However, look like he hard coded the encoder resolution, so you should be careful about that.

Just fiy, the technique he uses in the code is six-step commutation. It's the easiest to implement, the result is quite satisfactory.

[dwalsh62]

Hi,

I am not familiar with AVR since we are from ARM school. However:
1. Probably he ties both PD2 & PD3 together so that he can use 4x mode for the encoder (4 times the resolution), 1 interrupt for rising edge and one for falling. So it's better than 1x mode if you just keep it.
If using ARM, we only need 1 pin as the interrupt can be called on both rising & falling, don't need to waste 2 pins like this.
2. Why do you need the Z signal? If your synchronization is good, Z signal is not so important unless in critical applications.
3. He's already built the hex file Servo.hex. I believe you only need to load this firmware to the ATMega. However, look like he hard coded the encoder resolution, so you should be careful about that.

Just fiy, the technique he uses in the code is six-step commutation. It's the easiest to implement, the result is quite satisfactory.

An explanation to what he is doing with the code doesn't help me to make the required changes as I am not familiar with AVR programming.

Making the schematic/board changes as required by the code is something I can do.

I have rejoined PD2/PD3 and utilized PC2 as the Z signal input, under the assumption that it is a usable pin unless otherwise advised, the code to utilize the Z index signal (including roll-over) needs to be implemented, can you make these changes and provide me with the files please.

[mcm_xyz]

An explanation to what he is doing with the code doesn't help me to make the required changes as I am not familiar with AVR programming.

Making the schematic/board changes as required by the code is something I can do.

I have rejoined PD2/PD3 and utilized PC2 as the Z signal input, under the assumption that it is a usable pin unless otherwise advised, the code to utilize the Z index signal (including roll-over) needs to be implemented, can you make these changes and provide me with the files please.

PD2 and PD3 were together because in my learning curve I used 2 interrupts, one for falling one for raising. In the latest code only Int0 is used, so only PD2. This is explained somewhere in the thread but the thread has become too large to get all the updated info...
Also as clintonedward explained Z signal is really not important. if your encoder or the circuit looses steps, then resetting on Z won't make so much difference... I could implement Z input. Just tell me what to do with it...
Please also keep in mind that this implementation not using hall sensors requires to start the motor from a certain position, that has nothing to do with Z index...
In order to configure the Servo drive you will need to connect to it using a usb to serial adapter and the provided software. From there you can configure PID, motor and encoder parameters.

Mihai

[mcm_xyz]

As requested here are quite all my files on the ARM project (stm32f103)

As an addition to the provided schematic the pin PB1 can be connected to +3.3V to enter in boot mode, maybe you should add a jumper to the board...
Please also note that this design can connect directly to USB, no drivers are needed as device registers as HID.

Mihai

[clintonedward]

Oh hehe, so you are the author of the firmware.
So dwalsh62, you are so lucky lol.
(I can't help u with modifying the code as I don't know AVR & don't have the AVR compiler lol)

Sorry mcm_xyz if I also don't read the thread carefully. Was reading it during office hours lol.

[dwalsh62]

Oh hehe, so you are the author of the firmware.
So dwalsh62, you are so lucky lol.
(I can't help u with modifying the code as I don't know AVR & don't have the AVR compiler lol)

Sorry mcm_xyz if I also don't read the thread carefully. Was reading it during office hours lol.

"clintonedward" why would you post to a thread in a technical capacity without reading the thread?

"clintonedward" why would you post comments about code you admittedly know nothing about?

mcm_xyz will be modifying the AVR code to add support for the Z signal input since he is the author of the original AVR project.

As requested here are quite all my files on the ARM project (stm32f103)

As an addition to the provided schematic the pin PB1 can be connected to +3.3V to enter in boot mode, maybe you should add a jumper to the board...
Please also note that this design can connect directly to USB, no drivers are needed as device registers as HID.

Mihai

"mcm_xyz" from the way you were talking you lead people to believe you completed the initial schematic and board layout and have built and tested your prototype but the files you posted are incomplete and it is impossible for it to work based on the packages you have selected.

These files should not have been posted to this thread.

[clintonedward]

"clintonedward" why would you post to a thread in a technical capacity without reading the thread?

"clintonedward" why would you post comments about code you admittedly know nothing about?

...

"mcm_xyz" from the way you were talking you lead people to believe you completed the initial schematic and board layout and have built and tested your prototype but the files you posted are incomplete and it is impossible for it to work based on the packages you have selected.

Oh, actually I understand the code. that's why I can tell you why the author wires PD2 & PD3 & that he is using 6 steps & he is hardcoding the encoder resolution.

Like I said in the previous answer & you never read carefully, I am not going to do it for you. What I can is to show you how to do it but you have to do it by yourself. There is no free lunch.

From the way you talk, I think you know nothing about this subject so I think you should listen & learn rather than bossing us.

mcm_xyz: I think you just ignore this guy. He is an ungrateful kid.

[mcm_xyz]

"clintonedward" why would you post to a thread in a technical capacity without reading the thread?

"clintonedward" why would you post comments about code you admittedly know nothing about?

mcm_xyz will be modifying the AVR code to add support for the Z signal input since he is the author of the original AVR project.



"mcm_xyz" from the way you were talking you lead people to believe you completed the initial schematic and board layout and have built and tested your prototype but the files you posted are incomplete and it is impossible for it to work based on the packages you have selected.

These files should not have been posted to this thread.

Well, I did complete and tested the initial schematic, it still lays on my desk at home and works. But I never did design a board (I started but stopped). So I just build it using test PCBs (the ones with holes) and soldered wires between the connections. SO YES, I TESTED IT AND IT WORKS!

[mcm_xyz]

Oh, actually I understand the code. that's why I can tell you why the author wires PD2 & PD3 & that he is using 6 steps & he is hardcoding the encoder resolution.

Like I said in the previous answer & you never read carefully, I am not going to do it for you. What I can is to show you how to do it but you have to do it by yourself. There is no free lunch.

From the way you talk, I think you know nothing about this subject so I think you should listen & learn rather than bossing us.

mcm_xyz: I think you just ignore this guy. He is an ungrateful kid.

You are almost correct, except that the encoder resolution is not hardcoded, but can be changed with the program I also provide for servo tuning.

http://www.cnczone.com/forums/attach...2&d=1425654504

see in the picture the parameter Encoder PPR (in my case 400)

And for the rest let's just play cool. dwalsh62 says he is able to produce industrial grade PCB's with very well designed power stages. This would be an enormous step forward for the community... I guess

Mihai

[clintonedward]

You are almost correct, except that the encoder resolution is not hardcoded, but can be changed with the program I also provide for servo tuning.

http://www.cnczone.com/forums/attach...2&d=1425654504

see in the picture the parameter Encoder PPR (in my case 400)

And for the rest let's just play cool. dwalsh62 says he is able to produce industrial grade PCB's with very well designed power stages. This would be an enormous step forward for the community... I guess

Mihai

Hehe, I see your point.

Actually no offense, but 6 steps commutation is old & is not so good compare to recent techniques. Besides, I doubt this guy's solution as he knows nothing about the subject. But if it's good for the community then let's see.