3D Printing Warping Prone Parts

I’ve owned a Da Vinci Pro 1.0 for about a year now.  And I have noticed that like any other printer, the settings are crucial.  And I hope that this will help other owners.  And maybe owners of other machines as well.

3D Printing with ABS can be problematic from time to time.  ABS really shines when it comes to versatility.  Not only is it an easily accessible filament, but it is strong.  However, that strength doesn’t come without weakness.  And ABS has quite a few weaknesses.

First off, the sharpness of the print will not be as high as with other plastics. Due to the properties of the plastic, it just doesn’t lend itself well to printing high detail models.  But it excels at simpler ones.  This coupled with it’s strengths and it’s ability to be chemically bonded to itself with acetone make it a suitable plastic for creating enclosures.  And in electronics, we always need enclosures.

Secondly, ABS tends to warp.  And warping is exaggerated by larger parts with more mass. To break it down, if it is large, or flat, or has sharp corners, you will likely experience warping.  Or in the event that you do not experience warping, you may experience layer separation.

The root cause of the problem is that ABS tends to shrink as it cools.  So whether or not you’re able to make it stick to the build plate, you’re likely going to have some type of distortion.

This effect can be minimized to a degree, but will always be present.  A heated build surface is a must.  As is an enclosed build area.  These two items will help “keep the heat in”, and that will help the layers cool at a more uniform level.  But this isn’t a complete solution.  Even if you print slow, you may have problems with curling, or warping.

Below is an example of a warping prone part.  It’s large, it’s flat, and it would normally have sharp edges.  But I have designed this part to minimize warping.  Let me explain.

The first thing we need to address is mass.  Now this part was originally part of a larger piece.  That larger piece added a lot of height and mass to the model.  The problem with that is that with each layer you’re going to add a slight amount of additional “pull” to the piece.  Which over time, and increasing layers, can worsen the effect of shrinkage.

The next item we will look at is sharp corners.  There is no getting around it, sharp corners are like a magnet for warping.  Some people try to add “shields”, so to speak, around the corners to help maintain an even temperature.  However, I’ve had little luck with this approach.  What I have had luck with is “Mouse Ears.”  By adding a mouse ear to corners, I have found it does two things.  First, it turns a sharp corner into a round corner.  And secondly, it helps to tack the part down to the build surface, preventing it from peeling up.  An example of a Mouse Ear is here:

Another thing that we must discuss is build settings, specifically build speed.  The fact is, the faster you print the more warping you’ll likely get.  Warping happens as the piece cools. But the solution I have found is to allow the part a little time to cool down to the temperature of the heated bed before applying the next layer.  I do this by adjusting only my “Normal” Shell setting on the printer.  This slows the speed on the Outer Shells to 5mm/s.  This means that the shells take a much longer time to print.  Allowing the rest of the previous layer’s temperature to normalize.  See below:

How does this help?  Well, honestly I had experience ZERO warping on the part shown above with this setting.  However, it does substantially increase build time.  How much longer?  Well (and bear in mind the software’s estimates are never correct, they over state the time) with 20mm/s setting it is estimated to take about 3hrs.  With the 5mm/s setting it is estimated to take 5:40 hrs.  That is almost twice as long.  In reality, the part would likely take about 1:30-2 hours to print with the 20mm/s setting, and approximately 4hrs to print with the 5mm/s setting at 20% infill.  So there is a significant increase in time. But I have experience zero warping with this setting.

But there is one more disadvantage to using this setting that I’ve noticed.  At the place where the print nozzle starts (the Da Vinci has a tendency to start from the same spot for many layers in a row) there may be spots that are ‘missed’.  That is to say that they didn’t get filled in with plastic.  I believe this has to the do with the extrude ratio and the extraction.  I haven’t had a chance to experiment with those settings.  But I plan on testing in the future.

I hope this helps someone else with their print settings on the Da Vinci Pro 1.0 printer.

TinyBASIC 2.5g On The Horizon.

TinyBASIC 2.5g is very near release.  The source now includes routines for IN/OUT, PEEK/POKE, CLS, and DELAY.  And the code for executing Machine Code is being worked out.  So all things considered, it is just about ready to dump into the wild.

Along with the release of v2.5g, I will also be releasing the G80-S Monitor v0.50, which will include in ROM TinyBASIC 2.5g.  This greatly expands the ability of the computer by allowing the user to test new hardware on the fly without the need to write code in assembly, and modify the contents of memory from within BASIC.  I’m personally looking forward to the release.

As a note, the G80-S v1.0 boards are up for sale in the store, and on eBay here, and the Prototyping boards will be shortly.  And once I have a chance to do some tinkering with the hardware side of things I’ll be working on code for a FAT file system.

But until then, happy coding!

G80-S Prototyping Boards Arrive!

Retro Depot is happy to announce that the G80-S prototyping boards have arrived. They’ll be added to the store in a day or two.

So far everything looks good. Although we would suggest that you use extra tall stackable headers. Otherwise clearance may be an issue. But your particular setup may give varying results.

These boards feature breakouts for both the z80 bus as well as the PIO ports, a location for a 1117 Regulator (for 3.3v source), power indicator LED, Micro SD location with breakout (including spots for 1208 capacitors), and just over 1000 pads in a standard .100” grid.

G80-S v1.0 PCBs Have Arrived!

Great news fans!  The PCBs have arrived, been tested, and passed!  That means that I’ll will be able to get them up on the store for sale very soon!  I know many of you are anxiously awaiting the availability of these boards.  I’m waiting on a shipment of capacitors and resistors.  That should be coming in the mail before too long.  But it does take time, and because of this, if you order one of the early boards, you may be forced to purchase without the capacitors/resistors (something I plan on offering free of charge with these boards).

If that is the case, they are easy to find.  They are SMD 0805 footprint.  100nF for the capacitors (total of 16), and 10k for the resistors (total of 6).  One could make through hole work in a pinch.  But the safe bet would be to wait until the caps/resistors are ready.  You’ll know as soon as I do.  In the mean time, here is the front and back of the boards.  You’re excited, admit it.   😉

Also, International Shipping rates have been added to the store.  It’s a 3 tier flat rate.  It seems that for anything under about 8oz I can ship it for about $15 USD.  Once you cross over to 9oz it goes up to about $24 USD.   Above that, it’s best to ask for a quote.  But if we’re talking about a couple of PCBs, I should be able to ship 2-4 for $15 USD (plus the cost of the boards).  If you have any questions, just ask.

Contemplating Graphics

I’ve been thinking about graphics the last week or two. One of the items on my list of things to do is to build a video board for the G80-S. However, graphics pose a new problem…

Video Processors of the time period that this computer would exist were very primitive in respect to their capabilities. Wanting to have a machine similar in capabilities to an MSX, this requires me to use a chip compatible with the TMS9918A. The problem with this chip is that it doesn’t have the greatest of text modes. 40×25 characters just doesn’t work for the Monitor program, or any future aspirations of CP/M or DOS, which typically require 80×24 or 80×25 text modes.

There is a solution to this. Grant Searle’s adaptation of Daryl Rictor’s AVR video processor to 80-column text Mode is perfect for CP/M or DOS. But the problem is that: 1) It’s not compatible with the TMs9918A graphics, 2) the graphics mode leaves quite a bit to be desired.

That leaves me contemplating what should be done. I’ve got some ideas, but I figured in the mean time I would play around with a few different projects, at least until my new boards come…

One of the things that I’ve been wanting to play with was a 128*64 pixel graphics display. I bought one off of eBay a while back, and I’ve never toyed with it. 128*64 pixels isn’t a lot to work with. But I figured I should at least be able to get the G80-S to utilize it for it’s display…at least for TinyBASIC. I’d like to have 32-columns at the minimum. At 8-rows that should give a decent display. But cramming 32 characters in a 128 pixel wide display is a chore.

But with luck I came up with what I though would be a decent character set. I’ve attached the images below for your critique. The characters are 4×8 (width x height). That should allow for a 32×8 display and still permit normal graphics. Now I just have to write some code to test it.




G80-S v1.0 Boards In Production

That’s right boys and girls! The first production run of G80-S v1.0 board has been ordered, confirmed, and are currently in production.

Some of you may be wondering what changes were made between the Beta run and the v1.0 boards. Well, to answer that question, not many. Firstly, and the most important aspect, the IEI line has been fitted with a resistor to VCC. This will allow SIO/DART interrupts if desired. It doesn’t affect current G80-S software. The other changes were simply cosmetic changes to the silkscreen layer. Everything should look pretty now.

Once the boards arrive I’ll get them checked for issues, but the layout hasn’t changed. So the only issues, if any, should be cosmetic at this point. (I had put quite a bit of thought into the board when designing it).

Also, I have designed and ordered a first batch of prototyping boards for anyone who wants to tinker with other hardware. This board will have breakouts for both the z80 bus as well as the PIO pins.  And will have a place for a Micro-SD card and a 1117 3.3v regulator. These changes will simplify modification for CP/M or testing with other hardware by allowing the user a way to expand the board while keeping the same footprint.  With stackable headers you could add quite a few items to the computer.  Just food for thought.

Happy Computing!

TinyBASIC: Variables, Memory, and Expansion

In my last blog post I shared that I have managed to integrate TinyBASIC into my monitor for the G80-S in a ‘mostly stable’ way. Now that has progressed from mostly stable to very stable. But further, the IN instruction has been revised to use variables. Which is quite handy, as it allows the programmer to not only write to I/O, but to also read from it, and make branches in his/her program as a result of those reads.

This is a big step, as it is the basis for other routines that can expand on the original TinyBASIC source code. Routines such as PEEK or POKE may need to use variables, and the ability to use variables to OUT to I/O is also important from a programmers viewpoint. And these routines just simply were not included in the original source, and I desire to have them available in my software. So as such, I’m further modifying TinyBASIC as I see fit.  And yes, when it is done I will release it into the wild.

Variables in TinyBASIC are straight forward once you understand them. To read from or write to a variable one simple needs to understand that they are nothing more than a predefined area of memory, and that they have a given structure.

This area of memory is defined as VARBGN in the TinyBASIC source. And in my personal example of code resides in 55 bytes of data starting from 0xFF00. Now, each variable is broken into two (2) bytes. However, they are not organized as you would assume, with the MSB being first, and the LSB being second (i.e. the way one would read the memory if layed out in from of him). No, TinyBASIC addresses variables just like the z80 addresses memory. I.e. if we refer to location FF88 in memory it will be listed as 88FF. Likewise, if we refer to a variable (for the sake of examples let say it is listed as 01h) in memory, it will be addressed like this:  01h 00h.  Strange, but ok.

Further, the first address of the variables is not ‘A’. I believe that it is ‘@‘ which I also believe is a pointer. But I have not confirmed this. One step at a time…

Now, this means that if we want to use variables it is as simple as figuring out which variable we want to use, and reading from or writing to that area of memory. Simple right!

As a result I have rewritten the IN instruction so that it now operates as a tool for loading a given variable for use by the program. It can be used in the following ways:

IN hh V
IN hh,V
IN hh=V
IN hhV

Where ‘hh’ is the port to write to in Hexadecimal, and V is the Variable ranging from ‘A’ to ‘Z’.

I’m still working on patching the OUT instruction to use variables. Sometimes the best way to solve a problem is to step back and let your eyes rest. And that is where I am at currently. I needed to step back until my eyes are fresh. But as of right now it can output a byte to a port.

The rest of the functions are still a work in progress. I have added a CLS function that can be used either direct or within code. I have also added a QUIT function which serves to exit TinyBASIC. So it is coming along.

Overall, my work on expanding TinyBASIC to be more usable, while maintaining a small foorprint, is progressing at a pleasing rate. And while this project centered around my G80-S computer, need is the mother of invention.  And as a result I will release the source once I decide that it is complete enough for release.

But for now, I leave you curious…

Integration of TinyBASIC

It’s been a productive weekend!   I’ve been able to integrate TinyBASIC into the monitor program.  Btw, if case you were wondering why the monitor states that it is G-DOS, it is motivation (and my intent) to integrate a FAT file system into the computer.  Likely using a SD card.  I’m currently working on the design.

But wait!  Integrating TinyBASIC into my monitor program is not all that I’ve done!  I’ve also been working on expanding TinyBASIC with the following items: IN, OUT, PEEK, POKE, and CALL.  That’s right, TinyBASIC will actually have some use other than just printing to the screen.  This will be a great tool for testing hardware designs.

As it is right now, I’ve added the IN and OUT routines.  OUT performs exactly how you’d expect:  ‘OUT NN NN’ where NN is a two digit hexadecimal number.  IN on the other hand I’m still working on.  The routine itself works, but I’m unsure how to finish it off.  What I mean by that is that I need a way to be able to assign a variable, and I haven’t looked deep enough into the code to be able to determine how to do so at this time.  For now, it simply writes the value to a specific address in memory: 0x8015. Which required me toying with memory locations built into the original TinyBASIC source.

Once I can figure out how to assign a variable to the command, it will become much more useful.  And that same scheme can be applied to the PEEK command as well.  POKE on the other hand should be as straight forward as OUT.  And this gives TinyBASIC a new level of functionality, and no more limitations on variables, as you’d be able to access memory directly.

And the best thing about this is that I believe that after expanding TinyBASIC I can keep the entire ROM (including filesystem routines) under 8K. Currently with the Monitor and BASIC the ROM is just under 5K (5013 bytes). I do not see why I wouldn’t be able to keep the I/O routines for an SD card and the Filesystem routines under 3k.  And I should only need a few hundred more bytes for the additional commands.  Of course one must also take into consideration the ability to save files from BASIC and load them again.  Who knows, but 8k is my goal.  We’ll see how well we can accomplish this.

Popular Request: Microphone Pop Filter

Well, after suggestions from several viewers on my YouTube channel concerning the issues with my microphone, I have decided to break down and buy an el-cheapo pop filter.  Nothing special, here is the one I decided to purchase:

Double Layer Studio Microphone Pop Filter

It’s nothing fancy, but hopefully it will work until I have a chance to do research and invest in an audio interface and better microphone.  We’ll see.  But the good news is that it should at least help!  So look forward to future “hopefully pop-free” videos.

And for the record, it has already been ordered.  Whether or not I can hold off until it arrives before shooting my next video, that is a question for another day.  Although I do have a video I am REALLY wanting to shoot before too long.  However I have to do a little more work to get ready for it.  Maybe I could stretch it out until this weekend?

TinyBASIC for the z80 – TinyBASIC 2.0g

In celebration of 41 years of Li-Chen Wang’s TinyBASIC (the original Open Source Operating System), and the fact my G80-S Computer needed a version of BASIC, I am proud to announce the z80 port of TinyBASIC.

Version 2.0g was derived from the original TinyBASIC 2.0 source.  The method of it’s conversion was thorough.  First the original source was compiled in 8080 mnemonics.  It was then disassembled, and compared to the original source.  It was then modified for the z80 Instruction Set.  And finally, streamlined in order to make it a little more portable.  The link to the download is below.

TinyBasic_2.0g

However, if you’d like the assembly file for the G80-S computer, here is the link to that source code.  Enjoy!

G80S_tinyBASIC_2_0g