Jump to content

tinkergnome

Ambassador
  • Posts

    2,774
  • Joined

  • Last visited

  • Days Won

    61

Posts posted by tinkergnome

  1. 4 minutes ago, Glomby said:

    I don't quite get why an end script is needed anyway isn't this part of the gcode

     

    Some steps are done by the firmware, if the print was started from the sdcard. These are usually not in the gcode.

    If you add it generally, the home command (e.g.) would work, if you print via USB, but would be executed twice if you start the same gcode from sdcard.

     

    I use this for "After print job completes" and "After print job is cancelled":

     

    ;disable all heaters
    M104 S0 T0
    M104 S0 T1
    M140 S0
    G90 ;use absolute coordinates
    G92 E11.0
    G1 E0 F1500  ;end-of-print-retract
    T0
    G1 X23 Y200 F10800 ; move printhead away
    G28
    ; disable motors
    M84
    ; disable fan
    M106 S0

     

  2. 1 hour ago, harbaum said:

    Aber ich verstehe nicht, warum hier nicht haufenweise Reports der Art eintrudeln, wenn es so ein deutliches Problem ist.

     

    Ein paar ähnliche Meldungen sind inzwischen schon aufgetaucht, aber:

    diese Auswirkungen hat der Fehler nur bei GCode-Flavor "Ultimaker" (bzw. "UltiGCode"). Alle, die das inzwischen auf "Marlin" umgestellt haben, merken nichts davon.

     

    Es gibt vielleicht auch gar nicht so viele Nutzer, die regelmäßig Firmware-Updates machen - wie man sieht, ist diese Strategie gar nicht so schlecht...

  3. 6 hours ago, Glomby said:

    So it turns out Octoprint indeed always executes the gcode scripts and deleting them did fix the problem.

     

    I added two things to the "After print is finished"-script, retract the filament a bit (additional 11 mm as "end-of-print-retraction")
    and home all axis.

    I think Octoprint does this not automatically  - in opposite to the firmware if you print from sdcard.

  4. 4 hours ago, remars said:

    Laut Ultimaker soll man ja unbedingt mit jeder Curaversion die Firmware updaten, oder?

     

    Das wäre mir neu... wer hat das denn gesagt?

     

    Außer ein paar Kommentaren hat sich seit Ende Mai 2017 an der Firmware nichts mehr geändert, es gibt also vermutlich in den "Release Notes"

    nichts zu berichten. Ich würde eher nach dem Datum schauen. Die neueste UM2+ Firmware ohne diesen Fehler müsste aus 04/2017 sein.

    Evtl. auch 02/2017, dann wurde für Cura 2.5 gar keine neue Version kompiliert (das kommt auch gelegentlich vor).

     

    Firmware und Cura sind im Grunde nicht voneinander abhängig, da kannst Du alle Versionen verwenden.

    Der Drucker kommt auch ganz ohne Cura prima zurecht.

     

  5. 1 hour ago, remars said:

    ja ich habe kürzlich ein Firmwareupdate (arbeite mit Mac High sierra) gemacht

     

    Dann ist es leicht - pack die Firmware von Cura 2.5 wieder drauf.

     

    Der Fehler wurde Mitte 2017 eingebaut und offenbar bis jetzt noch nicht wieder korrigiert. Ich hatte das auf GitHub damals kommentiert (nach unten scrollen),

    und hier steht auch noch etwas dazu.

     

    Zum Update braucht der Arduino ein RESET, das schließt die SD-Card Methode aus..., das geht nur über USB und den bootloader

    oder ein externes Programmiergerät (aber das wäre wohl noch deutlich umständlicher... :))

    • Like 1
  6. 1 hour ago, gr5 said:

    Do you know if the UM2 board lets you plug a UMO temp sensor into a UM2 PCB temp input and just change the firmware?  The UMO outputs a voltage where 0V = 0C and 5V = 500C and everything in between is linear.  But the UM2 uses an opamp in some way to measure the PT100 but I don't remember what exactly it does.

     

    I doubt it... looks like there are a lot of additonal components between the sensor and the input pin... did i mentioned already that i have no clue about electronics...? :)

    Google says, the instrumentation amplifier is there to maintain dc precision and gain accuracy within a noisy environment - whatever that means...

     

    pt_100_input.thumb.PNG.22a9bf4746d2a7e6ddfeed76427c23e4.PNG


     

     

     

  7. Dear Mr. VULCAN,

    1. Please realize that you are talking to a community of users here, not to your paid support staff.
    2. I understand that you asked a question and you don't like our answers.
    3. No one guarantees and no one awaits an immediate solution to his very specific problem here.
    4. But the community tried at least to figure out what you're talking about.
    5. And as far as i can see is Mr. VULCAN the only person here that is uncivil all the time.
    6. And now: please go away and ask someone else.

    End of message.

     

    • Like 1
  8. 7 hours ago, ChrisRiddell said:

    noticed the LED lighting flickers for a couple seconds every now and then.

     

    Do you use the PID mode for the build plate? I heard that this generates a lot more electrical 'noise' than the 'bang-bang' mode and i wonder, if the flickering is related to this?

    If so, can you switch the PID mode off and check, if it makes a difference?

     

    In addition: during dual prints the power supply is working at it limits, perhaps there's a small voltage drop now and then that can cause the display jittering?

    Another test: try to reduce the value for the 'Total budget' in Preferences -> Power budget and check if it makes a difference.

     

    7 hours ago, ChrisRiddell said:

    can't run the auto pid tune

     

     

    I think the PID auto tuning is pretty useless in it's current implementation. It doesn't matter if you start it on the printer or via a serial console. Perhaps you'll get better results if you preheat the nozzle to a temperature near the target temperature before you start the auto-tuning.

     

    The defaults have changed for the UM2+ (35W) heaters:  p 12.00 i 0.75 d 55.00

    I would start with these and tune it manually, if necessary.

     

     

  9. 6 hours ago, appletart76 said:

    Here's a file I know it did it on.  It seems to happen right after the first layer goes down from Extruder 1 completes, then it switches to 2 for some reason, does a pass around the skirt then goes back to 1 and keeps on printing.

     

     

    It's tries to print a skirt with the second extruder.

    I see that support is enabled (but apparently not needed?)), which one is the "Support Extruder"?

     

    • Like 1
  10. 5 hours ago, ripacheco said:

    The problem is not buying a new nozzle. is to get Cura to properly generate proper g-code given an STL with vertical walls exactly 0.4mm thick.

     

    Great, if you cannot make the model solid, do what @gr5 suggested first.

    Set the line width in Cura to 0.25mm or lower and you will get 0.4mm walls (made of two lines).

    CuraEngine always generates one (outer) line per shell, that's just how it is designed.

    • Like 1
  11. 5 hours ago, gr5 said:

    I'm not sure where you need steps/sec though.  I'm not sure if that's what you need.

     

    @killerb77 gr5 is right, that's the calculation i talked about.

     

    @gr5

    I changed the speed constants for the material load/unload wizard from mm/s to steps/sec a while ago.

    The actual speed depends on the steps/mm setting now. The idea is to ensure, that the wizard can be used with different motors/feeders/steps

    without the need to recompile the firmware with different speed constants.

     

    For example:

    * the UM2 firmware uses 282 steps/mm and 100 mm/s  (= 28200 steps/s)

    * the UM2+ uses 369 steps/mm and 80 mm/s (= 29520 steps/s)

     

    I've chosen a value of 26500 steps/sec. That's a value that should be easily achievable with the given combination of Arduino and stepper driver.

    I don't know why it's necessary to reduce it to such a low value for the bondtech feeder.

     

    A similar thing is done with the acceleration.

    In short: it's exclusively used for the material change wizard (which you probably don't use anymore, right?) :sunglass:

  12. 5 hours ago, SCHNittER said:

    Hello, since Cura 3.2 the "Filament-Flow" wasn't correct transmitted to the Printer.

     

    AFAIK it was never different. Cura (and any other slicer that i know) uses it's own flow setting to calculate the volume of the used material (the moves of the e-axis).

    The "Flow" setting on the printer is completely independent and works in addition to that.

    The slicer does not generate any M221 commands (extrusion multiplier) into the gcode. If you really want that, you can put it in the start script.

     

  13. All examples that i have seen so far are using the 'K factor' only, so M900 K{material_linear_advance_factor} should be sufficient.

     

    http://marlinfw.org/docs/features/lin_advance.html#setting-the-k-factor-for-production

     

    But i also found a note that for Cura an additional "M900 W[width] H[height] D[diam]" works better.

    And layer height, filament diameter, and extrusion width are already known. Should be possible.

     

    https://mattshub.com/2017/10/02/linear-advance/

    (search for "One small note")

×
×
  • Create New...