Seite 10 von 13

Re: Community Mod RFx000 Firmware :: Neue Stable (Stand 1.37x7 / 26.11.2017)

Verfasst: Mi 28. Mär 2018, 17:49
von Dieter
Das habe ich etliche male gemacht, bekomme aber keine verbindung hin.

Über Werkzeuge -> Bordinformationen holen gibt es folgende Meldung:

BN: Unbekanntes Bord
VID: 0403
PID: 6001
SN: Laden sie irgendeinen Sketch hoch, um sie abzurufen

In Arduino ist unter Programmer angegeben: AVRISP mkll

Unter Sketch -> Hochladen bekomm ich folgende Meldung, (nur der relevante Teil)

Using Port : usb
Using Programmer : stk500v2
avrdude: usbdev_open(): did not find any USB device "usb" (0x03eb:0x2104)

avrdude done. Thank you.

Beim Hochladen des Sketches ist ein Fehler aufgetreten

LG

Re: Community Mod RFx000 Firmware :: Neue Stable (Stand 1.37x7 / 26.11.2017)

Verfasst: Mi 28. Mär 2018, 17:54
von Dieter
das sollte heißen

sketch → Hochladen mit Progammer

Re: Community Mod RFx000 Firmware :: Neue Stable (Stand 1.37x7 / 26.11.2017)

Verfasst: Mi 28. Mär 2018, 18:19
von Nibbels
Ah, du hast ein Problem mit dem Port?

Eigentlich sollte dein PC "über USB" einen Seriellen Port erkennen. Der heißt z.B. COM3. Diesen Port musst du angeben!
Das kann nicht "USB" sein.

Siehe deinem Zitat:
Dieter hat geschrieben: System wide configuration file is "C:\Program Files (x86)\Arduino\hardware\tools\avr/etc/avrdude.conf"

Using Port : COM3
Using Programmer : wiring
Overriding Baud Rate : 115200
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_getsync(): timeout communicating with programmer

avrdude done. Thank you.
(Wenn du den USB-Port angesteckt lässt kann der Drucker aus sein, aber der USB-Port wird erkannt, da er zumindest bei mir am RF2000 vom Rechner aus gepowered wird.)
Wenn du übrigens im Raum Stuttgart wohnen würdest, könnte die Problemlösung sehr einfach sein ^^.

LG

Re: Community Mod RFx000 Firmware :: Neue Stable (Stand 1.37x7 / 26.11.2017)

Verfasst: Do 29. Mär 2018, 09:36
von Dieter
Erst mal vielen Dank

Ich wohne bei Dortmund, das sind 4-5 Std Fahrt.
Für mich gar kein Thema, Drucker ins Auto und ab nach Stuttgart.
Also die Einladung nehme ich gerne an.

LG

Re: Community Mod RFx000 Firmware :: Neue Stable (Stand 1.37x7 / 26.11.2017)

Verfasst: Do 29. Mär 2018, 11:59
von Nibbels
Dieter hat geschrieben:Erst mal vielen Dank

Ich wohne bei Dortmund, das sind 4-5 Std Fahrt.
Für mich gar kein Thema, Drucker ins Auto und ab nach Stuttgart.
Also die Einladung nehme ich gerne an.

LG
Gerne!

Ich bin bis Ostermontag gegen Mittag immer da :) -> Schreib mir einfach ne PN.
Sonst die nächsten Wochenenden.

Du musst aber abwägen, ob es nicht aufwandseffizienter wäre, wenn sich Marcometaner deine Platine einmal anschaut.
Der Grund für den Vorschlag ist, dass ich deinen Fehler kaum nachvollziehen kann und mich trotz Recherche immer noch wundere wie dieser Fehler sein kann. Es wäre schade, wenn die Platine nach Murphys Law einfach kaputt ist. (Dass du RF_MICRO_STEPS oben mit RF1000_MICRO_STEPS zitiert hattest, wird wohl ein Vertipper gewesen sein, denn RF1000_MICRO_STEPS gibts nicht.)

Aber .. Kaffee haben wir und es ist immer interessant mit anderen 3D-Druckern zusammenzusitzen.
(Da fällt mir auf, dass ich auch schon länger bei AtlonXP vorbeischauen wollte ^^.)

LG

Re: Community Mod RFx000 Firmware :: Neue Stable (Stand 1.37x7 / 26.11.2017)

Verfasst: Do 29. Mär 2018, 12:18
von Nibbels
Um mal wieder den Fortschritt zu posten:
Es gibt inzwischen eine 1.41.13, die ich bisher aber nur auf meinem Github stehen habe.
  • BACK+OK+PLAY beim Starten halten löst einen EEPROM-Reset (ohne dass diese Werte geladen werden) aus und initialisiert die Werkseinstellungen (Genauer: Schreibt das ins EEPROM, was in der Configuration.h / RFx000.h eingestellt ist.)
  • Man kann die Startmade M3912 nun "skippen" wenn man Play drückt, solange die Startmade druckt. Das finde ich super, wenn ich z.B. eben einen Druck beim Start abbrechen musste und klar ist, dass die Düse schon voll ist.
  • Der PT100 ist nun die Sensortype 53. Es handelt sich hier um einen PTC-Verlauf statt dem üblichen NTC-Verlauf und bis easygo25 sein OK gibt, ist das ungetestet. "Ungetestet" erwähne ich, weil die Suchfunktion nach dem Umrechnungswert hier "anders rum" suchen muss, da die Funktion steigt statt fällt, also gibts leichte Unterschiede im Quellcode.
Die Changlog die über die 1.39+ hinausgeht sieht aktuell so aus:
1.39+ bis 1.41.13 hat geschrieben:V RF.01.41.13.Mod alpha (2018-03-28)
- We can now skip the rest of the M3912 startline by pressing play while printing the start line. (Might save some tiny amounts of plastic from time to time.)
- the eeproms max feedrates are dropped and overwritten if they are bigger than configuration max values.
- the eeproms homing feedrates are dropped and overwritten if they are higher than configuration max values.
- extruder steps/mm are corrected to default if they are set > 5540steps/mm
- if we press the 3 keys "Back", "OK" and "Play" while boot time the eeprom values are reset to defaults before being loaded.
- some reordering in boot time configuration to prevent to early use of things.
- compiling without SDSUPPORT is possible again. (~+1kb ram frei -> ~+8 MOVE_CACHE möglich)

V RF.01.41.12.Mod alpha (2018-03-26)
- cleaned up the thermistor functions
- depreached the use of int16_t targetTemperature and crushed void TemperatureController::setTargetTemperature(float target, float offset) to very few lines.
- added PT100 support on temperature sensor number 53 again. (This PT100 sensor board is sensortype no. 13 in original repetier but conrad dropped their V3 hotends sensor to this number.)
- inserted MAX_ROOM_TEMPERATURE as the default low constraint in some locations where a temperature has to wait for the target temperature.
- heater off now means targetTemperature=0 (not <15 or whatever in some locations).
- added sensortype 0 as 25°C dummy (like repetier did)

V RF.01.41.11.Mod alpha (2018-03-16)
- added a microsteps reset to the function that resets the configuration to defaults (Werksreset)
- fixed that EEPROM::initializeAllOperatingModes() did not update checksum. (Had been forgotten when using M502 and UI_ACTION_RESTORE_DEFAULTS )
- fixed EEPROM::updatePrinterUsage() to 1.39 version when not using FEATURE_MILLING_MODE
- cleaned up all the double coded code for "#else //FEATURE_MILLING_MODE" to one version.

V RF.01.41.10.Mod alpha (2018-03-16)
- tweaks and fixes for the case that M190 / M109 is running(/waiting for temperature) and meanwhile the user changes temperatures using Menu->Extruder-> at the printers display.

V RF.01.41.09.Mod alpha (2018-03-15)
- making the Z-Offset-Scan faster.
- small fix for M3913 / M3914 abort.
- implemented digit homing for M3913 / M3914

V RF.01.41.08.Mod alpha (2018-03-15)
- abort M3913 / M3914 (when moving) by ok-Button and back-Button
- commented all g_uStartOfIdle to find bugs -> adjusted some idle-times for better usability
- some more tweaks around checks if zCMP is blocked
- removed matrix-version check within calculateZScrewCorrection. the reason for this was an overflow we already corrected months ago.
- checked all uid.lock / unlocks
- cleaned up uid. object references within the UIDisplay itself. (but it didn't change rom size)

V RF.01.41.07.Mod alpha (2018-03-14)
- Support for REPETIER_PROTOCOL:3
- MoveZ now releases Z correctly. Printer::stepperDirection[Z_AXIS] = 0; (It was possible that the printer hung with the wrong combination of moveZ directions + waitUntilEndOfAllMoves)
- Stability: Commands::waitUntilEndOfAllMoves() now checks if zCMP is blocked by stepper direction and ignores wait in that case.
- cleanup of HomeY und HomeX
- ENDSTOP_X_RETEST_REDUCTION_FACTOR is not used at homeY anymore. -> ENDSTOP_Y_RETEST_REDUCTION_FACTOR instead.
- tuned Z_ENDSTOP_MAX_HYSTERESIS to 0.35f
- The rule that the bed tunes down by zCMP if homed and matrix>0 is bad if you want to scan anything. -> REMOVED!
- Preheat PLA/ABS does not block status line in display anymore.

V RF.01.41.06.Mod alpha (2018-03-13)
- more testing on serial -> Fletcher error correction really seems to work flawless.
- re-/implemented some debugging gode for serial errors
- fixed formats in GCode::printCommand()
- fixed sending Com::tWrongChecksum when using parseBinary (I once forgot newline)
- we temporarily set Z_ENDSTOP_MAX_HYSTERESIS 0.5f for mhiers tests

V RF.01.41.05.Mod alpha (2018-03-12)
- corrected unit calculation in void Printer::MemoryPosition()
- rise of LOW_TICKS_PER_MOVE to 500k (It might not have a big effect but maybe on some parts)
- removed some old TODOs on which I am now absolut sure how to handle them.
- dont show "setTemperatureForExtruder(): cant set Temp for Extr." when it is set to 0°C.
- switched MOVE_CACHE back to 17 for testing reasons.
- update void Printer::MemoryPosition() close towards repetier
- fix missing PSTR -> https://github.com/repetier/Repetier-Fi ... issues/763
- deleted UI_ANIMATION and some unused functions

V RF.01.41.04.Mod alpha (2018-03-12)
- added FEATURE_DEBUG_MOVE_CACHE_TIMING to debug movecache fill while printing.
if you want to adjust LOW_TICKS_PER_MOVE to default: M3993 P300000 (LOW_TICKS_PER_MOVE is 300000)
if you want to read and drop statistics: M3993

V RF.01.41.03.Mod alpha (2018-03-10)
- some tiny tweaks
- cleanup of homeZ for better reading. Inserted a lot of casts.
- removed some functions which are not needed anymore because their purpose already got removed.

V RF.01.41.02.Mod alpha (2018-03-10)
This is the "intelligent filament load update"
- new M3913 P[digits] which mounts/extrudes filament until Pxxxx digits are reached then stops.
- new M3914 P[digits] which unmounts the extruder by slowly heating and checking force. It is/was quite hard to test out good settings for unmount. This might be updated in future, but I like it.
- inserted M3913 and M3914 into MOUNT_FILAMENT_SCRIPT_... and UNMOUNT_FILAMENT_SCRIPT_... to vastly improve "Menu->Extruder->(Un)Load Filament"
- compressed functions for MOUNT_FILAMENT_SCRIPT_WITH_HEATING and MOUNT_FILAMENT_SCRIPT_WITHOUT_HEATING functions to one, because they where quite identical.

V RF.01.41.01.Mod alpha (2018-03-10)
- output object speeds are now limited to normal homing speeds. OctaStepping made that too fast. Thx@ AtlonXP
- MOUNT and UNMOUNT Scripts got an extra G92 E0 to in some cases prevent undo afterwards. Thx@ easygo25
- sync of UNMOUNT_FILAMENT_SCRIPTs and MOUNT_FILAMENT_SCRIPTs for both devices (RF2000/RF1000)

V RF.01.41.00.Mod alpha (2018-03-09)
- deleted M3002 and M3003 because they are not needed anymore. (We use M3007 and M3008 for this functionality. Not using M3007/M3008 it is even better because this mod has an automatic mode for placing those two values right :D)
- deleted M3100 because we have a smart menu point (Menu->Position->Z-Step: XXX um) for that and this functionality is only used in menu.
- deleted M3101 because there is no real need for this adjustment. Normal extrusion is not "directsteps over button"
- deleted M3102 because we have M3105 to configure Pause-Position in [mm]
- made the automatic startline a bit shorter when having dual hotend (i always forget to change x-axis-length when testswitching)
- the automatic startline only shifts in y when having a dual hotend, not on single anymore.
- split RF_MICRO_STEPS to {RF_MICRO_STEPS_XY, RF_MICRO_STEPS_Z, RF_MICRO_STEPS_E}
- added menu for changing Micro Steps:
XY is unlocked for 16,32,64 Microsteps
Z is unlocked for 16,32 Microsteps
E is unlocked for 16,32,64,128 Microsteps.
(High Microsteps are only usefull if you have low steps/mm. Otherwise you just get a slow printer. My testprint worked fine on E=64, Z=32, XY=64.
Using 128+ Microsteps on XY sounds horrible and is slower than 128=65mm/s or 256=32mm/s -> not a good choice!
I think E shouldnt have more Steps/mm than ~1200 max. that corresponds to a speed < 25mm/s for retracts.)
- changed some minor details to unhook RF_MICRO_STEPS from (some) places of use without inheritance.
- Z_OVERRIDE_MAX is now Printer::ZOverrideMax.
- reduced automatic startline spacing (for multiple lines) to 1.5mm instead of 2.0mm.
- removed and replaced some configuration with STEPS inside, because they are not good for configurable Micro_Steps and bad for EEPROM-configurable steps/mm. This totally cleaned up HBS-Scan configuration. :)
- removed static XAXIS_STEPS_PER_MM, YAXIS_STEPS_PER_MM, ZAXIS_STEPS_PER_MM from places which are no pre-initialisers.
- removed some configuration lines which had no effect anywhere
- disabled FEATURE_VISCOSITY_TEST by default to save rom space.
- included mhiers push https://github.com/Nibbels/Repetier-Fir ... e9309ab808 of changing WORK_PART_SCAN_X_STEP_SIZE_MIN_MM 5 (etc.) into Nibbels branch too.
- g_nManualSteps[E_AXIS] and g_nPauseSteps[E_AXIS] are now updated according to active steps/mm when choosing an extruder. Extruder Button speed should now stay the same when changing steps/mm.
- investigating g_nManualSteps[E_AXIS] and PrintLine::performDirectSteps();
1) i found a second reason for the E_Axis to have a time lag using PrintLine::performDirectSteps() -> Hal.cpp OCR1A = too high at the end of the function.
2) i found a third reason for the E_Axis to have a time lag using 128 Microsteps / 0.9° Stepper = 2560Steps/s: Advance might just fill up working too slow. -> Stay beneath 1280 Steps/mm
- fixed RF2000 optional temperature sensor. We removed Temptable 15 and renamed it to 14. I forgot to change this default Tempsensor as well. (See V RF.01.38.Mod (2017-12-28))
Eine sehr interessante Sache ist, dass man nun den SD-Support weglassen kann. Der Drucker hat dann einfach keine Unterstützung für SD-Karten.

(configuration.h)

Code: Alles auswählen

// ##########################################################################################
// ##   configure the SD Card
// ##########################################################################################

/** \brief  Select whether the SD card is supported. */
#define SDSUPPORT                           0
Ebenso ist erwähnenswert dass man als reine Drucker-Firmware (Keine Fräsfunktionen) auch den Milling_Mode weglassen kann.
(RF1000.h / RF2000.h oben)

Code: Alles auswählen

/** \brief Allows to use the device for milling */
#define FEATURE_MILLING_MODE                0                                                   // 1 = on, 0 = off
Warum könnte man auf diese Idee kommen?
Weils RAM spart ^^. Die SD-Karte kostet fast 1kbyte Ram.

Den Ram kann man als größere MOVE_CACHE_SIZE verwenden.

Code: Alles auswählen

/** \brief Number of moves we can cache in advance.
This number of moves can be cached in advance. If you wan't to cache more, increase this. Especially on
many very short moves the cache may go empty. The minimum value is 5. */
#define MOVE_CACHE_SIZE                     25

/** \brief Low filled cache size.
If the cache contains less then MOVE_CACHE_LOW segments, the time per segment is limited to LOW_TICKS_PER_MOVE clock cycles.
If a move would be shorter, the feedrate will be reduced. This should prevent buffer underflows. Set this to 0 if you
don't care about empty buffers during print. */
#define MOVE_CACHE_LOW                      20
Ohne SD-Support und Milling-Mode kann ich hier locker 25/20 anstatt 17/14 einstellen. Ob das wegen dem Mikrostottern was bringt, kann ich nicht sagen, aber sollte das Stottern wegen dem Cache sein, sind zumindest Tests empfehlenswert. Mit SD-Karte testen geht dann leider nicht, nur der USB-Druck über Raspberry/PC. (Was ich sowieso immer mache.)

LG

Re: Community Mod RFx000 Firmware :: Neue Stable (Stand 1.37x7 / 26.11.2017)

Verfasst: Do 29. Mär 2018, 21:56
von AtlonXP
Hier zur Abwechselung mal was Nettes.

Das Drucken mit Z Lift (0,3 mm) scheint zu funzen. (FW 1.39 +)
Es wurde von mir über mehre Stunden (mehrmals) natürlich über die 10 mm Z- Kompensation hinaus fehlerlos gedruckt.
In S3D waren 3 Prozesse hinter einander geschaltet, mit unterschiedlichen Layer Höhen in einem Druck Jopp.

Zum Thema Drucker stockt über USB, bei mir kommt es definitiv von meinem zu schwachen Schlepptopp.
Ich habe Win 7 / 64 drauf und bemerke auch wie die System Ressourcen in den Keller gehen.

Ich vernute selbst mit noch weiter aufgedrehtem Puffer wird dieses Verhalten sich nicht ändern.
Die Zeit wo der Drucker stehen bleibt ist bei mir, einfach zu groß!

Ich werde erst weitere Tests mit neuer PC Hardware machen.
Solange ist es halt soo..

Das mit dem EEPROM-Rest finde ich super!
Das hatte mich auch schon mal geärgert. ;-)


LG AtlonXP

Re: Community Mod RFx000 Firmware :: Neue Stable (Stand 1.37x7 / 26.11.2017)

Verfasst: Do 29. Mär 2018, 23:22
von Digibike
Hi,

ich habe meine Drucker zwar nicht Online, sondern nur über SD, aber ich meine da mal was gelesen zu haben, dass man
die Preview abschalten kann. S3D "verheizt" da nämlich anscheinend massiv Rechenpower...
Hab ich bei der 3D-Druck-Community mal vor kurzem gelesen. Damit könnte das Problem eventuell bei dir erschlagen sein,
oder AtlonXP? Sind ja nicht die einzigen mit dem Problem... :zwinkern:
Den Thread findest du hier

Gruß, Christian

Re: Community Mod RFx000 Firmware :: Neue Stable (Stand 1.37x7 / 26.11.2017)

Verfasst: Fr 30. Mär 2018, 00:39
von AtlonXP
Danke Christian,

nicht nur das Preview ist abgeschaltet sondern auch noch das Log. dazu. ;-)
Wenn ich nicht den Lötkolben für das Schlepptop ausgepackt hätte,
dann würde ich gar nicht mit dem Ding arbeiten können.

Der 18. April ist Stichtag.
Danach wird sich entscheiden, was ich neben meinen Drucker hinstelle.
Ich sag nur mehr CPU Kerne mit einer guten Grafikkarte und massig Hauptspeicher!

Was mich interessiert:

Läst sich unsere RFX000 Klasse gut mit einer USB 3.0 Schnittstelle, oder höher, betreiben?

Wer es macht und keine Probleme hat, bitte melden.

Im Voraus vielen Dank.

LG AtlonXP

Re: Community Mod RFx000 Firmware :: Neue Stable (Stand 1.37x7 / 26.11.2017)

Verfasst: Do 19. Apr 2018, 23:02
von OAthlon
Halli Hallo alle miteinander!
Ich habe mir vor ein paar Tagen die Repetier-Firmware-master installiert. Beim Starten von RF1000 wird als Firmware die 1.38 angezeigt.
Nach der Installion habe ich einen Heatbettscan ABS durchgeführt, der sage und schreibe vom Start bis zur Bestätigung " Scan complett " 46 min. dauerte. Extruder wird auf 100°C und das Heizbett auf 130°C aufgeheizt und nach ca. 15 - 20 min. beginnt dann endlich einmal die 132 Punktabtastung auf dem Heizbett. Nach Beendigung dieser Abtastung fährt das Heizbett ca. 2 cm nach unten und der Extruder in die Mitte des Heizbettes und heizt den Extruder auf 260°C auf ( Heizbett 130°C), und nach weiteren ca. 10 min findet eine einzige Abtastung in mitte des Heizbettes statt.
S o l l d i e s e r A b l a u f s o s e i n???????
Nach dem Heizbettscan ABS druckte ich dann ei Teil aus, alles okay.
Dann wollte ich ein nächstes Teil ausdrucken und der erste Layer fand keine Haftung mehr auf dem Heizbett !!!!
Es lies sich kein Teil mehr ausdrucken, da der Abstand Bett / Extruder ca. 1mm war.
Habe daruf hin einen neuen Heizbettscan ABS durchgeführt / 46 min. , und konnte danach wieder ein Teil ausdrucken. Die darauf folgenden Ausdrucke hielten wieder nicht auf meinem Heizbett !!!!!
Vlt ist dieses Problem schon bekannt und benötige dringend Hilfe.

Meine Grundeinstellung bei kaltem Heizbett und Extruder ist 0,3mm