synthetos / g2

g2core - The Next Generation
Other
627 stars 296 forks source link

Lost step #238

Closed alessandrolecce closed 7 years ago

alessandrolecce commented 7 years ago

I implemented a close loop to check the position on axis with micrometer measure (fagor CX optical line)...so at the end of a cycle I can check really machine position and tinyg2 position G53. I'm checking that i lost some step so I'm checking if the problem is electronic interference or hardware connection.... Can anyone confirm me that on arduino due nobody lost step and the problem is impossible that come from arduino platform? Is there a way to set high voltage step time?

alessandrolecce commented 7 years ago

I checked for electronic interference and no problems was found.....I think the problem is when dir pin change. Is sure that pin dir change before step are generate? And these is a little pause from dir change state and step generation?

alessandrolecce commented 7 years ago

I can confirm that the problem happen on change dir.....I think I need e little pause on change, so the interruput have time to count dir and step. These is a way to implement it?

aldenhart commented 7 years ago

Can you please provide some information on your setup? What base board are your running - Due? What stepper drivers are you using - gShield, some other shield, external drivers - if so, what make and model? If you are using external drivers are you using any other circuitry? Have you made any changes to the firmware settings, like step frequency, or other changes? Thanks

alessandrolecce commented 7 years ago

I use arduino due. I use a freescale processor at 120 MHz to get step and dir (with interrupt) and pilot a +/-10v analog brushless driver. I tried to change frequency from 500000 to 50000 and actually I improve the performance (less step lost) but some time I lost step anyway...I think I need to put a pause from changing dir and step pulse train.

aldenhart commented 7 years ago

Direction change timing is tricky. Some older drivers require a few microseconds between direction change and the next pulse, but most modern drivers do not. It is challenging to insert these delays without messing up the step timing (motion smoothness) or causing motor stalls in extreme cases. The g2core stepper routines change direction (as needed) at that start of each motion segment, which may or may not have a pulse occurring shortly after. So without modifying the core doe I am not sure how the direction delay is possible.

I am going to close this issue as we do not plan to work on this, but if you make progress please re-open it.

alessandrolecce commented 7 years ago

Just to close with this implementation: