motion is REALLY slow when the intent was really fast.

More
12 Jun 2021 18:59 #211881 by Doogie
So I just got LinuxCNC/Remora doing spindle PWM control for M3,M4,M5 and Sxxxx and tried to test doing an engraving on the laser cutter but OMG the speed is supposed to be 200mm/s but it's crawling instead.
Any ideas from this GCode clipped from the start of the file?

Note, I'm using Smoothware post processing from LightBurn because otherwise LightBurn's LinuxCNC postProc was using M106 for the laser control.

; LightBurn 0.9.24
; Smoothieware device profile, absolute coords
; Bounds: X40.48 Y52.1 to X118.38 Y97.2

;USER START SCRIPT
G64 P0.010 Q0.015 ; Path Blending to help fix rounded corners
;USER START SCRIPT

G00 G17 G40 G21 G54
G90
M3
; Image @ 200 mm/sec, 20% power
M107
G0X118.38Y97.2
; Layer C02
G91
G1X-5F12000S0
G1X-0.1S48.591
G1X-0.1S43.772
G1X-0.1S40.358
G1X-0.1S39.354
G1X-0.1S38.551
G1X-0.1S36.945
G1X-0.1S36.142
G1X-0.1S36.945
G1X-0.1S37.949
G1X-0.1S37.547
G1X-0.1S36.744
G1X-0.2S37.146
G1X-0.1S36.543
G1X-0.1S36.945
G1X-0.1S40.157
G1X-0.1S43.972
G1X-0.1S44.976
G1X-0.1S45.579
G1X-0.1S43.169
G1X-0.1S40.961
G1X-0.1S39.957
G1X-0.1S38.953
G1X-0.1S37.748
G1X-0.1S37.949
G1X-0.2S38.953
G1X-0.1S38.752
G1X-0.1S39.154
G1X-0.1S39.555
G1X-0.1S40.358
Attachments:

Please Log in or Create an account to join the conversation.

More
12 Jun 2021 22:46 - 12 Jun 2021 22:46 #211902 by Doogie
It was mentioned in irc to remove the Sxxx commands and see what it does and it does run much faster without the spindle comamnds on the motion lines. I don't know why that is yet but it could be why LightBurn puts the laser power on the M106 command when you pick LinuxCNC for the GCode post processor.

I'm now trying to figure out what signal to reference in the M106 command I had previously used for 3D printing part cooling fan:
#!/usr/bin/env python2

# Note! Change the above "python2" to "python" is not using Arch Linux

# M code to set Fan speed
# M106 in your G code program will run the python code in this file, 
# passing the P and Q variables as command line arguments.

import sys
import hal

Mcode = 'M106'
usage = 'Fan speed'
pin = 'SP'
SP_signal = 'ext0-cooling-SP'

h = hal.component(Mcode)

if( len(sys.argv) < 2 ):
    print "Usage: " + Mcode + " Pn - where n is the " + usage
    quit()

P and Q command line arguments
Q = sys.argv[2]

#Reprap fan speed is between 0 and 255 (0% to 100%) therefore we need to scale the setpoint

#SP = (float(P) / 255) * 100
SP = P

print 'Setting ' + usage + ' to ' + str(SP) + '%'

h.newpin(pin, hal.HAL_FLOAT, hal.HAL_OUT)
hal.connect(Mcode + '.' + pin, SP_signal)

h[pin] = SP
Last edit: 12 Jun 2021 22:46 by Doogie.

Please Log in or Create an account to join the conversation.

More
12 Jun 2021 23:01 #211904 by tommylight
The following user(s) said Thank You: Doogie

Please Log in or Create an account to join the conversation.

More
13 Jun 2021 03:41 #211913 by Doogie
Using M106 as an external command is a non-starter as it'll be too slow. I trimmed a sample M106 file down to nothing but defining the pre-processor( #!/usr/bin/env python2 ) and it was still very slow.
Replacing with bash(#!/bin/bash) and nothing else was faster but still VERY slow.

Back to figuring out if there is a way to make the standard spindle system work at speed or it was mentioned the M68 might be helpful.
linuxcnc.org/docs/html/gcode/m-code.html#mcode:m62-m65

Please Log in or Create an account to join the conversation.

More
13 Jun 2021 05:50 #211916 by phillc54
I think the M67 that Tommy used in thread he linked to for you would be better.
The following user(s) said Thank You: Doogie

Please Log in or Create an account to join the conversation.

More
13 Jun 2021 06:50 - 13 Jun 2021 06:56 #211918 by Doogie
I did a search and replace of "S" in the Gcode with "M67 E0 Q" then swapped in motion.analog-out-00 into the scaling connections
net spindle-speed-scale motion.analog-out-00 => scale.0.in

and speed has greatly improved. I don't know if I can reach 300mm/s which the machine is supposed to be capable of but hitting 200mm/s shouldn't be too limiting.

configs attached if anyone wants to look. The first 'etch' didn't look like anything but did look like laser power was varying so it could be some power level or speed settings. More testing on that front but at least it looks like the pwm control is there at a reasonable speed.
And possibly back to looking at doing inline manipulation of the gcode to create the M67 E0 Sxxxx entries.
Attachments:
Last edit: 13 Jun 2021 06:56 by Doogie.

Please Log in or Create an account to join the conversation.

More
13 Jun 2021 19:04 - 13 Jun 2021 19:42 #211961 by Doogie
Since the CAM software for laser cutting I'm using, LightBurn, generates M106 Sxxxx lines for laser power control with the LinuxCNC machine selection I will try the following substitutions.
M106 S0 -> M68 E0 Q0
M106 S -> M67 E0 Q

as this was recommended on one of the many many pages I'd run across in looking for ways to get the standard spindle control mechanisms to work.
Last edit: 13 Jun 2021 19:42 by Doogie.

Please Log in or Create an account to join the conversation.

More
14 Jun 2021 04:24 #211995 by Doogie
I seem to have spoken too soon. While the motion speed is far better than the literal snail pace it was moving it is FAR slower than the commanded 200mm/s and I think it has to do with LinuxCNC parsing of the M67 commands.

Does this make any sense? I have LinuxCNC on an rPi4 with Remora firmware but I don't think Remora has anything to do with the performance issues I'm seeing.

If I run a raster engraving file where I stripped off the Sxxx.xxx from all motion commands it runs purely on speed setting and the LinuxCNC DRO is showing Velocity pegged at 9000 and it reaches into the low 110 mm/s for the X axis which is the direction of scanning motion. The CAM software was set to 200mm/s and the motion is smooth on Axis and when the machine motors are powered.

But then I add the M67 E0 Qxxx.xxx to every line and the motion performance drops significantly and is choppy even on the display.
Velocity is all over the place but mostly stays well below 5000. I've tried this with hardware powered and unpowered and the results
are the same, with no Spindle processing(Sxxxx) the motion is fast and smooth, with M67 E0 Qxxx.xxx the motions is far slower and choppy.

I even went into my hal file and commented out all the scaling and the call into the hardware/Remora to set the laser PWM so it's not Remora slowing this down and seems to point to internal processing even though the CPUs are under 50% utilizations(2 of them). When there's no Sxxx processing the 2 cpu's are at/under 40% utilization.

Please Log in or Create an account to join the conversation.

More
14 Jun 2021 04:46 #211996 by Doogie
I just tried removing any spaces from the GCode lines and performance got worst.
G1X-0.1M67 E0 Q45.579 becam G1X-0.1M67E0Q45.579

Then I tried all spaces:
G1X-0.1M67 E0 Q45.579 becam G1X-0.1 M67 E0 Q45.579
and it was better than no spaces but worst than the original I'd started with were there was no space between X movment and M67 command but spaces for M67 parameters.
G1X-0.1M67 E0 Q45.579

I was not expecting performance issues on GCode parsing.

Please Log in or Create an account to join the conversation.

Time to create page: 0.152 seconds
Powered by Kunena Forum