Welcome to the SeeMeCNC Community

https://github.com/626Pilot/KISSCoast" onclick="window.open(this.href);return false;

Full instructions there. The idea is that we figure out a point some number of millimeters back from the end of a path (just before a de-string) and then stop extruding there. If that point is in the middle of a segment, we use linear interpolation to cut the segment at the correct point, and extrusion stops there. Separate values for normal and prime pillar paths are used because prime pillars are over-extruded by KISSlicer, leading to nasty blobs and filament being dragged all over the place.

EDIT: Multiprocessing support has been added. It is now EXPONENTIALLY faster! Time to process a ~15MB file has been reduced from 6+ minutes to under five seconds on my 2012-era machine.

I got a decent reduction with these settings, and by commenting out the prime command on Select New Ext & Warm: I think there is room to find more improvement by modifying the coast and primePillarCoast values.

I currently have no plans to rewrite this in Perl/LISP/C/whatever you think is cooler than PHP. If you are running Mac OS X, you already have the PHP interpreter installed. Windows, you'll have to find it (see instructions). Linux, if you have PHP installed, you're already good - otherwise, type 'sudo apt-get install php-cli' (you only need the command-line interpreter) or look for 'php-cli' or just 'php' in your package manager. You don't need to have a web server installed.

This is alpha-quality software. I'm looking for feedback from experienced users who are willing to experiment. I have verified that it processes the G-code like it's supposed to, but then again, this is the first day I'm using it.

How about Ruby? Isn't that what the cool kids are doing these days?

*runs*




g.

Seriously run Gene, run. The cool kids in the Boston high tech corridor are all over Python for a lot of different types of app development. If it's good enough for google...

Gods damned script kiddies. Hmmmph!

Nice work, 'pilot. How about a c# plugin for MatterSlice?

Mumbles to myself as i paw through my PDP-10 punchcard fortran program decks for explosive charge placement for tunneling and minerals extraction......

I thought Swift was the new hotness with the kids these days....

Windshadow wrote:Mumbles to myself as i paw through my PDP-10 punchcard fortran program decks for explosive charge placement for tunneling and minerals extraction......

That is the coolest sentence I've red on these forums all year.

I thought Swift was the new hotness with the kids these days....

Every coder has their pet language, and a litany of religious arguments about why it's The One True Language. The only languages I'm current on are C++ and PHP, and between the two, PHP makes it WAY easier to do string processing.

This program can fix up a small calibration object's G-code in about six seconds on my computer, but something large (~20MB file) seems to take many minutes to complete. I'm looking into whether hhvm (a JIT compiler for PHP) can speed this up. I'm also thinking about how to multi-thread it as well. Four or eight cores will obviously run a lot faster than just one.

If you haven't already, check out the 2011 and 2014 variants of C++ and the stdlib support for the string class, regex, shared pointers and the like. It really looks like the C++ committee have bent over backwards over the last 15 years to make C++ more like, well, Java. There. I said it

Result is it's pretty good with all the modern language features like reference counting pointers, lambdas, late binding and so on sitting on top of the good old standard we grew to know and love/hate. The trick seems to be in learning what of the new features are more trouble than they're worth - I still find the old sprintf to be a million times more intuitive than all that bullsh1t with streams, for example...

Speaking of languages people are into, I set my ME friend on Python and they've spent a week learning from the ground up (including OOP concepts they've never considered) and they now have a partially complete application for managimg swiss style tournaments with a pretty nice GUI.

The most experience this person had had before this was matlab/labview

Captain Starfish wrote:If you haven't already, check out the 2011 and 2014 variants of C++ and the stdlib support for the string class, regex, shared pointers and the like. It really looks like the C++ committee have bent over backwards over the last 15 years to make C++ more like, well, Java. There. I said it

From what I recall, C++ and Java are both a lot more complicated to do string processing with than PHP. They should theoretically run faster, but I don't know by how much. This kind of algorithm requires lots of string-scanning, which PHP already does internally in C++. Iterating through and writing out tens of thousands of lines (about 50,000 in my test file) completes in seconds. It's the byte-by-byte search for substrings that slows things down so much.

PHP for Ubuntu is distributed without threading support, which is a super dumb decision in my opinion. I'm altering the code to do multiprocessing instead (supervisor forks a bunch of processes). That should work on every OS, regardless of whether it uses pthreads or some other implementation. I already have the chunking algorithm perfected. It splits up the file in to a bunch of approximately equal-length chunks, one for every "thread" (actually, every process). It goes where it thinks a chunk should end, and then keeps scanning until it hits the end of a destring command. That way, it won't use chunk boundaries that would end up splitting the file in the middle of a path.

After this is all working and I've proven to myself that it's Much Better to have coast functionality, I'll submit this code on the KISSlicer forums as a proof-of-concept, and whenever the developer comes back from outer space maybe he'll see it and integrate it into the main program. It would naturally run exponentially faster in there, because KS already knows exactly where every last de-string command is going to go. In the mean time (which could be months/years/infinity), if someone wants to try porting the code to C++ or Java, they will have my blessing and support.

I would not bother porting to Python unless it has a JIT compiler. I sincerely doubt it would run much faster, if at all. In fact, I tried a PHP JIT compiler (hhvm) and it actually makes it take twice as long to run.

626Pilot, give Python a look. I used it to write a small program to convert all the 00index.txt files on the Garbo ftp archive into index.html files. Took all of about 2 seconds. Blew my mind.
It's VERY good at string processing.

g.

626Pilot wrote:

Windshadow wrote:Mumbles to myself as i paw through my PDP-10 punchcard fortran program decks for explosive charge placement for tunneling and minerals extraction......

"That is the coolest sentence I've red on these forums all year."

I still have my Xerox Sigma 7 MetaSymbol assembler manual (circa 1972). It might as well have been written in conversational Sanskrit. That class put me off of computing for nearly 10 years!

Psst!: http://www.livingcomputermuseum.org/Onl ... Login.aspx" onclick="window.open(this.href);return false;



g.

At one time I thought this was an English language forum but now I am not so sure.
I thought PHP was an illegal drug.

After years of seeing some pretty horrifying PHP, I'd just assumed the authors were ON drugs.

g.

The last version of this script took about 6 minutes to process a ~15MB file (537,306 lines) single-threaded. I now have it down to less than five seconds for the same file.

I've added multiprocessing support. On my 2012-era computer, it processes the file in a little over 30 seconds, running 8 processes. With 16 - and this is on a 4-core machine with hyperthreading, so 8 virtual cores - it finishes in about 8 seconds. 32 processes, and it finishes in 4.68 seconds. That's not a bad delay for something that will take 16+ hours to print!

Get it here: https://github.com/626Pilot/KISSCoast" onclick="window.open(this.href);return false;

Just pushed a new version that adds minimum extrusion length. That way, you don't wind up extruding a tiny percentage of a short path, which would lead to filament starvation well before the end of the path.

My Post-Process line now looks like this:

Eaglezsoar wrote:At one time I thought this was an English language forum but now I am not so sure.
I thought PHP was an illegal drug.

I went to a coffeeshop around the corner (yeah, Dutch yeah!) to ask: "Never heard of thààt, mààànnn"...

Hey 626Pilot,

If I'm understanding this correctly, your coasting script leverages the hysteresis of the bowden. You're using the remaining backpressure to complete the line segment between lifts and moves, right? And the --coast= value would be tuned to your specific setup?

I wonder if backpressure would be different for different printing speeds.

I really like the idea of it, what differences are you seeing in the prints? And do you find that you use different slicer settings now to take advantage of the modified gcode file? (different prime/retract, etc?)

It is intended to compensate for hysteresis in the Bowden tube. The remaining pressure from the melting filament completes the segment, and yes, that is what --coast= is for. You have to print a test calibration object to tune it for whatever filament/speed you use.

I haven't been using the script for a few months. I got a newer nozzle for my E3D Cyclops that has a different inside profile, and it seems to work well enough without the coast script, especially now that I'm printing more in PETG. (PETG can print with less feed resistance than PLA.)

626Pilot,

I wanted to try you program so I downloaded PHP7 and your program. When I ran you program I get the following error:

Fatal error: Uncaught Error: Call to undefined function split()

After looking at your program (I don’t know PHP) I checked the PHP manual for the split function and found that the split function was removed in PHP V7. Split was replaced with preg_split(), explode(), and str_split(). I have done some Python program so I took a WAG and replaced both split functions in your program with explode. The program now runs without errors. But I’m not sure if the explode function returns the same data as the old split function.

Could you verify that the explode function is the correct replacement for the split function?

Thanks.

Ah - so they removed a perfectly good function used by millions of lines in existing code all over the planet, because someone likes perl regex more than POSIX regex, thus creating countless thousands of support issues just like this one.

I didn't use any fancy regex, just a " " for the delimiter. Based on that, it appears that explode() will work.

Reminds me of:

One day, a programmer had a problem with his code.

"I know!", said the programmer. "I'll use regular expressions to fix this problem!"

The programmer now had two problems.



g.

Thanks

Regex is one of my least favorite things in programming, second only to recursion: Powerful, but tricky.