XYZprinting Da Vinci 1.0 Hacking (Page 4 of 6)

Yes, that is correct. Just downgrade your firmware and you can use 400m, 999m. Otherwise you're going to have to program the eeprom to a standard cartridge size, eg 240m/600g.

I got a cartridge that had some obscure data, compared to what is currently being seen on the eeprom. I read it and wrote it back and it says undetected.  Looks to be some kind of encoding scheme. Beware , they might be phasing out the old cartridges on future firmware updates

FYI - I don't recall just where I read the comment about correcting for the "out of round" condition for either holes or round shapes but the thought was that the X-axis belt was a little too loose, so tightening that belt was the solution.  As is mentioned above, there is no real accurate way to judge the tension of the belt but I did move the motor (loosen 4 screws - left and right sides around the motor) - and while I can't say with any degree of certainty that this improved the "roundness" condition it did bring in something else that could have been more troubling.

The belt tension effectively pulls the bearing carriage on the left side towards the centerline of the unit.  If you put too much tension on the belt, something has to give and I believe it's the stretch potential within in the belt.  On the next two or three prints that I made following that adjustment, there was a definite sound coming from the bearing/carriage - the sound you would get from plastic under too much tension!  The point is, any adjustment to help the "roundness" may create another more threatening issue with either breaking or deforming the bearing that the belt is rotating or in breaking the belt as well - which would not be a good thing.  The sound has pretty much disappeared now as I believe the belt has once again reached some point of equilibrium - meaning it's probably not going to stretch much more and is most likely tight enough to do the job it was intended.  In this cube we call the "XYZ" printer, there are plastic parts, metal parts and "others" - and the ones most likely to create problems are those plastic pieces that are either tensioned too much, tightened down "too tight" or adjusted beyond what is reasonable and simply promotes the failure that sends us off into other areas for solutions.  Like it or not we need to think thru the "chain of events" that are likely if we don't want to end up with a collection of parts that won't work for us.  Lesson learned for me - now for you too!  Thanks.

I don't know if it has been mentioned here already but for those who don't want to cut a hole in their printer to access the SD card, there is an SD card extension cable that you can plug into the slot on the printer, then run the cable down and out the back and just plug the SD card into that. Very easy and no holes! Just do a search for SD card extension cable. I found one for $4.16 on DealExtreme.

For those with perl there are one liners for encoding/ decoding base64

63. Base64 encode a string.

perl -MMIME::Base64 -e 'print encode_base64("string")'
This one-liner uses the MIME::Base64 module that is in the core (no need to install it, it comes with Perl). This module exports the encode_base64 function that takes a string and returns base64 encoded version of it.

To base64 encode the whole file do the following:

perl -MMIME::Base64 -0777 -ne 'print encode_base64($_)' file
Here the -0777 argument together with -n causes Perl to slurp the whole file into the $_ variable. Then the file gets base64 encoded and printed out, just like the string example above.

If we didn't slurp the file and encoded it line-by-line we'd get a mess.

64. Base64 decode a string.

perl -MMIME::Base64 -le 'print decode_base64("base64string")'
The MIME::Base64 module also exports decode_base64 function that takes a base64-encoded string and decodes it.

The whole file can be similarly decoded by:

perl -MMIME::Base64 -ne 'print decode_base64($_)' file
There is no need to slurp the whole file into $_ because each line of a base64 encoded file is exactly 76 characters and decodes nicely.

In the original post it says that it's preferred to set the total filament usage to 0.00 in the gcode then upload through xyzware.  Currently my printer is on 1.1.J and I have been unloading through XYZware.  Even though I set the filament usage to 0.00 in the code heading and footer (generated by slic3r) the filament is still counted and the total decreased.  Does anyone know what firmware this will work with.  Thanks in advance!

hi all, just flashed the printer and it is saying that the computer doesn't recognize the usb. I am using windows 8.1 and everytime i go to install the drivers it comes up as a bossa programming port (it should be an (Arduino Due Programming Port). I'm freaking out and don't know what to do. Any help would be greatly appreciated. this is the guide I used, I followed the steps perfectly but it didn't work. btw I have da vinci 1.0A

BTW - just realized checksum is just a sum (ony gcode part, after replacing '\n' => '\r\n')

        public static int checksum(byte[] arr, int start, int len)
        {
            int num = 0;
            for (int index = start; index < start + len; ++index)
                num = (int)arr[index] + num;
            return num;
        }

that gives 4 bytes - 00 00 b9 2e for minimal.gcode exact as hardcoded in print-to-davinci.py

A long answer but, hopefully helpful...

I’ve had the Da Vinci 1.0  for two weeks and thought I’d summarize my experience with it.
Have made ton’s of SLA prototype and CNC machined parts (I own 3-axis CNC mill).
I know Gcode well and am a java and assembly-code programmer so naturally I tried out the various hacks.
Wanted a 3D printer that was low cost with some bang for the buck and would accept code.

Did several runs on small (0.5” x 1.0” x 0.03”) to large (7.6” x 7.6” x 3.5”) parts.
Used: XYZware, Netfabb and Slicer with many different settings to see their affects.
Material: White ABS (that came with printer) and Black ABS (from XYZ).

Summary of Results:
Surprisingly, in all cases, the XYZware printed the best.
Best approach (for me) is to:
    Repair .STL in Netfabb (not all holes closed when Auto-preparing in XYZware)
    Export it as .STL
    Drag&Drop (or import) into XYZware
    Select export / change parameters as desired (don’t repair as it was done in Netfabb)
    Print

Using Gcode (on iMac running Yosemite 10.10.2):
Worked until I upgraded Firmware - then no longer.  However, I took care of that, as follows:
Completely deleted XYZware (best to use an app cleaner so all the related files get deleted - there are several and deleting the related files is a must!!).

Re-install XYZware but DON’T upgrade firmware!  (perhaps that will change down the road).
Repair and export the .STL part in Netfabb.
Open it in Slicer (make your custom settings) and export gcode.
Edit the gcode using TextEdit (on a Mac, no need to decode base64 - it will be in english).
Add the required header lines (you can find them on net) and save.
Drag&Drop (or import) into XYZware and Print.
Works like a charm.

Poor documentation on the printer and it appears no ability to increase the extrude temp with gcode so strings on large objects aren’t bonding well, even at slow speed.  Extruder temp is 210C but the ABS specs from XYZ say range starts at 215C…

Has anyone had quality issues after using filament reseters?

I've had my Da Vinci 1.0 for about a year and finally got tired of warping prints and expensive filament so I went all out with modifications.  I did the following in this order:

• Started with latetst firmware:

• Removed the back panel and removed the SD card

• Sliced a model using Slic3r and replaced the GCode for Sample1 (Slic3r config attached)

• Printed through SD card (Worked great!)

• Then I hard reset to revert firmware to J:

• Used the Arduino Nano to revert my catriges to 240/240 (using Filament Resetting Instructable)

• Sliced same model as above.  Now it's printing stringy and thin

Had an issue after resetting my cartridge and using some aftermarket filament.    It was a clicking noise and then the extruder just stopped putting out material.   Read a lot of the posts here and there was everything from taking the thing apart to adjusting the bed, etc.   None of these are the issue from what I can tell.

If this happens to you, make sure you are using a filament/ABS that will work within the temperature range of the XYZ.   Have not seen how to adjust the temperature yet, so I'm stuck (for now) on that, but I noticed that the PLA I bought is rated for 190 C up to 210.   The XYZ operates above 210 C.    the ABS I bought operates between 210 and 230.

Popped out the PLA and put in the ABS and off she went without any issues.

Okay I have had my Da Vinci 1.0 for almost a year, brought it knowing that I could use aftermarket filament as a friend sell them.  I use the WCT to reset to 120m.  Never updated either software or firmware and been successfully printing even with different bed temps etc for almost a year with hundreds of successful prints.  One day XYZware stopped recognising printer, checked driver and seems to have done an update the morning I started using it.  Pulled out another laptop (with software already installed) disconnected the internet and works fine - whilst this is a work around its a pain the arse just booting up this laptop to do a print (its an old Win7 laptop).

So my questions are has anyone else experienced this?
Any idea how to over come this?

Some Spec's
Win7 Laptop (WORKING) SW 1.1.27.6 Printer Version 1.2.3; Printer Driver 8/01/2013 Version:6.0.0.0
Win 8.1 Laptop (was workin now not) SW 1.1.27.6; Printer Driver 22/01/2015 Version: 14.38.4.327

I'm unable to roll back driver as this option is not available.  Does anybody have an earlier driver they could send me (for Win8.1)?

Thanks in advance
Alice