[roivai]

There has been a lot of talk about the improved pinout, especially moving the low-side switch controls from PB13-15 to the alternate function locations PA7,PB0,PB1. If I understood the response from ST quoted in this thread, there would be some ~120ns less propagation delay on these lines. I have tried to understand this, and especially how it would affect the performance of the drive so significantly as it is said here. I tried reading the thread (which isn't a one night task any more ) but I haven't found any technical discussion about this.

First, I tried measuring the complementary PWM outputs. I have my controller wired "the wrong way", similarly to Mihai's original schematic, i.e pins PA8-PA10 for high side switches and PB13-PB15 for low side. My drive method (and I think Mihai's too) is something that is referred as Complementary High-Side PWM (referring to this excellent application note by SiLabs: https://www.silabs.com/Support%20Doc...Docs/AN794.pdf figure 9). The STM32 PWM generator has adjustable non-overlapping time and I've set it to be seven clock cycles, which corresponds to 98ns with 72MHz clock. And by measuring the complementary outputs, I see that non-overlapping time is something close to 100ns on both rising and falling edge of the high side control. (My 50MHz scope is on the limits here). Now, if the improved pinout is applied, so that suddenly the low side control would have 120ns less propagation delay, it would imply that both rising and falling edge of the low side control would come 120ns earlier, meaning that the non-overlapping time on the other edge of the PWM would become much larger, like 220ns and on the other edge the non-overlapping time would become negative causing possibly a short circuit in the drive stage. So practically you would have to increase the intentional non-overlapping time in the software to make sure that both controls are not high at the same time. I don't understand how this would be beneficial. The way I see it, the drive signal delays are very nicely balanced with the current schematic.

Secondly, even though it would be so that the alternative pinout would provide the delta of ~120ns towards something that is better, I simply cannot see the significance of it. At least I am driving the PWM at 20kHz. The period is then 50us or 50000ns. So we are talking about timing issues that are 0.24% of the PWM period. I don't know that much about motor control, but I think that's negligible.

Sorry for the long post, but I've been thinking and studying this and I would really appreciate if there was discussion or an explanation why the alternative pinout is better. And even better, a measurement results or scope waveforms from the PWM signals. I can try to capture the scope waveforms from my boards if that is wanted.


Thanks,
-roivai

[Brad43]

Moderator, thanks for making my post visible and shedding light on my posting problem, in the future I'll be more patient when posting and avoid repeat posting.


jimmkas, why there is so much drama and mud-slinging in this project is mind-boggling, why no one can agree to work together instead of constantly butting heads has definitely destroyed any chance of a finished product when there are way too many bosses and getting rid of the only worker without a plan to move forward wasn't a bright move in my opinion.

If I were Mihai, I wouldn't return to this project either, too many wanna-be chiefs and not enough indians, I can't really help, I'm like you, I can use gcc to compile existing code and fix a bugs or two but no experience writing anything from scratch, don't have the time or patience.

websrvr was making an effort to improve the code when no one else was and what you say now about not kicking him out seems contrary to what you said to him earlier by telling him you and no one else wants him here working on it and better that he leaves on his own because I saw no other posts that said he wasn't wanted by anyone but you and I wont debate it with you, because you have no plan I now think you didn't act in the best interest of the project and it would be a waste of time to argue this based on the reply you gave me.

Since you have no real plan and made decisions about the projects future that are not in the projects best interest I'll look for a different solution, after testing in a machine, Mihai's design has definitely got problems and with no plans of development on or for a fixed one the project is pretty much dead where it stands.

The lack of leadership is the only real reason this project is in the state it is in and until that changes this project is a unfortunately a joke.


Pommen, I think you should read through this thread before you actually commit to being part of the project, you're going to need help and based on how things have been it is unlikely you will get any so bear this in mind when you consider the position you are placing yourself in and you might wish to reconsider the burdens of involvement in this project when you would be the sole developer.


KOC62, the motors are labeled Renesance Servo Systems LTD, 36V, 140W, the manuals say Dynetic Systems, part number 170015A on the motor matches the part number in the manual so I am assuming it's a rebrand, there was a lot of that going on in the 90's and early 2000's, date in the manual is August 2006 so I have no real clue as to the age of the motors due to all the different date markings.

I bought 3, 1 was new unopened with a date stamp of Jun-2003 and a date code K06T which I wasn't able to decode, the two used one just needed a good cleaning and black crinkle spray paint from the auto parts store made them look like new without stickers, I wasn't able to save them when I removed them.

Encoder is a Quatum Devices Inc QDM35-1000-5-ES, copyright 2001, 5VDC, 1000CPR (marked on it) but when I was setting up Mach3 I had to use 40000 steps per inch (10 turn ballscrew) which tells me they are 4000CPR so probably mislabeled, even the new unopened one had the same encoder number and date on it so I can't really say when they were actually produced and Renesance Servo Systems doesn't seem to be in business any more because I couldn't find them.

The motors fit the nema23 mounts for bolt positioning but the raised center section is just a little smaller than the raised center section on the nema23 stepper motors, I used an elastic band on the raised section to give it a nice tight fit and this seemed to keep them centered during installation, the manual lists the flange mount as EIC-B35, the other mount option was a horizontal mount EIC-B14 which has legs and ears and would never fit the nema23 mount and there was no mention of nema23 in the manual on any page.


websrvr, I was kinda hoping to use the touch screen I already have but if you give me a link I'll buy the one you recommend, if it's OK with you, I'd prefer to have our discussions in private messages, I'm not interested in being a part of this debauchery.

[Al_The_Man]

1000CPR (marked on it) but when I was setting up Mach3 I had to use 40000 steps per inch (10 turn ballscrew) which tells me they are 4000CPR so probably mislabeled, even the new unopened one had the same encoder number and date on it so I can't really say when they were actually produced and Renesance Servo Systems doesn't seem to be in business any more because I couldn't find them.

.

It is normal for Encoders to be labeled as to their basic quadrature (90°) counts/rev, drives and control systems have the opportunity to use two or all four edges in order to increase the resolution x2 or x4.
Some simply use the basic count.
IOW a 1000p/rev will offer 4000p/rev when used this way.
Al.

[KOC62]

There has been a lot of talk about the improved pinout, especially moving the low-side switch controls from PB13-15 to the alternate function locations PA7,PB0,PB1. If I understood the response from ST quoted in this thread, there would be some ~120ns less propagation delay on these lines. I have tried to understand this, and especially how it would affect the performance of the drive so significantly as it is said here. I tried reading the thread (which isn't a one night task any more ) but I haven't found any technical discussion about this....

Thanks,
-roivai

I too wondered what the technical merits were regarding the PWM pins. I don't have the physical hardware so I can't verify the results. I had just finished printing the dwalsh62 schematic along with the STM Tech Support comments, as in post # 204, and saw your post.

I extracted that their main objection was that mihai's version doesn't get good "field saturation". Supposedly a commercial product could only get about 72%, while the dwalsh62 modified version can approach 92%. Then by choosing, say STM32F103T8U6, STM32F103TBU6 or STM32F103TBU7, you can get "less delay allowing you to achieve a 98% PWM frequency efficiency."
So, there may be some merit to this, but it isn't obvious to me why it works.

[Brad43]

Al_The_Man, I don't get the 90deg angle stuff and thought the signal was either on or off 1000 times per revolution sot basically you're saying I have a 4000cpr encoder and this makes sense as it works out with the steps in Mach3.


jimmkaz, I don't need your explanation why you did what you did or think what you think, I think you made the wrong decision and acted hastily, this is my opinion and you wont be able to change it without a driver or at least an eagle file to make the new design board along with the working software for it.

While I can't make any comments about the new design because I can't test it, the stuff going on here is making the leadshine motor and driver combo look like a better buy without the headaches of this project and all the unknown factors introduced by all the wanna be leaders.

You say Mihai might return but you made decisions affecting the project without a game plan, poor leadership at it's finest, I can understand it if you already arranged with Mihai to return but with nothing, not impressed with your leadership skills and you should have left things to develop before claiming that someone can't or wont solve the problems.

I know the current driver has issues, I've experienced them, I don't know why and it doesn't matter to me why, I'm not part of the project development group, they are the ones who should know why and how to solve them.

While I haven't seen it posted or just didn't realize it, if information is provided by ST then I would think the information is valid and apparently it has been given to several people including Mihai but hey, ST could be talking out of their backsides for some reason for twisted enjoyment, who am I to comment on why when I don't know the what's or why's.

Oh wait, didn't a guy post something in this thread about confirming or at least understanding the information, logic and the why's, wouldn't he be the better person to ask about it?

Lunch is way over, back to the grind.

[KOC62]

Al_The_Man, I don't get the 90deg angle stuff and thought the signal was either on or off 1000 times per revolution....

That is correct. But your encoder has two channels, A and B. If each cycle is 360 degrees (i.e 1 half ON and 1 half OFF) and you displace the B channel by 90 degrees(quadrature) then counting each edge of both channels will give 4 possible transition per cycle. Well, ... that is how I see it.

[Al_The_Man]

Al_The_Man, I don't get the 90deg angle stuff and thought the signal was either on or off 1000 times per revolution sot basically you're saying I have a 4000cpr encoder and this makes sense as it works out with the steps in Mach3.

.

Ok The basic quadrature encoder has two square waves, displaced by 90° (quadrature) , originally the simple usage was to use one rising edge as count (basic count/rev) the other pulse the direction, soon it was observed the resolution could be increased by either using two of the rising edges of the pulses (x2), or every rising and falling edge (x4).
So this became the most common way of increasing the basic count resolution if desired.
What you have is a basic 1000 count encoder that the either the drive or the system takes advantage of the x4 capability, BTW Mach CNC does not count the pulses as the control is not closed back to the Trajectory planner as it is in commercial CNC or motion card etc, but is the responsibility of the drive to use the x4 to increase the resolution and track position.
Al.

[jimmkaz]

Brad43,

After being a member of the forum for less than a day how and why have you come to the conclusion that this thread needs a project manager?
There are already several moderators here including one that stated if the goal of the group or individual was not Open Source to start a new thread.
Now you decide to focus the same disdain for the rules that "Dwalsh62" and "Websrvr" exhibit.
Repeatedly you have told me I am making a mistake and make irrational, disparaging, innuendos why I am the one derailing "Dwalsh62" and "Websrvr" efforts to complete our Open Source Project. When in fact "Dwalsh62" and "Websrvr" have stated on numerous occasions that they do not have the ability to develop or share Open Source firmware for this project.

Your opinions are not well thought out to say the least.

[websrvr]

websrvr, I was kinda hoping to use the touch screen I already have but if you give me a link I'll buy the one you recommend, if it's OK with you, I'd prefer to have our discussions in private messages, I'm not interested in being a part of this debauchery.

There's no need to be private about the reflow oven related stuff and if you don't engage anyone they wont engage you and you can ignore any one you don't wish to have dealings with.

Also, others are answering you with technical details/information regarding some of your questions that wouldn't hurt for you to know about, the information might come in handy later so don't discount it just because you don't understand it now..

KOC62's description is a less technical version that may be easier for you to understand but Al_The_Man's explanation is more accurately described in layman's terms.

Give you a link for a TFT, you go to ebay and you pick the person you want to buy from is your hardest decision to make, I only told you what TFT the app will operate with but I can't tell you specifically what TFT to buy or who to buy it from, I didn't buy mine from ebay and the guy who had them doesn't have any extras anymore so this is what you do:

1. go to ebay.com
2. in search field put "3.95 TFT Uno"
3. ignore the ones priced at $129.xx
4. pick one of the cheap price sellers
5. click "buy-it-now"
6. pay for it
7. contact me when it arrives

KOC62,tonight over drinks I will be discussing the alternate compliment pin issues with an STM32 expert who came highly recommended in the embedded development field to get a better understanding of why it is better, I'll let you know what she says about it tomorrow.

Made more progress this afternoon, after some testing, I can tell you the MI is required on PWM-A and definitely makes one of the current sense lines (which one is dependent on rotational direction) always zero and I'm finding that it's easier to use the 20:1 current sense amplifier (AN271) to calculate and track the actual current using simple whole number math.

As I delve further into the STM32 world more questions arise and I think the answers need to come from someone with experience or knowledgeable in PWM programming.

I've been looking over some of the related servo projects, later this week I'll try incorporating some index code from one of the projects to see if there is really any benefit to using the encoder index in this application since commutation is taken from a table it might serve no purpose other than tracking/reporting true shaft positioning and possibly table synchronization but I could be wrong.

The STMBL code calculates commutation on-the-fly, the code is a little bloated and I'm not sure if it would provide any benefit to do it this way over the lookup table except to save memory but wouldn't an "on-the-fly" solution be slower than a lookup and if so, why does the STMBL code do it this way as the used memory resources are less than 6K according to the allocated variables when more is available.

I've now looked at several servo related projects that seem to do everything differently to achieve the same results and am wondering if all of the functions and methods currently used in the Mihai code are appropriate or correct because there are so many different ways to achieve the same results, shouldn't emphasis be placed on execution speed for optimal performance?

Something else that crossed my mind, how would ST be able to determine from looking at the Mihai code that it's a student related project as the code is not much different than what is generated using the CubeMX software and all of their motor related tutorials rely on the CubeMX software to generate the basic PWM code.

With the information provided by ST engineers it would have been nice if they provided an outline of the firmware requirements for the schematic they created that would give optimal performance for it making everyone's life easier but then again, that would make it too easy if they did all the work.

Something that was recently pointed out to me is the disclaimer embedded in the schematic, does this imply they don't trust the work they provided or is it they can't guarantee the results because they're not providing the firmware and what kind of money did they want to provide the firmware for it as there is no mention of any amount except expensive which is not very descriptive?

[Brad43]

websrvr, bought this one, 14 to 21 days for delivery from china **3 95" TFT LCD Shield Touch Panel Module TF Micro SD for Arduino Uno R3 | eBay


jimmkaz, what rules am I ignoring or complaining about?

Yes I am new here and only because I need to know what you're intention was for this project when you got rid of the only person who seemed to be working on it.

You are the one acting like the leader, publicly announcing who you don't want involved in the project claiming everyone else has the same sentiments but I don't see anyone else saying they didn't want his help but you.

You have*admitted*you have no plan, you just wanted him gone and now the rest of us are made to suffer because you didn't consider the project or those interested in it when you made and attempted to enforce your decision.

Now if you claim you didn't kick him out, you can keep that lie to yourself, you did everything in your power to make it difficult for him to participate, you publicly*announced*that you and everyone else wanted him gone, no one can work under those conditions and to deny this now would make you a liar.

Wow, you're really good at twisting the truth, only you are claiming that websrvr doesn't have the capabilities to develop or share open source software, what I read tells me that he's*unfamiliar*with it but learning about it and from his last post it's looking like he's making some progress.

Instead of helping him you decided it was best to get rid of him and the real reason is unclear*because*I'm seeing a lot of conflicting and twisting of statements from you, this is why your decision to get rid of him was made prematurely and anyone reading your posts can figure this out easily.

It also looks like pommen isn't joining you because he's made no more posts since his last one to websrvr so are you also going to claim this is due to his lack of capability to develop and share open source software?

[websrvr]

websrvr, bought this one, 14 to 21 days for delivery from china **3 95" TFT LCD Shield Touch Panel Module TF Micro SD for Arduino Uno R3 | eBay


jimmkaz, what rules am I ignoring or complaining about?

I advised you not to engage anyone you don't want to talk to and the next thing I see is you arguing with someone you told me you didn't want to talk with so now he's sucked you into his world of drama.

He's been here since 2009 and has only made 14 post and guess where those posts are.

I've been here since 2012, have 43 posts (not counting this one) a few posts in some other threads and around twenty posts in this one.

I don't need you defending me or pommen, I know I never said I couldn't do it and others can read this, I said I had no STM32 experience and needed to learn about it first, he's perverted everything I have said to make himself look better and powerful so my advice is ignore him and go about your own business.

The next bit of nonsense I expect from him is a claim that pommen and I are the same person and I wouldn't put it past him considering his track record.

If you continue dealing with him you're only going to find yourself in some kind of trouble so I am reiterating to you again, just ignore him and you wont have any problems.

[jimmkaz]

This might peek someone's interest. There is a Open Source d.c.servo project on hackaday complete with firmware and a inexpensive encoder that may be a good fit for a Taig sized machine.

https://hackaday.io/project/9433-brushed-dc-servo-drive

[jimmkaz]

Projected cost for a complete servo drive with encoder $40.00

https://www.youtube.com/watch?v=8ZDAxsMe85c

[websrvr]

KOC62, have you ever looked forward to meeting and discussing something of a shared interest with someone and then after meeting with them wished you had sent your nemesis, tonight was one of those nights for me.

Until tonight I thought I only knew one person who left me with the feeling that I had been massaged with a cheese grate but to my surprise, the lady I just spent an hour with makes him seem like an angel in comparison, why are these people so harsh in nature?

Why are these types of people not people friendly?

Also, why do these types of people seem to have sleep disorders or is this just coincidental in these two individuals?

While it was hard to stomach being treated like an infant still in diapers from a woman who could obviously bench-press a harley and I thought I saw the shadow of a mustache growing under her nose or it could just have been the dull lighting.

I swallowed my pride to listen to the explanation along with a visual presentation on a nice four channel 10in digital oscilloscope which showed that the issue cause by the delay in the compliment channel actually affects the time when power is applied to the motor and a magnetic field is generated and it's not just about the delay of the compliments channel alone, it seems that the on time of a normal or high channel must occur with an on time of a low or compliment channel and both remain on for a specified amount of time which is static based on the PWM frequency and it's duty cycle to generate the magnetic field required to make the motor turn, as you increase the delay time that the low or compliments channel turns on it means that both are on simultaneously for a lesser amount of time and as the on time of the compliment channel happens later, the normal or high channel turns off after being on it's specified time the amount of time in which both are not on is increased and when this simultaneous on time is reduced to around 75%, torque is greatly affected, if this is reduced below 60% stuttering occurs and below 20% there is insufficient power in the magnetic field to make the motor turn, hopefully I have explained it correctly.

Being able to see the magnetic field on four channels from a box and these six large coils placed around the stator was something I'd never seen before, I didn't ask questions about the equipment because I didn't want to stick around any longer than was absolutely necessary but noticed a collection of toys like a 144-channel digital signal analyzer, 64-channel digital capture buffer with 30 second playback, an Atmel FPGA/PLC programmer with six sockets on it and all kinds of other test equipment I'd never seen before, several bottles of "Liquid PCB" something I also never saw before, some kind of mini tesla coil looking type of device for an unknown purpose, just tons of toys everywhere, no real sign that a person lived in the place, more like a hidden secret electronics laboratory.

So the explanation with visual presentation made sense but I sure wish it would have been easier to get than the way it was given by the person who gave it, there was definitely no desire to stick around for more conversation and I was glad to quickly exit.

[ger21]

A little advice.

If you don't like what someone says, ignore it.
Every one of you is pushing this thread closer and closer to being permanently closed.

[KOC62]

... why are these people so harsh in nature?

Why are these types of people not people friendly?
.

Fundamentally, a serious lack of genuine love towards all people.... but that is an off topic discussion and can be fleshed out in the "lounge".

OK, the answer does then lie in "field saturation". To get the full torque we need full current. The commutation process thus needs to be accurate with precise timing to get those results.
Thanks for taking the your time to share this understanding with us. Hands-on experience can reinforce these findings. Awww, I only have a dual channel 'scope.

[KOC62]

This might peek someone's interest. There is a Open Source d.c.servo project on hackaday complete with firmware and a inexpensive encoder that may be a good fit for a Taig sized machine....

That may be more up my alley. It is a brushed, not brushless, DC motor project. I'd like a 200V version.

Edit:
It looks like a project by our member James Newton as a team player.

[jimmkaz]

KOC62

James Newton is not the originator of the project however he is rolling out a inexpensive kit (Target price less than $40.00 including a encoder) maybe a high power version is on the horizon also. As seen in the video these guys are serious and not just talking about vaporware.

https://www.youtube.com/watch?v=8ZDAxsMe85c

That may be more up my alley. It is a brushed, not brushless, DC motor project. I'd like a 200V version.

Edit:
It looks like a project by our member James Newton as a team player.

[KOC62]

KOC62

James Newton is not the originator of the project however he is rolling out a inexpensive kit (Target price less than $40.00 including a encoder) maybe a high power version is on the horizon also. As seen in the video these guys are serious and not just talking about vaporware....

Thanks for the correction. I saw his name in one of your links and jumped to conclusions. I was sooo close.

[jimmkaz]

KOC62,

No worries, just wanted to give credit where credit is due.

Thanks for the correction. I saw his name in one of your links and jumped to conclusions. I was sooo close.