cohesion 3d mini board. I have changed the settings in the config file a few times, and adjusted the fastscan setting multiple times but it seems nothing changes the speeds anywhere. Where do i look??
You’ve said you have “changed the settings” and “adjusted the fastscan setting”, but not given any specifics. What have you changed them to?
When you say “it won’t fastscan white space”, what are you trying to engrave? If it’s vectors, it should work, but if it’s images, it has to actually truly be white.
The fast whitespace scan setting needs to be enabled, and then given a speed to go. If that speed is lower than the speed you are engraving at, it won’t make a difference.
Assuming im changing the correct settings on the config file, they were at 30,000mm/min, I upped them to 50,000mm/min, and i have the fast whitespace scan enabled and set at 500mm/sec and Im only engraving at 70mm/sec. Im Raster or “Fill” engraving text.
Have you changed the “default_seek_rate” on the SD card, and increased the maximum per-axis speeds?
Your K40 will not go 50000mm/min (833mm/s) no matter what, so that’s optimistic, but it should be able to get close to 400, depending on how large the gaps between letters are, and what your acceleration is set to.
If you engrave two squares, 100mm apart, you should see the laser speed up between them. Test and tune with something simple like that first.
Yeah i realize the machine will not go that fast, I was just hoping setting it absurdly high i would see some sort of difference.
The default seek rate is currently set at 18,000mm/min, is this what limits the whitespace speed? It seems 18,000mm/min should still be fairly quick.
I just set the speed limits for all axis back to 30,000mm/min.
I have attached a copy of my config file, i dont see anything in it that stands out to me as an issue, but maybe youll see something i dont.
config.txt (25.9 KB)
I should note, this seems to have started when i found the firmware “upgrade” from cohesion that was supposed to allow faster engraving speeds. So I’m not sure what exactly is going on here.
I wrote that - It allows up to 8 power values to be distributed across a single G1 move, meaning you can fit more pixels into the planning buffer. It also increased the rate at which the PWM output values are updated from 1kHz to 4kHz.
I don’t see anything in your config that says it won’t work. When you say “this seems to have started…” were you seeing the fast whitespace speed working before that?
Default seek rate is only for G0 moves. Fast Whitespace uses G1 moves with a feed rate set, and the S value set to 0.
I wasn’t trying to say the firmware is the issue - I just thought it was worth mentioning.
It’s been a few months since I found that firmware update and don’t remember the timeline exactly for if that’s when the white space scan started acting like this.
Most jobs I do are very small so the white space scanning doesn’t really come into play.
I’ve recently been doing some bigger jobs with lots of space so it’s become very apparent.
Are there any other settings in LB I should look at that might effect this function?
It’s really only that one toggle and the speed value under it. Set up a simple job with a pair of filled squares and save the GCode if you want to see if it’s correct.
I did it, and it emits this:
; Scan @ 50 mm/sec, 100% power
M106
G0X95Y140.07
G91
G1X15F3000S1 ; burn 100% at 50mm/sec
G1X65F30000S0 ; travel to the next line at 500mm/sec
G1X15F3000S1 ; burn at 50mm/sec
G1Y0.1S0
G1X-15S1
G1X-65F30000S0
G1X-15F3000S1
G1Y0.1S0
Ok, so i set up a file with two 50mm x 50mm squares a distance away from eachother. I used the same settings as you, 50mm/sec speed, 100% power, and 500mm/sec for whitespace sanning and this is the gcode that is emitted from LB.
; Scan @ 50 mm/sec, 100% power
M106
G0X20.19A392.428
G91
G1X50F3000S1
G1X183.01S0
G1X50S1
G1A0.19S0
G1X-50S1
G1X-183.01S0
Doesnt appear the whitespace scanning is outputting into the code?
Did you enable the switch in the device settings, and set the speed for it?
(switch has to be green for on, red for off)
Do you have your rotary switch on? Why is it emitting A moves? (shouldn’t matter though - whitespace skip should work for either)
Try turning off clustering - it takes a very different path through the code, so it’s possible that with that on, I’m not doing the work for the whitespace skip. I’ll have to check that on my side, and flag that as a bug if this is what’s happening. It should be in there.
That did the trick! Some sort of bug. Thank you for helping me sort it out!
Is the time for the job in “preview” based from the g code? So since it wasn’t generating the fast white scan on the g code the approximate time would have showed longer as well?
It probably doesn’t account for the clustering bug. It’s based on the data the GCode is generated from, not the GCode itself.
You’ll also have to tune the simulation settings (2nd page of the device settings) to match what you have in your controller to get it accurate.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.