[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.