I just finished the one pic and going to reflash RC8 and do another to see if it’s as pronounced. And intervals were exactly every second corresponding with the refresh.
Edit: No stuttering on RC8 at all. I’ll likely run a few more tests but prefer the non-grindy movements. That said, the picture I did with V1.1 turned out pretty nice with no evidence of issue from the weird movements.
What resolution are you using?
I have flashed the board at least 8 times now with different settings. Turns out the resolution is so high, commands are .18mm apart it is flooding the controller and our max speed is about 40-50mm/s I think. I see no difference above there at least and the messing with the buffer seems to confirm, larger buffer fast movements, smaller buffer drastically slower. If the buffer is less that half full slowdown kicks in.
So many variables, but the .18 resolution seems to be the biggest issue because of the shear volume of commands.
The min for our lasers is about .18mm, typical is about .23. Just changing the resolution to .23mm gives about half the file size and a much less pronounced stutter.
Well…Here is a new one. The feedrate doesn’t work in that program.
The first F command needs to be at the end of a g0 or g1 command to work.
So far an f1000, works perfect not stuttering at all with a resolution of .23mm
Still testing more.
F1300 seems to be max. I am going to put this in the img2gcode thread.
I’m using 0.1mm resolution and running a M140 2W laser right now. I also bought PEP5 after testing it and the filesize is dramatically smaller. The current burn is going smooth and looks perfect as well under RC8. It’s almost done so I’ll give a better look at the results soon.
I wound up going back to RC6 on my printer. Just too many goofy things in 1.1.0 even with the bugfix-1.1.x branch 
When it worked it worked great and I got some of the best print quality I’ve seen off my machine.
But it was just doing too many goofy things. Even with UBL disabled it was doing stuff like randomly not printing the 1st layer at all. Same gcode, but would get different results when I’d run it 3 times in a row
And with UBL things went all kinds of crazy, trying to print 20mm above the bed, or slamming the print head into the bed.
After a week of messing with it and applying every fix that came across I finally decided enough was enough and went back to my working reliable RC6 config for now.
Maybe you missed a setting or something. I have this on 4 of my printers and 1 of the MPCNC’s that is printing and it hasn’t had an issue yet. Rc6 is pretty far back some of the movement equations have been fixed since then.
Went over all the settings several times. Like I said it worked great when it worked. I suspect most of the issues are with auto level which I don’t use on my MPCNC and I believe you don’t use on your printers…but on my printer I rely on because the bed shifts far too often ( working on some mechanical upgrades to solve that though.) Most of the issues I had were with the new UBL which I have to say really doesn’t seem to be release ready. But even with the older leveling code things were just not right.
The way it would sometimes skip the first layer and sometimes not from the same gcode really scares me. I can’t think of any setting that should cause that kind of thing to happen.
There does seem to be a lot of improvement on the basic movement stuff. But there were enough rough edges that I’m stepping back from 1.1 for now.
And yeah…RC6 is pretty old…but it’s a case of “if it ain’t broke don’t fix it” 
RC7 had too many issues and it scared me from trying RC8. The printer works and is reliable on RC6 and after a week of fighting with 1.1.x variants and getting fed up it was just a matter of going back to what was working fine before so I can finish printing the parts I need to rebuild my Y axis.
Once that’s done I’ll probably dig back in on 1.1.x…but watching the development the past week or so I’m a bit wary now. There doesn’t seem to be much vetting on new code before it gets pushed into the main branch. The way they kept adding new features to RC’s I’m not surprised that the “stable” release isn’t that stable. They really need to get better about respecting the RC’s and doing feature freezes to get stable releases.
Yeah the UBL stuff came in really late and is still under heavy development.
In today’s bug fix 1.1.0 branch programmers committed spindle and laser m3 m4 m5 support!
Too early to try?
I haven’t even gotten the all of the 1.1.0-1 firmwares out, I can’t release every bugfix commit. If I release a bad firmware I get swamped with hundreds of personal emails and forum post for weeks.
I will give it a shot after I get these released and figure out a good relay for the 120V/220v control. Could help not to have to swap firmwares for the laser though.
More info, reference for later.
Interesting link… looking at that, I wonder if some of the movement and laser vs LCD conflict is in us using pin 44? I’m not very knowledgeable in the way of the RAMPS board but am going to look at using another pin and see if things resolve. Maybe this has been addressed/looked at before?
TIMER5C Pin 44 LCD stepper motor current XY PWM
Whoa, good catch. Need to track down where the other pins break out to.
I did try it yesterday without remapping and it was still on pin 9 and same issues though.
Pin 6. No more stutter at all! It’s a Servo pin as per pics.
I disabled the declaration in the Pins_Ramps.h (not sure if necessary, but why not…should avoid any redundant calls to the pin?)
[attachment file=33848]
Mapped D9 to D6 which will output PWM signals.
[attachment file=33849]
And measured the Voltage using the Temperature-> Fan Speed menu as per original instructions. It measured out perfectly so hooked positive line to Pin 6 and Ground to … Ground. Red = Pos, Blk = Neg
[attachment file=33850]
Currently burning a largish image with no stuttering.
So Awesome! I need to put this information somewhere, and probably change the firmware. Man that is great.
Did you see my post in the img2gcode thread about the speed not working on a separate line?
So if we use the new bugfix laser/spindle enabled firmware, and map it to this pin, one firmware can handle all the functions without needing to swap…That is so awesome, but…that means I have to start the testing all over again. So worth it though, I am excited about this.
I freaking love that the machine just keeps getting better, and easier to use and it is all for free!!! Free upgrades how often does that happen?
I did see it but I’m running slower than that anyway so haven’t tested yet. I do notice some delay on long burns so am going to load a different file with more lengthy laser-on time to see if it’s an issue or just a random thingy. Will report back soon.