Hallo Marcometaner,

Marcometaner hat geschrieben: es gibt offenbar ein Problem mit der RF.01.35.
Diese funktioniert bei manchen RF1000 nicht, bei anderen schon.

hier mal neugierig gefragt:

Welcher Unterschied ist Ausschlaggebend? (Hauptplatinen abhängig)?
Kann man eine Aussage machen: Bei welchem RF1000 funktioniert es und bei welchem geht es nicht?

LG AtlonXP

Hallo,

das ist ja das Problem, leider nicht.
Nach Rücksprache mit der Entwicklungsabteilung wurde an der Platine nichts mehr verändert seit dem vor Ewigkeiten
ein zusätzlicher Elko für den Lüfter verbaut wurde.
Somit hatten alle Platinen eigentlich die gleiche Version.
Es ist auch egal ob das Board komplett verkabelt ist oder nur das nötigste dran hängt.
Es wird gerade intern mit einer neueren Version getestet, aber die läuft auch nicht überall. Seltsamerweise funktioniert diese Version
auf einigen Druckern auf denen die 35 nicht läuft einwandfrei, das trifft aber auch leider umgekehrt zu
In diesem Sinne

OMG WTF Informations Flash

das muss ich erstmal verarbeiten und umsetzen

vielen vielen Dank für die schnelle Reaktion auf mein Problem.
Da schimmert doch eine kleines Licht am Tunnel Ende

Ich drücke euch die Daumen!

Wie ich erfahren durfte, kann es gut sein, dass ein Arduino-Compiler seine Arbeit gut macht, ein anderer aber nicht. Obwohl alles ok scheint.
Viel schlimmer: Man merkt es nur in Details. Da könnte man verrückt werden.

LG

99 little bugs....

One of the main reasons I would never become a programmer - I want to keep my sanity.

mjh11

Mmmmh.
Ich kann mir irgendwie nicht so ganz vorstellen, daß es sich hier um ein Compilerproblem handelt. Meiner Erfahrung nach liegt das Problem in 98% der Fälle nicht am Compiler . Wenn ein- und dieselbe Firmware auf dem einen Board / Drucker funktioniert und dem anderen nicht, dann sind meistens andere Probleme die Ursache (nicht initialisierte Stackvariablen wo die Reaktion von vorhergehenden Verwendung abhängig ist, das Überschreiben von Stack-Werten oder nicht-atomare Operationen auf Shared Variables bei Multithreading-Umgebungen oder Interrupt Service Routinen die noch nicht abgearbeitet sind während bereits die nächste Instanz derselben ISR initialisiert wird. Diese Szenarios sind aber unheimlich schwer zu debuggen vor allem, wenn sie so sporadisch / selektiv auftreten (großes Lob an die Firmware-Entwickler, welche die Firmware des RF1000 und RF2000 bis jetzt in einem solch stabilen Zustand gehalten haben ).

Und bei folgenden Problemen

Ich hatte in einer Konstellation zwischen jedem Befehl in OutputObject ein Com::printFLN( PSTR( "xxxxxxxxx()" ) ); eingebaut, um zu sehen, wie weit der Drucker läuft, dann gings.

tippe ich eher auf eine nicht initialisierte Variable, Überschreiben des Stacks oder ein Timing Problem da der Aufruf eine Subroutine aufruft und damit auf dem Stack etwas hinterläßt und der Funktionsaufruf auch ein bißchen Zeit verbrät. Gefunden habe ich aber nichts (ich entwickle fast ausschl. auf / für große Linuxserver in C++ und nicht im embedded Bereich).

Nix für ungut

An all die mir so wahnsinnig viel text gegeben haben ,

Danke für eure Arbeit und Interesse mir zu helfen.
Ich habe einieges überprüft anderes umgesetzt und OH mein Gott ich bin am Ende, naja fast, am Ende des Tunnels.
Er Druckt und zwar das was er soll und wie er es soll. noch ein bissel fein Justierung der Temp. lift und retraction und es läuft.

Ihr seid 3D GURUS



Danke an alle, sollte noch ma eine Baustelle auftreten weiss ich wo ich hin muss.

Tech. Daten

RF 1000
FW: 1.33
Renkforce Repetier Host 1.6.2
Slic3r


MfG

Hmm, ...
Wenn ich mich irre, habe ich einen Micro-Bug beim RF2000 in der Firmware gefunden.

Wenn ich am RF2000 die Steckdose ausschalte, den Resetknopf drücke und dann den Drucker wieder starte bleibt die Steckdose aus.
Im Menü steht "OFF".
Stelle ich dann übers Menü auf "ON" klickt das Relais kurz und die Steckdose ist aktiv.

Wenn ich am RF2000 die Steckdose eingeschaltet lasse, den Resetknopf drücke und dann den Drucker wieder starte bleibt die Steckdose aus.
Im Menü steht "ON".
Stelle ich dann übers Menü auf "OFF" und danach wieder auf "ON" klickt das Relais kurz und die Steckdose ist aktiv.

Da passt was nicht

Warum die Steckdose nach dem Drucker Ausschalten immer aus bleibt:

RF2000.h -> Zeile ~1191 Aber warum zieht das Menü nicht korrekt sein schalterlein auf OFF:

Dass die Steckdose vom Nutzer aktiviert wurde, wird im EEPROM gespeichert. Und nachdem der Drucker die Steckdose auf "AUS" == OUTPUT_230V_DEFAULT_ON == 0 initialisiert hat wird erst das EEPROM geladen.
Aber dann wird nur umgesetzt, diese Info aber nicht auf den Pin geschrieben.

Printer.cpp -> ~Zeile 1112 Printer.cpp -> ~Zeile 1177 Und: EEPROM::init(); -> EEPROM::readDataFromEEPROM() -> Printer::enable230VOutput = HAL::eprGetByte( EPR_RF_230V_OUTPUT_MODE );
Ohne WRITE(OUTPUT_230V_PIN, enable230VOutput);, was sonst überall drin ist, wenn diese Variable umgeschrieben wird.

Kann das sein?
Evtl. streiten sich da zwei mögliche Konventionen, wie man mit der Steckdose beim Druckerstart umgehen sollte. Speichern vs. immer AUS/AN.

LG

Hallo,

könntet Ihr mir einen Gefallen tun?
Bei wem läuft diese Firmware und bei wem hängt sie nach dem flashen?
Und welches Betriebssystem und welche Arduino Version verwendet Ihr?
Spitze wäre es noch wenn Ihr schreiben würdet von wann die Hauptplatine ist, bei vielen ist ein Aufkleber angebracht mit
der Produktionswoche und dem Jahr. Das selbe gilt für das Herstellungsdatum vom ATMEGA.
Hab ein Bild angehängt und die entsprechenden Stellen markiert.

Danke schonmal.

MfG

Hallo Nibbels,


die 230 V Steckdose soll nach dem Start der Firmware immer aus sein. Natürlich sollte das auch im Menü entsprechend angezeigt werden, d.h. wir werden das Menü in der kommenden Version der Firmware entsprechend korrigieren.


mfG
RF1000