Need a protocol to tweak/tune acceleration and velocity for peak performance.

Over there , I started a thread to get help with my system dropping steps.

[Update: Second things first. for Christmas I fetched one of those mentioned gallons of grape juice, which should've been wine, but it was vinegar as were the other six. Doing my research after the fact I learned I should've had air locks on the jars. I don't have any extra money just lying around for 'wine equipment' so I had put paper towels over the jars and under the lids. We are now well-stocked on vinegar, easily enough to soak my head and those of a few others who need it.]

First things second. I'm back because I cut out a recent project (wood carving) recently (with my stable Mesa-6i25-based machine) which would have taken, I'm guessing, about three hours on the old software-stepping setup I had using the computer's parport, but took 3X that on the new setup. (I add here that a forum search for "optimize acceleration" turned up next-to-nil.)

The problem with extended cutout times is that I live out in forest country where electrical power is interrupted regularly.  The longer the time, the higher the risk.

Although F120 ipm is called for in the G-code, in practice the feedrate seems to hover between say 30-and-60.  The model is elevation/terrain data being cut in a series of left-to-right-to-left moves (that is a sequence of G1 moves between XZ-pairs for a fixed Y, after which Y is incremented and a new sequence commanded). Steps in Y are typ. 1/4-to-1/5 mm and steps between XZ pairs typ. around 0.01 inch.  I suspect this is not like "ordinary" machining.

I will say that performance under my original software-stepping setup cracked along at, if memory serves, perhaps 80-90 ipm for commanded 120 ipm, and in any event always managed to hit the commanded velocity of 120 on smooth "straightaways." 

My current setup can't do that, and I know it's a more capable system.

I used PncConf to Test Axis again to increase stepper velocities/accelerations until I got scared when the motors stalled and backed off some. (They ended up in the 240ipm/165ips2 range.)  However when I ran the G-code (with the CNC machine off), the backplot still showed those low velocities.)

Returning to this thread to see what the heck I must have done, I guess  I selected for stability/reliability/predictability over performance.

But I'm not exactly sure.  It could be that my particular G-codes are doomed to slow execution by the nature of the surfaces being cut, but I would like to know I'm getting the best performance possible.

% uname -a
Linux clunc 4.19.0-20-rt-amd64 #1 SMP PREEMPT RT Debian 4.19.235-1 (2022-03-17) x86_64 GNU/Linux

The values in my .ini file (clunc.ini, attached) seem reasonable.

% latency-histogram --nobase --sbinsize 1000
The histogram is attached as well, and strikes me as very good.

I am looking for a tuning protocol that will give me confidence that I have optimal performance.

I thank you, again, for giving your time to help.

 

The first thought upon waking was, "I bet this would be in the documentation..." (I was asleep when I first posted.)
linuxcnc.org/docs/stable/html/motion/tweaking-steppers.html
particularly,
linuxcnc.org/docs/stable/html/motion/twe...rs.html#_no_guessing

Well, yes, but it is silent on Mesa cards, leaving me to wonder: "Is optimal step-timing the same whether steps are generated by software or hardware?"

I have to reflect: "No, because step rate can be faster when hardware-generated because CPU overhead is less of a factor." In fact, inspecting the spreadsheet download available at the latter link, it seems that BASE_PERIOD is a key part of the calculation, but Mesa configuration does not use a base thread.

So I did shine my flashlight around, but didn't recognize what I saw.

I thought of one other thing to try.

My test G-code is about 100,000 lines extracted from the middle of the last project which struggled to meet 30ipm in the "complicated" topography regions whereas 120ipm was commanded.

I will generate a similarly sized and similar alternative for a run of straight lines over "flat ground" and see if the commanded velocities are met, and a second alternative where the straight lines are broken up into a sequence of steps 0.01" apart and compare.

...and THIS--which has been in my preamble so long--it didn't occur to me to mention it:
  G64 P0.001

From here : 
"G64 P- Q- - is a way to fine tune your system for best compromise between speed and accuracy. The P- tolerance means that the actual path will be no more than P- away from the programmed endpoint. The velocity will be reduced if needed to maintain the path. In addition, when you activate G64 P- Q- it turns on the naive cam detector; when there are a series of linear XYZ feed moves at the same feed rate that are less than Q- away from being collinear, they are collapsed into a single linear move. "

(I may have set this to P0.01 in a test, but now can't recall, and I've never set Q.  Certainly, if I do get around to making a test program composed of a moving along a straight line in X between fixed points (X,Z=0), setting Q should combine them, all, into a single straight line.)

Sorry, Tommy, I overwrote you.

Regarding the quality of the stepper motors, I had actually paid extra to get Japanese steppers, but discovered a year after importation that the Chinese assembler [Qiang Da] had switched in cheep Chinese copies. After one failed and I reported it, asking for restitution, I was informed I should not be running the machine 24 hours without rest, and anyway, it was my fault for not taking the sheet-metal covers off the motors on delivery to verify I had not been cheated![1] Caveat emptor. And id erit quod emisti.

Still it is good news that replacing them with what I originally ordered will likely offer improved performance.

As it is my steplen and stepspace are set at 5000, and I haven't even tried reducing them.  I have to try, if only to make a note: "NEVER, EVER, do that AGAIN!"

I just took a look at ' dmap2gcode ', and based on my experience with Scorch's other projects, I'll definitely give it a try.  It could be that something in my current CAM software, MeshCAM, is contributing to the slowness. (I wonder that dmap2gode will have the sophistication of MC regarding things like tool libraries and path smoothing, but I'll find out.)

Thank you for the ideas!  I'm sure I feel like a lot of others here; sometimes I feel utterly alone, like on a desert island. I've tried everything I can think of: I've scoured every sq. in. of the island, and come to this forum, the beach, to throw a bottle with a note in it into the surf.

What encouragement to come back and see a response. Absolutely makes my day.

[1] If you watch a number of videos posted by the yang gweidz (foreign devils) who have lived in China for extended periods, you will conclude this is not an uncommon attitude.

 

I've got it back to what I consider "historical" performance: 80-90ipm, actual, for 120ipm, commanded, and 120ipm on straightaways.  I did allofthese:
* downgraded G64 P0.001 to G64 P0.005 Q0.005[1]
* HALVED (radically) DIRSETUP and DIRHOLD for each stepper in the .ini file from 10000 to 5000[2]
* HALVED (radicatlly) STEPLEN and STEPSPACE for each stepper in the .ini file from 5000 to 2500[2]
* more than QUADRUPLED (radically) MAX_ACCELERATION for each stepper in the .ini file from 20 to 90[3]

I am off to give 'dmap2gcode' a whirl.  Before any of these, I had downgraded the resolution of the model to be cut, so as not to put any strain on the kinematics. That resulted in a model with an obviously inferior look. I will go back and re-generate a model with higher resolution.

Thanks all.

[1] I won't know if the quality will be acceptable yet[4], but given that I was calling for stepover distances of ~0.01 inch, it seemed overkill to require it to stay within 0.001 inch. I give this a lot of the credit.
[2] I expected these to fail because of the pedigree of the motors, but there has so far been no hint of instability. A lot of credit here too, to the motors.
[3] This was after testing real performance with TestAxis inside PncConf. Again, the motors stood up.
[4] Testing was done on an extract of a model other than a topographic map so the acid test will be later. I am optimistic.

I regret to say that as of v12 Dmap2gcode has a non-starter for me; my current CAM software provides the capability to include/exclude regions to be machined, either by drawing on the model or by loading DXF files. This is chiefly important for saving running time for circular projects.

The reason why you are not hitting your commanded velocity is simply a function of physics.
In a simple linear move linuxcnc will accellerate at max_acceleration in the ini file until the commanded speed is reached. THen it travels at constant velocity and finally decellrates at max_acceleration to a stop.
This is what is called trapezoidal acceleration and you can see it if you use halscope.

But if the segment is too short to reach commanded speed, the profile is truncated to a triangle. Also the lookahead motion controller takes into account the physics of the next segment and may further truncate the velocities so the next segment can be honoured.

bUt in many cases generated short segments are not really necessary to produce a pleasing result. There are some settings in the ini file that can be used to smooth out motion if the generated gcode is poor.

 

...There are some settings in the ini file that can be used to smooth out motion if the generated gcode is poor.
 

Can you expand on this? I'm facing this exact issue and while I've yet to walk out to my machine and test out the previously mentioned G64 Pn codes, if there's other wins to be had, can you direct us to them?