cncsnw wrote: ↑Mon Oct 07, 2024 5:23 pm
ashesman wrote:Little test programs seem to be ok, but bigger programs that are harder to show don't.
Are you saying that if you select and copy just 3-5 seconds of movement out of a big program -- movement that consistently exhibits the problem -- and paste that into a separate file to run as a test program, then the problem does not occur?
If so, that in itself could be a clue as to what is going on. I cannot meaningfully speculate on it, as I do not know enough about the low-level code that is used when running in position mode: e.g. how the MPU queues up and clocks out motion pulses at the correct rate, based on the stream of motion commands coming down from CNC12.
I tried making small example programs manually to reproduce what I see when that bigger program is running, but they seem to run fine! I tried stripping down the bigger program, but it seemed to come right the closer I got to a smaller program. But, I really don't know how to make a consistent program to reproduce it. I have burnt some serious hours fluffing around with this so far. Enough that I threw my hands up and just walked away from it the other day!
cncsnw wrote:
One subtle point that I think has been overlooked in some of the responses is that -- if I understand your description correctly -- the "flat spots" are in the velocity vs. time graph; not position vs. time. In other words, they are pauses in acceleration, not pauses in motion. This says that the MPU has continued to clock out motion pulses at a constant rate, but appears to have momentarily ceased changing the rate.
The graphs are position count vs time. Suddenly the pulse train stops counting which means the controller said stop moving completely, without any decel, then start counting again without accel.
I feel like an Oak loaded with the files from my report, asked to do the same movements should produce the same stepping output, but maybe I am oversimplifying the difficulty of reproducing my setup.
I have really muddled this post up by discussing two issues I have seen. The flat spots in pulses, and harsh transitions between g code moves that should otherwise be smooth. The later issue is the one most conversation has been about, and is the one I struggle to reproduce. The first issue is covered entirely in my first post and is 100% reproducible (on my machine).
cncsnw wrote:
I would not rule out the possibility that the issue is in the drive's response to the incoming pulses. If a person with time, resources and knowledge had a segment of G code that consistently showed the problem, then they could use the CNC12/MPU "debug dump" feature to capture a short interval (maybe one second?) of the low-level data, to see what the outgoing pulse stream looks like. That could be compared to the Delta data plot, to see if the pause in acceleration was commanded from the MPU or not.
I think the drives have been ruled out. Turning on/of smoothing makes the problem go away immediately, turning it back on makes it come back. I have not seen one example where the drives haven't done exactly what they were told to do.
cncsnw wrote:
Regarding Keith's comment about doing a factory reset to defaults before programming a drive: I realize you already posted a parameter dump from the affected drive, so you assume that a support technician will take the time to do a line-by-line comparison of your parameters with a known-good parameter set. Keith's position is presumably that, because everyone's time is limited, they should not have to do that.
I didn't attach the file with the intention of someone else having to do a comparison. Just so it could be loaded directly into a drive to reproduce. I have done a comparison myself, several times. The delta software allows a comparison against default values with a few clicks. The Centroid recommended parameters are set as they should be. The only other difference are gain tuning values and some special values the drive seems to change itself.