Concatenating a file at the beginning wouldn’t be difficult. I usually don’t start the file until after I have set everything up. I use have the dual end-stops, I zero x-y then I have a known stop where my work piece is placed. I have created buttons in Octoprint that move the head to the know x and y then
zero there. Depending on where I want my start I may index out from that point. I also use a zprobe, again I have a button that I press in Octoprint that zeros and sets the z height (19.3 in my case). Once I have done that then I start the gcode.
It does already do a tool change between the v-clean and the clean files. I didn’t create a separate file for it but there is a line you can put in there. I created a pause in the code. If you look at the output from finished gcode file, if you have specified a “clean” file there will be a tool change too.
What order would the files be concatenated?
Currently:
Main file
V-Clean file
Tool Change (line plus code)
Clean file
Are you looking for:
Start File
Main File
V-Clean File
Tool Change File
Clean File
(is there an end file?)
I am happy to work with you on tweaking what’s there.
Thanks. Your second order(start-main-vclean-tool-clean w/optional end if it is not too difficult) is what I’m looking for.
I’m thinking the “end” code would just display something like “done” on the LCD for those w/o octoprint.
I guess sometimes it takes a different perspective: I’m not sure why I thought it had to be main then clean, then v-clean last order (maybe the scorchworks video?), but I have been changing tools after the main, then changing back for v-clean. Your way is better because there is only 1 tool change vs. 2 and it clearly works great. So… I feel a little silly.
No worries, two heads are always better than one
I will modify the code and add a start and end file option.
I will let you know once there is something for you test.
I have been thinking about how this would work. Adding a new page to the docs.
If Heffe has better solutions that would be awesome.
I think there are 3 ways to do it.
Use git and add a page and links, submit a pull request.
Pick any page already in the docs Add the stuff you want at the end and we can easily separate and and add a new page. Just leave a little note that that was your intention.
I am happy to do whatever you need but I will wait until there is decision on the best way to go. - I am also happy to upload the exe I created to post process the f-engrave files ready for the MPCNC if there is a place to put it. For now, I have it on my own website.
If you are familiar with python and github, then you can also fork the project, clone it, and run mkdocs locally. I can totally understand that most people aren’t, but I thought maybe you would be, since you mentioned your exe.
From those three options Ryan made, they are all fine with me. @ianj001, pick the one that makes sense to you. Both Ryan and I can munge changes in easy enough. Just providing solid information, and presenting it in a clear way is the hardest part. Any help there is huge.
If you want to share software, then storing it somewhere like github in it’s own repo, or something, would probably be better. There are no reasons why you couldn’t document it and post links in the docs. Make sure you use an appropriate license (I license most of my software as MIT). It will give you more control over releases, versions, and updates. And it will use your own limits for bandwidth (which is free so far, but Ryan has a lot of friends :D).
Gotcha, let me take a look at it. - I use bitbucket for my repo. My exe was written in Python.
Here’s a quick view of what I am working on Inlay overview
Sharing the python (if you’re intending to share the source) is cool too! I use Linux, and I know there are a lot of mac users, so if it is close to portable as python, that would be great. I totally understand that we live in a windows world, and many GUI toolkits aren’t portable either, so sharing the exe is great too.
And BitBucket is pretty close to github. So you would be very capable of making changes in mkdocs from a local checkout. It is really git that you need to know more than github…
But I also see you’ve got a pretty healthy website, so no hard feelings if you just want to keep it there.
I am planning to release the source code, it will take a little setting up. - I am also a Linux and Mac user so I will test it on those platforms to check that it works then I will let you know.
I am going to create a local check out and modify it in mkdocs. I am putting together a “template” on my blog so that I can see what I want to include. I am thinking about doing a screen capture video of the setup too. I will update here as I get new stuff for you guys to look at.
Take a look here, I have put together the main page but need some fresh eyes to look at it.
I will create a video once I can decide on which free screen recorder works best. I haven’t made that hummingbird yet so I am planning to video the whole process using that as an example.
I didn’t want to re-invent the wheel by doing everything that Scorchworks has done on his site.
I am working on a new bitbucket repository to set up the code. I will also confirm that it works under Linux and Mac. - I think I taught myself enough markdown to make it work.
If you make a Pull Request, I can edit and push some fixes directly to your branch. Otherwise, I can make edits on my own branch, and request you pull them into your branch, but it will be harder if you are still working on it.
If that doesn’t make sense to you, I can explain more. I’m still not sure where your comfort level is
The content is great. The images are great. The layout is good. I have some things I will be editing on it, mostly for consistency, and for a using a bit more features of mkdocs. IMO, it is >90% there, and it is an excellent addition to the docs. So Thanks!
I completely agree that we shouldn’t be duplicating the documentation from scorchworks. This is more like a simplified tutorial to do one specific thing, and documentation that is specific to our normal set up. If users step outside of that path, then we will just point them to the more complete documentation.
