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.

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

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.

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.

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.

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

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.

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!