You are not logged in. Please login or register.
SoliForum - 3D Printing Community → XYZ Printing Hacks & Mods → Jr + Cura 2.3.0 + ThreeDub
Honestly I would rather print slower if the quality of that vase and bench are what you get at those higher speeds. Those are pretty much only good for test prints and setting results.
Agreed. I thought at 60mm/s, my JR would shake apart.
Also, when using Cura, you have to set the Z height in the profile. The one from the control panel doesn't affect the actual gcode program. To do this go to Preferences>Configure Cura, then Printers and then Machine Settings. In the lower left side in the "Start Gcode" box, adjust the Z portion of the line "G1 Z0.350 F6000.000" until you get good first layers. This info was originally in post #10 of this thread, but worth mentioning again.
Agreed. I thought at 60mm/s, my JR would shake apart.
Put the case on, my Jr. never shake at all at 60mm/s. It do generate very noticeable noise even when the door is close, so I only print at 40mm/s. (My Jr. is RAMPS converted. with E3D hotend and layer cooling fan.)
Profiles do matter. this image shows the Benchy printed with good settings, on the left (as described below), accidentally 1 layer wall thickness in the middle, and forgetting to turn off Spiral/vase mode on the right!
The "good" benchy is printed on my worn out 2 year old 15 spool-used Jr @ 30% infill, .2mm layer height, 210 degrees, print speed 70mm/s, and travel 100mm/sec 
Jdplus3, thanks for the profile. I'll give it a shot later today.
Thanks to all for the hard work that got this far!
I've got an STL file (from Tinkercad) that xyzWare just can't slice (consistently crashes after the print options) so it forced me to finally get around to try using a different slicer. Downloaded Cura (previous experience) and installed threedub on my Mac (easy, thanks to the forum posts). When I open the resulting .3w file in xyzWare, I can see the model, but printing gives me the following error:
Printer mismatch - Please change your printer
settings and make sure you have selected the correct printer model.
For troubleshooting, please refer to our user guide.I'm assuming something in the threedub process is adding a Davinci JR header that needs to be changed to work with my miniMaker, but I have no idea where to try that.
Any help would be appreciated!
You will need to use xyz advanced to see gcode with. Slice a model with xyz with your printer, and take note of what it says for model.
In threedub you can change this in models.py. that should fix it.
I don't know how to get to xyzzy advanced 
. I'm on a Mac with XYZWare 2.2.19 if that helps.
I did try to use threedub to extract the gcode from a file saved out of XYZWare that worked on my miniMaker, but it had the same headers (I presume threedub changed them?) as the gcode in the file created by threedub. I then took the same gcode file, repacked it with threedub and validated that indeed it wouldn't print from XYZWare (so XYZWare 3w -> threedub gcode -> threedub 3w and I can open both 3w files, but only print from the XYZWare 3w and not the threedub 3w).
I did play around with threedub a little more (found the printers.py file, with a definition for JR10, which I'm guessing is what has to be modified once we can figure out what the miniMaker values are). It was able to query status from the miniMaker (threedub -q) but I noticed that several of the raw status values threedub doesn't know how to interpret.
Lastly, I did notice that there are two different versions of the python port of threedub (I couldn't find the source to the original threedub?):
- origin https://gitlab.com/Razor_keen/py-threedub.git - more recent (2 months ago)
- origin https://gitlab.com/anthem/py-threedub.git - older (1 year ago)
although both versions behaved the same for me with regards to XYZWare and the printer.
Sorry, just saw your reply. I'm not at home yet, but here are a couple 3w files. The "TARDIS_panel" is something I had printed before and I'm sure was saved after slicing specifically for the miniMaker. The "xzyCalibration_cube" I just downloaded off thingiverse and saved after slicing, but I'm not 100% sure the 3w file is setup for the miniMaker.
Appreciate it! Please let me know if there is anything I can do to help.
Thank you!! That worked 
I tried it first on the newer py-threedub (0.2 from https://gitlab.com/Razor_keen/py-threedub.git) and it kept failing with an import error on the Padding name. (I'm not very proficient with Python, so I'll investigate more later). I then applied the same change to the older py-threedub (0.1 from https://gitlab.com/anthem/py-threedub.git) and was able to put out a 3w file of a model that xyzWare had refused to slice and then open the 3w file and print it
The initial print was all messed up, but I figure that is probably in slicer settings. Guess I have some tinkering to do this evening
https://youtu.be/yfoowvOjNGE
Now I can use cura And have a good extruder. I replaced my extruder with a generic Bowden.
I was excited to have an option to XYZware when I found this thread. I am glad it works for so many. I actually get better prints from XYZware then with cura.
XYZware is optimized for jr. Cura is not. And default setting for Cura will work on most popular 3d printers, but not jr. in stock condition. You need to fine tune Cura setting in order to get better print quality than XYZware. Option to use Cura on one hand opened the door to many possibilities, on the other hand increase the complexity to identify the best setting for your printer.
XYZware is optimized for jr. Cura is not. And default setting for Cura will work on most popular 3d printers, but not jr. in stock condition. You need to fine tune Cura setting in order to get better print quality than XYZware. Option to use Cura on one hand opened the door to many possibilities, on the other hand increase the complexity to identify the best setting for your printer.
Yes I under stand that. Tried the many profiles that were posted and tried to tweak them but the first layer fails to print at the proper thickness even when I set it to be twice the size. Uses up a lot of time and filament. So I will probably keep trying when I have excess of both.
yizhou.he wrote:XYZware is optimized for jr. Cura is not. And default setting for Cura will work on most popular 3d printers, but not jr. in stock condition. You need to fine tune Cura setting in order to get better print quality than XYZware. Option to use Cura on one hand opened the door to many possibilities, on the other hand increase the complexity to identify the best setting for your printer.
Yes I under stand that. Tried the many profiles that were posted and tried to tweak them but the first layer fails to print at the proper thickness even when I set it to be twice the size. Uses up a lot of time and filament. So I will probably keep trying when I have excess of both.
The first layer is controlled by the height between the nozzle and bed. If your printer allows for calibration and it is calibrated correctly and the proper z offset in your start gcode is set in your slicer than you should just be able to slip a piece of paper between the nozzle and bed with slight drag. The actual layer height setting will influence it to some extent but it still should be squished standard layer. The layer height setting in the slicer is actually for all the other layers after the first and should not even be considered in determining the fist layer. The first layer thickness again is dictated by the nozzle to bed clearance and it sounds like yours could be too high.
A rule of thumb could be simply be that the gap between your bed an nozzle should be half or less of your desired printing layer height. For example if you want to print a .2 layer then the gap should be .1 or less. You never want the gap to be a value larger than half of your printed layer height.
Again if your printer allows the bed height to be adjusted then that is how you would achieve this. If the bed is not adjustable then you will need to play with or create a Z offset in your START gcode. If you have to do this then make very small value changes to avoid allowing the nozzle to hit the bed.
I am running linux and would like to print directly from my computer without an sd card. Is there any way to do this from cura?
I got cura set up a year ago with no problems.
If the bed is not adjustable then you will need to play with or create a Z offset in your START gcode. If you have to do this then make very small value changes to avoid allowing the nozzle to hit the bed.
@carl - I have been playing with Cura and comparing XYZWare and CURA generated GCODE, I am not following how an offset in the start GCODE affects the first layer as defined by cura
The examples posted run the priming routine at Z = .35 from start gcode (which matches what XYZware does) but the gcode commands are absolute positional (not relative) so once its done with the priming it seems it will go to whatever Z value is specified by cura's first layer setting.
So for instance if start GCODE has .35, Cura first layer height is .25 and standard layer is .2 It seems to run the priming line at Z=.35 (from start gcode) and when done it then actually lowers to Z=.25 for the first layer, the next layer will be .45, then .65 etc.
Am I misunderstanding something. It seems whatever is in start gcode only affects the process until the first layer as output by cura begins. I believe you can reset the Z via a G92 Z command but I don't see these in any of the examples provided.
Anyone help me get Threedub working on Linux. When I run it (the older version mentioned above as the newer link no longer works)
I get an error about encryption I think. I am running Python 2.7, I have installed py-crypto, pyserial and padding. Anyone got any suggestions?
Error is as follows.
sudo threedub 20140205_Marvin_KeyChain.gcode Marvin.gcode
Traceback (most recent call last):
File "/usr/local/bin/threedub", line 11, in <module>
load_entry_point('threedub==0.1', 'console_scripts', 'threedub')()
File "build/bdist.linux-armv7l/egg/threedub/main.py", line 60, in threedub
File "build/bdist.linux-armv7l/egg/threedub/davinci.py", line 76, in write
File "build/bdist.linux-armv7l/egg/threedub/davinci.py", line 41, in encrypt
File "/usr/lib/python2.7/dist-packages/Crypto/Cipher/AES.py", line 59, in __init__
blockalgo.BlockAlgo.__init__(self, _AES, key, *args, **kwargs)
File "/usr/lib/python2.7/dist-packages/Crypto/Cipher/blockalgo.py", line 141, in __init__
self._cipher = factory.new(key, *args, **kwargs)
ValueError: ECB mode does not use IV
carl_m1968 wrote:If the bed is not adjustable then you will need to play with or create a Z offset in your START gcode. If you have to do this then make very small value changes to avoid allowing the nozzle to hit the bed.
@carl - I have been playing with Cura and comparing XYZWare and CURA generated GCODE, I am not following how an offset in the start GCODE affects the first layer as defined by cura
The examples posted run the priming routine at Z = .35 from start gcode (which matches what XYZware does) but the gcode commands are absolute positional (not relative) so once its done with the priming it seems it will go to whatever Z value is specified by cura's first layer setting.
So for instance if start GCODE has .35, Cura first layer height is .25 and standard layer is .2 It seems to run the priming line at Z=.35 (from start gcode) and when done it then actually lowers to Z=.25 for the first layer, the next layer will be .45, then .65 etc.
Am I misunderstanding something. It seems whatever is in start gcode only affects the process until the first layer as output by cura begins. I believe you can reset the Z via a G92 Z command but I don't see these in any of the examples provided.
Your nozzle is set at a position deemed as home. Any movement originates from that home position. So like you said the purge line is done at .35 from the home position of zero. An offset modifies the home zero position by whatever value you use. So say you make an offset of .2 even though it is still seeing home as zero you have actually added .2 to the zero so not your purge line would actually start at .55 and would not be on the bed but start in the air. That's why it is called an offset as it offset the true zero of home by the offset value.
SoliForum - 3D Printing Community → XYZ Printing Hacks & Mods → Jr + Cura 2.3.0 + ThreeDub
Powered by PunBB, supported by Informer Technologies, Inc.