search

torontomulibrary / DMEPrinting

0 stars 0 forks source link

Prusa Issues #4

Open ShamiuRahman opened 6 years ago

ShamiuRahman commented 6 years ago

The first layer does not stick to bed even with hairspray. This happened three times today to one person.

Also, we need a Prusa Git Directory to post issues.

DongerZonie commented 6 years ago
  1. ​Maybe the bed leveling tool needs to be run through again. Give that a shot.
  2. I'll get right to making that git now, thanks for reminding me. When we get the next few prusas we'll need to name them as well.

On Fri, Apr 13, 2018 at 5:23 PM, ShamiuRahman notifications@github.com wrote:

The first layer does not stick to bed even with hairspray. This happened three times today to one person.

Also, we need a Prusa Git Directory to post issues.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ryersonlibrary/DMEPrinting/issues/4, or mute the thread https://github.com/notifications/unsubscribe-auth/ARSf9Mm50G6HUN17SY697X0qgxEoB2UWks5toRdLgaJpZM4TUc30 .

cgarcia2097 commented 6 years ago

Update as of May 3, 2018

I have been encountering these issues again for the past two weeks. Only this time, the fault seems to lie with the Octoprint slicer.

DIAGNOSIS

I have run the following calibrations:

All three calibrations produce non-erroneous results. Current setting as of today is -0.450 mm. This is most evident from running the "First layer leveling" calibration, as the filament appears stable and even on the Prusa bed.

PROBLEMS

The issue arises with the Octoprint slicer. For the past three days, patrons that utilize the Octoprint slicer consistently create gcode files that create first layers that fail upon printing. The issue is that the first layer is too high off the bed to stick. I believe this is an issue with the .ini file within the Octoprint slicer; it warrants an investigation.

CURRENT MITIGATIONS

To deal with the issue at hand, the patrons have been advised to utilize external slicers configured for the Prusa i3 MK2S, provided they load the resultant gcodes into Octoprint. SD card printing is to be used as last resort.

SO-SO MITIGATION

One unauthorized attempt made by one of the patrons was to use masking tape to slightly elevate the printing surface. While this is a valid technique in FDM printing, the placement is unauthorized. Any modifications to the printer must be run through by the staff for consideration. This is using the current Octoprint slicer.

TO-DO list:

DongerZonie commented 6 years ago

I have begun work on porting the prusa3d fork of Slic3r for our printers. Should simplify process for most patrons. Only detriment is that they will not be able to change slicing settings on octoprint (but WILL be able to slice) Once attached 3mmBox.gco file prints well then this process may be adapted.

On Fri, May 4, 2018 at 12:17 AM, cgarcia2097 notifications@github.com wrote:

Update as of May 3, 2018

I have been encountering these issues again for the past two weeks. Only this time, the fault seems to lie with the Octoprint slicer.

DIAGNOSIS

I have run the following calibrations:

  • Calibrate XYZ
  • Calibrate Z
  • First layer leveling

All three calibrations produce non-erroneous results. Current setting as of today is -0.450 mm. This is most evident from running the "First layer leveling" calibration, as the filament appears stable and even on the Prusa bed.

PROBLEMS

The issue arises with the Octoprint slicer. For the past three days, patrons that utilize the Octoprint slicer consistently create gcode files that create first layers that fail upon printing, issue being that the first layer is too high. I believe this is an issue with the .ini file within the Octoprint slicer; I believe that warrants an investigation.

CURRENT MITIGATIONS

To deal with the issue at hand, the patrons have been advised to utilize external slicers configured for the Prusa i3 MK2S, provided they load the resultant gcodes into Octoprint. SD card printing is to be used as last resort.

TO-DO list:

  • FInd and configure appropriate .ini file
  • Fix other erroneous settings

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ryersonlibrary/DMEPrinting/issues/4#issuecomment-386502071, or mute the thread https://github.com/notifications/unsubscribe-auth/ARSf9LFwoPHLzChteMuIK44sl5KWno9Bks5tu9ZXgaJpZM4TUc30 .

cgarcia2097 commented 6 years ago

Is that why the slicing profile on the Prusa is that weird one in lowercase? I don't recall installing Octoprint with that profile.

DongerZonie commented 6 years ago

no this was sliced on a development machine

On Fri, May 4, 2018 at 12:37 AM, cgarcia2097 notifications@github.com wrote:

Is that why the slicing profile on the Prusa is that weird one in lowercase?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ryersonlibrary/DMEPrinting/issues/4#issuecomment-386503896, or mute the thread https://github.com/notifications/unsubscribe-auth/ARSf9DZTliENXwdkQ-qciOKUa_sShONCks5tu9rtgaJpZM4TUc30 .

DongerZonie commented 6 years ago

test.zip

cgarcia2097 commented 6 years ago

I also added a DMEPrusa repo. Is it possible to relocate this issue there?