Allow infinite acceleration/speed on one axis

Here it is, but the hal file will not work for you as it uses quadrature output for driving l298 IC's.
You can use the PWM part from it and paste it in your hal file.
Dang can not attach from the tablet, will do as soon as i get to my laptop.

All,

Based on your recommendations yesterday I ran some tests last night. I need more time to test the further this weekend, but wanted to present my findings now to get your input on what's happening.

I am leaning heavily on Todd's statement of:
"I just did a little experimenting with M67 in a simulation and it works fine if... and this is a BIG IF. The distance between the changes of M67 settings has to be long enough to take more than 1 servo-period to execute at the commanded speed."

So I ran test files, while increasing the distance between M67 changes as follows:

Test #1:
A.) M67 command spacing set at 0.15mm



This output is the same as I have been testing in my previous posts, and shows the velocity reduction I experienced while trying M67 commands. It looks much as expected based on my history with the issue. Note: I don't often use halscope, so I'm not so good with it. The only way I was able to see the graphs move was to use the run mode "Roll" and then manually click "Stop". I tried to stop the graphs in roughly the same place each run to get consistent results.

B.) M67 command spacing set at 0.30mm



More or less the same as 0.15mm spacing...

C.) 0.6mm spacing



D.) 1.2mm spacing



So at this point I stop and evaluate the data (images) to see if anything makes sense. I see that in each case my velocity starts dropping before any M67 commands occur, i.e. the red line begins sloping down before the blue line goes up. I don't really know what that means, although I can take a few guesses which are likely all incorrect (Linux is expecting to have to slow down to issue M67 command so it starts slowing down before the command, etc).

Its possible that the I have not yet spaced my commands far enough apart to get outside of the "1 servo period" distance. I have never had reason to tweak my servo period, so perhaps its set extremely high and is causing my results. In the previous tests I was running at a feed rate of 420mm/min. If I make an educated guess as to the highest allowable servo period for 1.2mm M67 spacing I get (420mm/min = 1.2mm in ~ 0.17 sec) 0.17 sec = 1.7 x10^8 ns. My .ini file shows:
[EMCMOT]
EMCMOT = motmod
COMM_TIMEOUT = 1.0
COMM_WAIT = 0.010
BASE_PERIOD = 100000
SERVO_PERIOD = 1000000

and I think those values are in nanoseconds, meaning my servo period is 1.0 x10^6 ns. Perhaps I am wrong or confused in these numbers somehow, but if they are correct I should be able to attain a ( 420mm/min ~ 0.007mm in 1 nanosecond) 0.007mm spacing on M67 commands (note that I am testing a speed much lower than your 300in/min so it makes sense that I could hold smaller spacing then you are able to, so at least this seems accurate). Unfortunately I don't seem to be able to hold these spacing values, so perhaps something else is amiss here? Any thoughts on the above are welcome.

Test #2:
So at this point I wanted a break, so I decided to investigate the use of M68 vs M67, and received the following graph:



This yielded (what is now the new) worst results I have gotten in any testing. The velocity was abysmal, staying mostly near 100mm/min and often dropping near zero and never really getting close to 420mm/min as the M67 testing would always hit prior to issuing M67 commands. This leads me to think it is issuing the M68 commands as received, and that (at least in this case) M68 is directly affecting axis velocity in a big way.

I did not do further testing with M68 because the axis never got to 420mm/min at any point during my initial test.

Test #3:
I still have on my list to do a check of XYZA system as a simple three axis system using one of the 'normal' axes to control the laser via step pulses, to see if it increases performance since it was pointed out that XYZA will fall back to one line look ahead.

I attached some of the g-code/config files I used for the tests if someone has time to look at them and offer any guidance or tips for improvement based on them.

Could you try riposting the G-code file. It didn't come through.

For Halscope, you have to set a signal source as the trigger, then set the trigger level to something appropriate.
linuxcnc.org/docs/html/hal/tutorial.html#_triggering

At 420mm/min (7mm/sec) you should be good down to about 0.007mm resolution. I think the key to what might be wrong may lie in your g-code.

Todd,

For the g-code, I started with my base file I'd been testing with before and slowly adjusted it from there (mostly removing every other line of code to double the distance until I started to need more lines of code so that it would adjust the M67 values a bit more (because to many lines of code had been deleted).

Posted here, thanks for taking a look.

On a slightly unrelated note, when I was testing I noticed that the behavior of M67 was not as I expected from the description in the doccumentation. When I had an M67 command on the same line as a commanded move, I would have expected the M67 command to be executed at the end of that move or the start of the next (or maybe the value of the output is interpolated through the duration of the move), but what actually happens is that M67 is activated at the beginning of the move in the line commanded. So if the machine is a X0 and G1X1M67E1Q0 is commanded, the output is set to 1 and the machine BEGINS the move to X1.

so is the same as and that is not the same as this, which gives the result I would have expected from the 2nd bit of code.

I was going to look into this after sorting through the velocity problem, but it seems you had the same question as me. (When exactly the M67 command is implemented?) To keep it easier to read/follow I'll probably adjust my script to set the M67 command one line before the movement line, so that the two are never on the same line, to help avoid confusion.

Probably as your first example:

M67 E## Q###
G1 X## Y##
etc