#MakiBox A6 Update - Work In Progress Week

2021-10-21 16:03 by Jonathan Buford (comments: 0)

#MakiBox A6 Update - Work In Progress Week

Here at the MakiLab, there are so many things that are happening, but, they are all in progress.

tl_files/img/DSC_0376.JPG.scaled1000.jpg

So, this week, we've been hacking away at refining the pellet drive extrusion, have gotten to where it comes out in the 230-240C range, as opposed to the 270C range, and are putting together what we hope are the last revisions for that system. One of the critital points we are working with is controlling the melt zone within the system. For those that are not familar with systems like this, the melt zone is just what it sounds like, where the hard plastic turns into hot oozy molten plastic. For us, what we are finding is that the better output comes with the shortest melt zone possible. This probably is true due to a couple of factors. First, the friction of liquid plastic is higher, so moving more of that liquid mass than is necessary just disappates the power into heat. Second, air bubbles get trapped in the larger mass and can't get back out. This turns the output into a more brittle and less dense filament, which probably isn't great for the printing output. 

The other improvement we've made is finding an adjustment on the drive geometry that prevents the jamming, which does loads to make the driving and output more consistent.

On the firmware and host software side, we had a pretty major decision that we made, which breaks the compatibility with other host software, but leads to a vast improvement on usability. Before someone goes off and rants that they really want to use Replicator G or whatever, don't worry, the hardware is still compatibile with other firmware, so for those users that really want to use other host software, it will still be possible. OK, so, what is the change and why? 

All of the existing host software and controllers for this category of 3D printer is derived from the venerable Arduino/RepRap lineage. The major problem with all of them is that they represent your spiffy new state of the art printer as a COM port. For those of you that are too young, COM ports are used for communication, it is a serial interface that was used for a lot of things, but mostly for connecting modems prior to USB. So, the thing is, if we use this abstraction of a USB device as a COM port, we can't easily automatically know the printer is hooked up, load up the right drivers, or any of the other things that devices like printers should do. 

Aside from that, we have just a lot of small things happening on the design to improve the UX and just get things ready for the first Beta units. We are also having someone move this blog over to our new site that we will be consolodating the forum into and starting to get the support documentation setup on, so expect to have notice of that soon as well.

Next week will be interesting.

_______________________________________________________________________________________________

Comment

Torleif Ceder responded:
 
So you mention before that the hostware will start out pretty simple with no integrated slicer and so on. Will you still provide instructions and presets of some tried and true toolchain plan.
 
Jonathan Buford responded:
 

We will have existing slicers integrated, just not our own. It will be a very simple single install, and we will have good documentation for the process. This is one thing that will continue to evolve, so we will start with load file, get printer ready, print. But will look at what people need and add more features as it makes sense. For more advanced users, we will sort out a multi-part tool chain, but we figure there will be folks in the community that does some of this as well.

 

logdog16 responded:

 
Looks like things are going great. Looking forward to seeing a few test prints soon!
 
andybox responded:
 
VERY unhappy about dropping the COM port emulation in favor of "dummying up" the install/init.

I think you need to keep both COM and non-COM (easy - the user sets up the port), or drop this bad decision altogether, otherwise you're shutting the door to compatibility with a lot of the hacks that are out there for reprap, for third party s/w for 3D printing, and for machine tool controllers in general.

I think you need full REPRAP emulation, and be able to be driven by the likes of Mach3 for your future milling machine aspirations, or you will go the way of the Mac computer...a few fan boys, but out in the weeds for mainstream capability and compatibility.

:-(

 
maximpulse responded:
 
I don't care what any of the commentators say! I am simply more excited by each update you issue.
How you think becomes more apparent each time you communicate and that makes me incrementally more optimistic because I can see you are continually improving the Makibox. And at the same time you are drawing a fairly definite line as to where this version will end and where the next one will take off.
I keep thinking that the Makibox will keep getting better and better, with upgrades and whole new devices, yet preserving the affordability aspect which means I will probably be able to both buy the first one and also newer products as you release them. Whoopee!
On that note, have you seen the just-announced "long-awaited Arduino Due just hit the market, replacing the 8-bit, 16MHz brain of the popular Uno microcontroller prototyping platform with a 32-bit, 84MHz processor"? Any thoughts about its usefulness in the future? http://www.wired.com/design/2012/10/arduino-due/
I sympathize with you not seeming to be a wanting to hog the camera and be the center of attention type of person, and yet, here you are, being the spokesperson for Makibox. I hope you'll stick with it and gradually grow comfortable, as it's the communications which have allowed this whole project to move forward. I certainly don't epect great discoveries and such with every update, but I do enjoy seeing what you folks are up to. It's even nice to simply have some idea of how long it takes to have some gears made or even what didn't perform as desired.
Thanks for doing what you do.
 
Jonathan Buford responded:
 

As I mentioned, for those that still need compatibility with existing software, the hardware is still compatible with other existing firmware. We are still compatible with g-code, so most people will be able to just generate their own g-code in an alternative program to get the full benefit of the hacks that are available. Outside of that, we saw the drawbacks of the current state, which include poor communication, and see that having a more robust install and communication method is pretty critical to making the technology better and easier for everyone, not just experts.

There may be some mis-understanding about making the software more simple. We have to start with the basics, what 99 percent of users do. We will look at how to add more functionality, or anyone will be welcome to contribute to the project. However, there is a need for better user experience to be the center of it all. For those that are only needing specific functionality and prefer difficult to use, existing firmware and software may be a better option. Probably the best option will be the middle route of generating the g-code in other programs and using our host stack.

Compatibility with Mach 3 is a bit too far out of the scope of this current machine. That would be a consideration for ones that are more focused on the CNC machining side.

 
Jonathan Buford responded:
 
@maximpulse Thanks! It is a bit of a tradeoff, I'm looking forward to when we can focus more on what cool things people are doing with our hardware. Development can be just a lot of time spent and then figuring out that direction is just not quite working, or a lot of time on a small feature that changes the usability, but may be difficult to quantify to people. Usually, we need to focus on the product itself, so I tend to stay off camera, since it is a different framing to record a person.
 
Jonathan Buford responded:
 
@maximpulse - oh, the Due, I can see a couple of branches that will happen. The Due will be a good fit for applications currently using shields, so like RAMPS. For our machines, we will look at a solution that is more cost effective and rolls in specific hardware on board.

Go back