Printing and converting issues

Question

Printing and converting issues

Opened this issue 12 years ago · 16 comments

When I assembled machine, I had to have a little bit of voodoo with the firmware to make it work as it should. Then I experienced some issues. To configure the steppers I tried to print different slices on paper. I tried the square, rhombus and circle. I set the scale factor to 1.0 in the settings and change the length with a width to 600, because the slice is truncated to the size of 24mm. First, I printed a square and it was perfect. Then I tried the rhombus and circle, and they disappoint me. Their top (first nozzles) had significant stepladder. At first I thought that the nozzle is not connected properly. I found that the PORTC is backwards numbering and I reverse the nozzles 1 - 4. This made better, but insufficient. In spite of this, the bottom of the slice (the last nozzles) look almost satisfactory. To understand where the problem is, I connected the nozzles separately and 12 times I printed same layer. I found that at the top of the rhombus, long of lines differs only in 1st and 2nd nozzles, the other 10 nozzles have the same long of lines. In the lower part of the rhombus is almost good. And I found one nonworking nozzle (9) I check connection with multimeter, and check signal on arduino with LED, it's Ok, maybe I smoked ULN or burn the printhead, in any case, one nozzle is insignificantly. To see the problem more clearly, I printed the slice with double the size of the Y-step. You can see the result in the photo:

But with the circle I have a different issue, when converting GUI shows irregular circle. You can see it and printed result on pictures.

Has anyone encountered such issues? Where there may be a bug? This is a bug of converting with GUI, or bug in STL Model? I look at the models with MeshLab, and they looks fine.

Answer 1 · 2013-02-17T19:35:14.000Z

I am not at that point yet, but the aliasing effect you see, can it be that the head is still moving while these jetz are firing? Try to position the head, then pause for a few uSecs before firing the nozzles.

Answer 2 · 2013-02-17T19:41:57.000Z

The second problem is obviously an issue with the slicer. IIRC Pwdr uses a library, so not much to do about that.

Answer 3 · 2013-02-17T19:45:42.000Z

The stepping motion is completely done when the nozzle is fired.

On the problem: the stl files are fine, what you see in the GUI is what you
get in the print file. You mention you use PortC, why is that?

To check whether it is hard or software, please check the print file with a
bin editor. Or dump print file here.

On Sunday, February 17, 2013, MatthiasWM wrote:

I am not at that point yet, but the aliasing effect you see, can it be
that the head is still moving while these jetz are firing? Try to position
the head, then pause for a few uSecs before firing the nozzles.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/18#issuecomment-13691879.

Answer 4 · 2013-02-18T06:00:00.000Z

When I said PortC I talked about this: -

for(int i = 4; i <= 7; i++){
byte mask = 1<<i;
if(upper_nozzles<<4 & mask){
PORTC |= mask; delayMicroseconds(5);
PORTC &= ~mask; delayMicroseconds(1);

// if set upper_nozzles<<3, than signal on pin 30 (PC7) is missing

According to pinmapping http://arduino.cc/en/Hacking/PinMapping2560. PortA have direct numbering PA0-PA7 which corresponds to Digital Pins 22-29, than PortC have reversed numbering PC7-PC0 which corresponds to Digital Pins 30-37, so if I understand it right then connection should be next

Nozzles___________12__11___10___9___8____7___6_______5____1____2___ 3___4

ULN2003_pin__U5__16__15___14__13__12___11__10__U6___16___15___14__13__12

Digital_Pins_______22__23___24__25__26___27__28________29___30___31__32__33

Port______________A0__A1__A2__A3__A4__A5__A6_______A7___C7__C6__C5__C4

Answer 5 · 2013-02-18T06:05:54.000Z

Sorry, I hurried and wrong with U6 now I corrected it.

Answer 6 · 2013-02-19T07:12:01.000Z

Ok, to
locate the bug, I tried to print file with previous version of firmware
and GUI V0_2, I used default files PwdrPrintDataUpper.ino and
PwdrPrintData.ino, because I can't convert self model – GUI created
empty files. So printed picture shows that the problem not in
hardware, because picture is almost fine.

I tried
to check my printfile in WinHex, but saw is not to much, I'm no much
understand in it, but in my view, the bug is in printfile (location of bytes looks asymmetrically), I put this file in attachment, if you can, please check it, and I attach STL file, just in case.

От: Pwdr notifications@github.com
Кому: Pwdr/Pwdr-Model-0.1 Pwdr-Model-0.1@noreply.github.com
Копия: Michael boreaz73@yahoo.com
Отправлено: воскресенье, 17 февраля 2013 23:45
Тема: Re: [Pwdr-Model-0.1] Printing and converting issues (#18)

The stepping motion is completely done when the nozzle is fired.

On the problem: the stl files are fine, what you see in the GUI is what you
get in the print file. You mention you use PortC, why is that?

To check whether it is hard or software, please check the print file with a
bin editor. Or dump print file here.

On Sunday, February 17, 2013, MatthiasWM wrote:

I am not at that point yet, but the aliasing effect you see, can it be
that the head is still moving while these jetz are firing? Try to position
the head, then pause for a few uSecs before firing the nozzles.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/18#issuecomment-13691879.

—
Reply to this email directly or view it on GitHub.

Answer 7 · 2013-02-19T08:05:06.000Z

Could you sent a link to the files? Attachments don't work with e-mail reply.

Answer 8 · 2013-02-19T08:16:54.000Z

Ok, I put them on in repository, there are three files - printfile, STL model and photo of printing result with previous firmware https://github.com/Boreaz/MyPrintfiles

Answer 9 · 2013-02-19T08:23:55.000Z

Ah. The picture surely shows that one of the nozzles is defect. Can you replicate the bug of the rhombus?

Answer 10 · 2013-02-19T08:52:08.000Z

Replicate? What do you mean? The dat file in repository prints with bug, as I show in previous photos. The bug comes always when I'm trying to print slice using newest firmware (PwdrFirmware2_0), I convert this STL model using GUI V0_3, then copy PWDR folder into SD and insert it to SD shield, and I have ladder each time, I'm trying different sizes of model, scalefactors in config, number of slices, rhombus and circles, and I always have this bug. But when I use previous firmware (PwdrFirmware) with default PwdrPrintDataUpper.ino and PwdrPrintData.ino files, then I have almost Ideal circle. Now, when I'm change ULNs to new, all nozzles working fine, but ladder still here.

Answer 11 · 2013-02-19T08:58:09.000Z

Ah, and I can't print rhombus with previous firmware, the GUI V0_2 not working with stl files, I paint it in msPaint in png format, GUI says that he convert png file successful and ask to upload firmware to arduino, but PwdrPrintDataUpper.ino and PwdrPrintData.ino is empty and 0kb.

Answer 12 · 2013-02-20T12:08:28.000Z

Ok, it seems I solved issue with ladder bug, I will not describe all the voodoo tricks that I have used, but all works when I deleted the few strings from this -

      if (lower != 0 && upper !=0){
        for (int i=0; i<saturation; i++){
          spray_ink(lower,upper);
        }
      } else {
        delayMicroseconds(500);
      }
    }
  }

Now it looks like this

          for (int i=0; i<saturation; i++){
          spray_ink(lower,upper);
        }
     }
  }

And the photo of printing results
Before

After

And now I have another one problem, circle converts awry.

Answer 13 · 2013-02-20T12:33:46.000Z

Ah, well. The first line was to speed up the printing for when there is nothing to print. Don't remember why there was a delay if that was true. Probably for precision reasons.

Anybody knows why the statement doesn't hold?

The problem of the oddly shaped circle is due tessellation. The STL format describes all shapes by triangles, converting a sphere results in these artefacts.

On Wednesday, February 20, 2013 at 13:08 , Michael wrote:

Ok, it seems I solved issue with ladder bug, I will not describe all the voodoo tricks that I have used, but all works when I deleted the few strings from this -
if (lower != 0 && upper !=0){ for (int i=0; i<saturation; i++){ spray_ink(lower,upper); } } else { delayMicroseconds(500); } } }
Now it looks like this
for (int i=0; i<saturation; i++){ spray_ink(lower,upper); } } }
And the photo of printing results
Before

After
And now I have another one problem, circle converts awry.

—
Reply to this email directly or view it on GitHub (#18 (comment)).

Answer 14 · 2013-02-20T14:11:32.000Z

Yes, it seems the problem with circle in STL model, AutoCAD is not a good choice for 3d modeling, can you advise the good, easy and cheap (or free) program for creating STL models?
It seems like the machine now is almost workable, only need to configure steppers, and another few adjustments, soon I will try to print in 3d. Thanks a lot for your patience and advising.

Answer 15 · 2013-02-20T14:14:21.000Z

Personally, I use SolidWorks. But Google Sketchup should be able to produce reasonable STL files. And it's for free :)

How did you manage to test print on paper when you need to configure the steppers? :P

On Wednesday, February 20, 2013 at 15:11 , Michael wrote:

Yes, it seems the problem with circle in STL model, AutoCAD is not a good choice for 3d modeling, can you advise the good, easy and cheap (or free) program for creating STL models?
It seems like the machine now is almost workable, only need to configure steppers, and another few adjustments, soon I will try to print in 3d. Thanks a lot for your patience and advising.

—
Reply to this email directly or view it on GitHub (#18 (comment)).

Answer 16 · 2013-02-20T14:22:00.000Z

Thanks! I mean Roller, Z and Z1, and with current step size I have 22mm vs 20 in model, but it may because of saturation.