Hi, ich suche für ein eizelnes Project einen Programmierer gegen Bezahlung. (ich bitte höflichst alle, die kein Interesse haben, hier keine Grundsatzdiskussion zu beginnen) - leider keine Festanstellung - Vergütung liegt irgendwo zwischen 200€ - 500€ - Der funktionale Code für einen ATMEGA16-16PU existiert bereits und funktioniert zu 95% Die Aufgaben in etwa: Existierenden AVR-Code (als Eclise Project unter Linux vorhanden) - in Ein C-Make Project mit ATmega644PA-PU wandeln - Weiterführende inline Doku, (damit ich) CMake besser verstehe! - In ein Clion-Projekt einbinden - Refactoring des Codes!! Funktionale Module sauber trennen und - alles was irgendwie zu kapseln geht mit Unit-Tests abdecken! - WatchDog sinnig einbauen und aktivieren. - [Optional] Simulation für den ATmega644PA-PU mit einbinden (Doku!) - [Optional] Das ganze CLion-Project (vorkompilierte AVR-Toolchain) auf Windows bauen lassen (Doku) Hardware Hintergründe: - 2 Temperatursensoren - I2C- Display - Einige Taster - 3x 230V Ausgänge (Heizung/Rührer/Kühlung) Häufigste aktuelle Probleme: - "Der µC friert ein" während er 36°C anzeigt aber den Tiegel immer weiter heizt! - Sensorüberwachung (Fehleranalyse/Kabelbruch) greift nicht. Ich freue mich über tatkräftige Hilfe. Gerne auch als Team aus 2-3 Mann. (Es eilt leider etwas) Grüße David
> - Der funktionale Code für einen ATMEGA16-16PU existiert bereits und > funktioniert zu 95% die Einschätzung "95%" würde ich bei der Aufgabenbeschreibung mal sehr in Frage stellen. > - Weiterführende inline Doku, (damit ich) CMake besser verstehe! > - Refactoring des Codes!! Funktionale Module sauber trennen und > - alles was irgendwie zu kapseln geht mit Unit-Tests abdecken! > - "Der µC friert ein" während er 36°C anzeigt aber den Tiegel immer > weiter heizt! > - Sensorüberwachung (Fehleranalyse/Kabelbruch) greift nicht. [...] > - Vergütung liegt irgendwo zwischen 200€ - 500€ Debugging, Refactoring, Testen und Dokumentieren fremden Codes zu einem Festpreis? Das erscheint mir unrealistisch und unprofessionell. Denn der potentielle Auftragnehmer weiß nicht was da für Murx in dem Code drin ist und muss ihn dafür erst mal vollständig verstehen und sich tief in den bestehenden Code einarbeiten. Den Aufwand dafür vorweg realistisch einzuschätzen ist so gut wie unmöglich. Das ist eine typische "Feuerwehr"-Aufgabe und wird normalerweise nach Stunden/Tagessatz bezahlt.
Gerd E. schrieb: > Debugging, Refactoring, Testen und Dokumentieren fremden Codes zu einem > Festpreis? 12KB Flash bietet nicht unendlich viel Spielraum für verbuggten Code. > Das ist eine typische "Feuerwehr"-Aufgabe und wird normalerweise nach > Stunden/Tagessatz bezahlt. Auch da hätte ich nichts gegen einzuwenden. Letztendlich ist es ein Regelkreis, der stabil und sicher laufen muss. (Wir reden hier von Minuten nicht µSec) Drumherum ein Menue und Display, um einige Parameter wie Uhrzeit einstellen zu können. DIESES stoppt den Regelkreis und kann daher als "nicht kritisch" betrachtet werden. Vor Dokumentation sollte man auch nicht sofort zurückschrecken. Am lieben hätte ich ja Hilfe zur Selbsthilfe, doch da packt der geübte denke lieber das ganze Project an, statt sich über Schnipsel zu ärgern, die ich aus einer Vermutung heraus zuwerfe. ------------------------------------------------------ Mir würde für den Anfang ja eine typisches "Hallo TDD" in Clion reichen. Momentan bekomme ich nicht Mals das empfolene "googletest" eingebunden um eine Methode zum füllen einen Buffers testen zu können. Cygwin kommt <stdint-gcc.h> für uint8_t daher und gtest kompiliert nur mit C++ statt C. Ich brauche ein Grundgerüst, um am PC entwickeln und testen zu können und dann ERST alles wieder auf den µC zu schieben. Grüße David
> 12KB Flash bietet nicht unendlich viel Spielraum für verbuggten Code. In 12kB passt VIEL rein. Insbesondre auch grauenvoll-µC-abhängiger Code. Kannst Du mal cloc drüberlaufen lassen und dessen Ausgabe hier zeigen? > Vor Dokumentation sollte man auch nicht sofort zurückschrecken. Das hättest Du dem ursprünglichen Entwickler sagen sollen. Doku ist eigentlich selbstverständlich und macht - wenn man sie selber macht - wenig Mehraufwand. Wenn man dagegen nachträglich fremden Code dokumentiert macht das um mehrere Größenordnungen(!) mehr Mehraufwand.
Clion? Nie gehört und damit bin ich auch schon raus. Ich denke aber, für diese Aufgabe wirst Du einen Spezi brauchen, der sich mit diesem Clion-Wasauchimmerdasist so gut auskennt, daß er den fremden Code versteht und dann darin auch ohne Dokumentation (die er ja selbst anfertigen soll) arbeiten kann. Ich stelle da zumindest mal den Preis in Frage. Ist denn wenigstens die Hardware dokumentiert? Vielleicht kommst Du besser dabei weg, wenn Du das alte Programm wegschmeißt wenn es nicht fehlerfrei funktioniert (und der Programmierer, der das geschrieben hat, nicht mehr verfügbar ist) und ein neues Programm schreibst.
D a v i d K. schrieb: > Hardware Hintergründe: > - 2 Temperatursensoren > - I2C- Display > - Einige Taster > - 3x 230V Ausgänge (Heizung/Rührer/Kühlung) > > Häufigste aktuelle Probleme: > - "Der µC friert ein" während er 36°C anzeigt aber den Tiegel immer > weiter heizt! > - Sensorüberwachung (Fehleranalyse/Kabelbruch) greift nicht. Warum wurde das nicht per SPS realisiert?
G. 4. schrieb: > Das hättest Du dem ursprünglichen Entwickler sagen sollen. Doku ist > eigentlich selbstverständlich und macht - wenn man sie selber macht - > wenig Mehraufwand. Wenn man dagegen nachträglich fremden Code > dokumentiert macht das um mehrere Größenordnungen(!) mehr Mehraufwand. ICH bin der Urheber des derzeitigen Codes und habe vor 2 Jahren mir alles a la Blackbox zusammengeschrieben, da der Vorgänger nicht bereit war seinen Assembler raus zu geben und ich wiederum nicht bereit war Assembler zu lernen, wenn ich etwas minimal abändern möchte.
Jens M. schrieb: > Warum wurde das nicht per SPS realisiert? Schön das wieder alles in Frage gestellt werden muss. Ich bitte hier um Softwarehilfe, bitte bleibt bei meiner Frage. Wenn mir keiner helfen kann oder will, sollte dieser Thread leer bleiben und sich nicht mit Beitragsmüll füllen. Danke!
D a v i d K. schrieb: > ICH bin der Urheber des derzeitigen Codes Das klingt aber eher so als ob du "ziellos" Code-Fragmente zusammengeschustert hast ohne zu wissen was du tust... D a v i d K. schrieb: > alles a la Blackbox zusammengeschrieben, da der Vorgänger nicht bereit > war seinen Assembler raus zu geben und ich wiederum nicht bereit war > Assembler zu lernen ... und jetzt nicht weißt was der Code machst bzw. wie du was änderst. Ich glaube auch eher bei 0 Anfangen ist da sinnvoller, scheinbar ist die Steuerung nichts weltbewegendes. Wenn die Hardware schon steht und funktioniert könnte das fast schneller von der Hand gehen wie umgekehrt. Wenn du mit C und Mikrocontroller nicht gut klar kommst, wäre vielleicht jetzt auch der Zeitpunkt auf ein anderes System zu wechseln, egal ob was mit ESP/ARM und LUA/MicroPython (einfacher wie C), ein RaspberryPI oder eine SPS.
Jens M. schrieb: > D a v i d K. schrieb: >> Hardware Hintergründe: >> - 2 Temperatursensoren >> - I2C- Display >> - Einige Taster >> - 3x 230V Ausgänge (Heizung/Rührer/Kühlung) >> >> Häufigste aktuelle Probleme: >> - "Der µC friert ein" während er 36°C anzeigt aber den Tiegel immer >> weiter heizt! >> - Sensorüberwachung (Fehleranalyse/Kabelbruch) greift nicht. > > Warum wurde das nicht per SPS realisiert? Weil er sich so die 100€ für die SPS sparen konnte. ;) PS: Je nach Aufbau wäre es wohl am einfachsten das alles neu zu entwickeln mittels SPS oder wenn es wirklich ein eigenes PCB sein muss ESP32/Cortex-M. "Schnell einarbeiten" wird gerade von denen unterschätzt die keine Ahnung von der Materie haben. So klingt das für mich ziemlich nach Müll, wer entwickelt denn bitteschön unter Linux mit eclipse und migriert das dann auf Windows mit clion und cygwin der vermutlich nicht mal ATmega Code generieren kann? Und dann nicht nur Fehler beheben sondern auch noch Refactoring usw., das klingt für mich nach ein paar Mannmonaten wenn wirklich der besehende Code genutzt werden soll (von dem dann vermutlich nicht mehr viel übrig bleiben dürfte). Denn fehlende Überwachung für Fehler klingt für mich schon nach deaktiviertem Watchdog und damit kann man dieses Programm als Schrott erachten, wieviel hat das gekostet? Auch nur 200€? PS: Ich könnte zwar sowas entwickeln (85-120€/Stunde), wären mehrere Mannwochen, aber wenn das schon so diffus gehalten wird und so spezielle Anforderungen gestellt werden von jemanden der nicht mit der Materie vertraut ist lass ich bei sowas lieber meine Finger weg.
:
Bearbeitet durch User
Ich hatte ganz vergessen, was der eigentliche Sinn des Internets ist. Shitstorm und tue ich mir nicht an. ==CLOSED===
Man versucht dir doch nur zu helfen und zwar langfristig. Wenn es besser ist den Code komplett neu zu schreiben oder die Hardware (teilweise) umzustellen weil - günstiger - besser zu warten - für alle stressfreier Was spricht dann dagegen? Damals wurde offensichtlich eine Fehlentscheidung getroffen, sonst würdest du jetzt nicht hier schreiben. Die Frage ist ob die Hardware-Plattform dann nicht auch schon eine Fehlentscheidung war, offensichtlich willst du ja sowieso schon den MC wechseln. Ich kann mir gerne deinen Code mal anschauen, erfahrungsgemäß und nach deinen Aussagen kommt man da aber nicht mit 200-500€ hin, wenn grundlegende Dinge (Fehlerbehandlung, friert einfach ein -> kein Watchdog, Codequalität so schlecht das Refactoring notwendig ist) nicht klappen. Da könnte es besser und schneller gehen den kompletten Code neu zu schreiben.
:
Bearbeitet durch User
> Ich hatte ganz vergessen, was der eigentliche Sinn des Internets ist.
Schnell und einfach Informationen übertragen. Hast Du die Ausgabe von
cloc schon beisammen?
200-500€ heisst: Weniger maximal 1 Arbeitstag. Das kannst du vergessen. Es ist völlig illusorisch in so kurzer Zeit all das zu Leisten, was du da forderst. Rechne mal eher mit einer Arbeitswoche zur Einarbeitung in das Projekt (Reverse Engineering). Dann eine Woche für's Refactoring, sowie eine ungewisse Zeit, um den eigentlichen Fehler zu finden. Optionale Aufgaben kann es bei einem Festpreis nicht geben, denn niemand wird Dir freiwillig Arbeitszeit schenken. Offensichtlich soll da eine Maschine gesteuert werden. Wirst du diese Maschine beim Programmierer zuhause aufbauen, oder soll er zu Dir kommen um es zu testen? Wer bezahlt die damit verbundenen Kosten? Gerd E. schrieb: > Das ist eine typische "Feuerwehr"-Aufgabe und wird normalerweise nach > Stunden/Tagessatz bezahlt. Ja Vorschlag: Dokumentiere die Hardware detailliert, und was die Software tun soll. Da du das Programm geschrieben hast, bist du der Beste Mann dafür. Dann zeigst du und die Doku und wir schauen nochmal drüber. Wenn die Doku gut ist, dann reduziert sich der Entwicklungsaufwand auf ein Minimum. > Gerne auch als Team aus 2-3 Mann. Ich glaube nicht, dass du eingespielte Teams Stundenweise buchen kannst - ausser in gewissen Etablissements.
D a v i d K. schrieb: > Schön das wieder alles in Frage gestellt werden muss. > Ich bitte hier um Softwarehilfe, bitte bleibt bei meiner Frage. > > Wenn mir keiner helfen kann oder will, sollte dieser Thread leer bleiben > und sich nicht mit Beitragsmüll füllen. Wenn man das lostritt muss man sich nicht wundern. Das ist ein Forum wo jeder schreiben kann was er will. Es gibt hier aber auch Annoncen, die kosten aber. Fragen dieser Art gehören nun mal zu einer seriösen Ermittlung. Das Mittel der Wahl ist anscheinend ungeeignet. Es wird auch nicht beschrieben worum es sich handelt sondern mit unspezifischen Abkürzungen gearbeitet. Weiter ist die Preisvorgabe in einem Bereich bei dem "wer mit Peanuts bezahlt wird von Affen bedient" zutrifft. D a v i d K. schrieb: > ICH bin der Urheber des derzeitigen Codes und habe vor 2 Jahren mir > alles a la Blackbox zusammengeschrieben, da der Vorgänger nicht bereit > war seinen Assembler raus zu geben und ich wiederum nicht bereit war > Assembler zu lernen, wenn ich etwas minimal abändern möchte. Wenn er den Code nicht rausgibt ist es wohl müßig.
Stefanus F. schrieb: > Vorschlag: Dokumentiere die Hardware detailliert, und was die Software > tun soll. Da du das Programm geschrieben hast, bist du der Beste Mann > dafür. Dann zeigst du und die Doku und wir schauen nochmal drüber. Mir fehlt der Einstieg, um die Routinen ordentlich zu testen! Fast alles davon würde ich mir ja selbst zutrauen (natürlich viel zu langsam) Wenn ich den Ansatz dazu hätte: also eine beliebige Methode in der IDE rauspicken, per Tastenkürzel ein UnitTest dafür anlegen und so lange refactoring betreiben, bis alles hübsch ist. (So ist mir das aus der Java-Entwicklung geläufig-->Hauptberuf unter Win10 --> Nun kommt aber C und das Fehlen aller nützlichen Frameworks/Tools auf meiner VirtualBox und vor allem das nicht WISSEN bei diesen Nebenjob durch Erbschaft daher)
Für mich liegt eine kleine Diskrepanz zwischen dem, was Du willst D a v i d K. schrieb: > Die Aufgaben in etwa: > Existierenden AVR-Code (als Eclise Project unter Linux vorhanden) > - in Ein C-Make Project mit ATmega644PA-PU wandeln > - Weiterführende inline Doku, (damit ich) CMake besser verstehe! > - In ein Clion-Projekt einbinden > - Refactoring des Codes!! Funktionale Module sauber trennen und > - alles was irgendwie zu kapseln geht mit Unit-Tests abdecken! > - WatchDog sinnig einbauen und aktivieren. > - [Optional] Simulation für den ATmega644PA-PU mit einbinden (Doku!) > - [Optional] Das ganze CLion-Project (vorkompilierte AVR-Toolchain) auf > Windows bauen lassen (Doku) und dem, was Du bereit bist auszugeben - Vergütung liegt irgendwo zwischen 200€ - 500€ D a v i d K. schrieb: > - Der funktionale Code für einen ATMEGA16-16PU existiert bereits und > funktioniert zu 95% Heißt für mich 95% der geplanten Entwicklungszeit sind um und max. 50% der Anforderungen sind umgesetzt (die typischen 95-Entwickler-Prozente :-) ) Clion heißt für mich, dass Du das auch auf andere Plattformen umsetzen willst (sonst würden ja Eclipse oder Atmel Studio vollkommen ausreichen ). . Clion wäre für mich eher ein "Krüppel" - besonders in Bezug auf die geplanten Test's - aber ich bin ja auch eher ein fortgeschrittener Laie.
D a v i d K. schrieb: > Mir fehlt der Einstieg, um die Routinen ordentlich zu testen! > > Fast alles davon würde ich mir ja selbst zutrauen (natürlich viel zu > langsam) > Wenn ich den Ansatz dazu hätte: Das wird nach meiner Erfahrung nichts. Nach der I/O und Timing Beschreibung ist eine SPS schlicht die bessere Wahl. Eine Logo! kostet 100 Euro und kann von jedem innerhalb weniger Stunden selbst programmiert werden. Es gibt auch ein Forum. Sie hat alle Zulassungen etc pp. . Einfache Software schreibt man da in einer Stunde. Jetzt möchte ich nicht weiter nerven, es ist ja nichts schlimmer als gut gemeint.
Hmm ich würde für die 500 Euro schon ein paar Tage investieren um das fertige Produkt zu entwickeln. Aber dann eben mit eigenen Werkzeugen und nicht irgendwas von Windows-Cygwin auf AVR-Code oder was manche hier oben für abenteuerliche Wege schildern. Ich bräuchte aber mindestens eine Aufstellung der Hardware und was das Ding können soll, um den Aufwand abzuschätzen. Und bitte genauer als "I2C-Display" oder "paar Taster". Bitte die Anzahl und ggf. Anordnung der Taster, welches I2C-Display und die Pinbelegung des ATMega. Für den I2C-Bus würde ich z.B. gern das Hardware-Interface benutzen. Wenn an den Pins aber z.B. die Relais hängen, ist man schon in den Arsch gekniffen. Alternative C: Ich baue die komplette Platine. Das dauert zwar am längsten, aber ich kann hinterher eine hohe Sicherheit geben, daß das Teil auch tatsächlich das macht, was es soll.
Dieter F. schrieb: > und dem, was Du bereit bist auszugeben > > - Vergütung liegt irgendwo zwischen 200€ - 500€ Es gibt halt Beiträge da kann man nur hoffen das es ein Troll ist, alles andere ... .
Ben B. schrieb: > Hmm ich würde für die 500 Euro schon ein paar Tage investieren um das > fertige Produkt zu entwickeln. Rate ich dringend von ab, unabhängig von der Höhe. Erst Leistungsumfang, dann Angebot. Den Preis vorher festzuzurren ist Glatteis. In der Regel werden beide nicht glücklich damit.
Am besten fängt man an diese Aufgabe zu lösen, in dem man zwei Dinge dokumentiert: -die vorhandene Hardware (welche Hardware ist verbaut, was sind die Schnittstellen zwischen den Sensoren/Aktoren etc.) -die Anforderungen (was soll eigentlich gemacht werden?) Wenn man einen sauberen Satz an Anforderungen hat, dann kann man den bisherigen Code getrost ignorieren. Übrigens kann man auch eine Maschinensteuerung weitgehend hardwareunabhängig programmieren. Dem eigentlichen Algorithmus ist es völlig Wumpe, ob er auf einem µC, einem PC oder sonstwo läuft. Also kann man den absolut problemlos auch auf einem PC entwickeln und testen.
:
Bearbeitet durch User
Mark B. schrieb: > Übrigens kann man auch eine Maschinensteuerung weitgehend > hardwareunabhängig programmieren. Dem eigentlichen Algorithmus ist es > völlig Wumpe, ob er auf einem µC, einem PC oder sonstwo läuft. Also kann > man den absolut problemlos auch auf einem PC entwicklen und testen. Wie machst du das dann mit I/O test? Bei meinen Steuerungen waren Vorbereitung und Installation (Doku Beschaffung und Inbetriebnahme) immer der größte Aufwand. Die Algo zwischen In und Out ist meist schnell erledigt.
Jens M. schrieb: > Mark B. schrieb: >> Übrigens kann man auch eine Maschinensteuerung weitgehend >> hardwareunabhängig programmieren. Dem eigentlichen Algorithmus ist es >> völlig Wumpe, ob er auf einem µC, einem PC oder sonstwo läuft. Also kann >> man den absolut problemlos auch auf einem PC entwicklen und testen. > > Wie machst du das dann mit I/O? Das ist logischerweise der Teil, der hardwareabhängig ist. Auf dem PC kann man sich beliebige Eingangsdaten selbst vorgeben und somit die Unit-Tests prima dort erledigen. Ohne ständig flashen zu müssen.
Stefanus F. schrieb: > Vorschlag: Dokumentiere die Hardware detailliert, und was die Software > tun soll. Da du das Programm geschrieben hast, bist du der Beste Mann > dafür. Dann zeigst du und die Doku und wir schauen nochmal drüber. Darauf hin hast du geantwortet: D a v i d K. schrieb: > Mir fehlt der Einstieg, um die Routinen ordentlich zu testen! Kein Wunder, ohne Doku kann niemand ordentlich testen. Die wäre nämlich für den Einstieg notwendig. Natürlich kannst du auch jemanden dafür bezahlen, die Doku mit Reverse-Engineering Methoden zu erstellen. Aber dann wirst du wohl noch eine Null an den Preis anhängen müssen.
Mark B. schrieb: > Jens M. schrieb: >> Mark B. schrieb: >>> Übrigens kann man auch eine Maschinensteuerung weitgehend >>> hardwareunabhängig programmieren. Dem eigentlichen Algorithmus ist es >>> völlig Wumpe, ob er auf einem µC, einem PC oder sonstwo läuft. Also kann >>> man den absolut problemlos auch auf einem PC entwicklen und testen. >> >> Wie machst du das dann mit I/O? > > Das ist logischerweise der Teil, der hardwareabhängig ist. > > Auf dem PC kann man sich beliebige Eingangsdaten selbst vorgeben und > somit die Unit-Tests prima dort erledigen. Ohne ständig flashen zu > müssen. Eine Logo kannst du auch komplett am PC simulieren. Aber meist sieht die Praxis dann anders aus weil du die Werte nicht hast, nicht bekommst, keiner Sie vernünftig beschreibt etc.. In all den Jahren hab ich noch nie eine anständige Beschreibung gehabt, egal ob KMU oder global Player. Ne SPS wird heutzutage übers Netz geproggt, egal ob Sie auf dem Schreibtisch liegt oder in Botswana hängt. Das können die Bastellösungen alle nicht leisten, die scheitern meist schon an vernünftigen Schraubklemmen.
Jens M. schrieb: > Ne SPS wird heutzutage übers Netz geproggt, egal ob Sie auf dem > Schreibtisch liegt oder in Botswana hängt. Das können die Bastellösungen > alle nicht leisten, die scheitern meist schon an vernünftigen > Schraubklemmen. Das ist ja mal eine GANZ hervorragende Idee: Sicherheitskritische Steueranlagen, an die man übers Internet rankommt... :-)
Mark B. schrieb: > Das ist ja mal eine GANZ hervorragende Idee: > Sicherheitskritische Steueranlagen, an die man übers Internet > rankommt... :-) Die Problematik ist bekannt.
Mark B. schrieb: > Das ist ja mal eine GANZ hervorragende Idee > Sicherheitskritische Steueranlagen, an die man übers Internet > rankommt... :-) Immer noch besser, als zahlreiche ESP8266 mit kommerzieller Cloud zu betreiben. Ich denke, ihr wisst wessen Produkte ich meine.
> Erst Leistungsumfang, dann Angebot. Den Preis vorher festzuzurren > ist Glatteis. In der Regel werden beide nicht glücklich damit. Gebe ich Dir bei großen Projekten uneingeschränkt recht, aber so groß ist dieses Projekt hier nicht. Und bei solchen kleinen Dingen kann man auch viel direkt auf dem µC probieren. Ich denke ich schaffe da große Abschnitte auch ohne Flashen und Testen zu programmieren.
Übrigens fehlt die grundlegendste Information: Wo (in welcher Region) denn die zu steuernde Anlage steht. Bei dem Budget wird wohl keiner Hunderte von Kilometern weit fahren wollen, um die Software vor Ort in Betrieb zu nehmen und zu testen.
:
Bearbeitet durch User
Ben B. schrieb: > Gebe ich Dir bei großen Projekten uneingeschränkt recht, aber so groß > ist dieses Projekt hier nicht. Woher willst du das wissen. Der TE hat wohl eher wenig Plan. Wenn es um Geld geht hört die Freundschaft meist auf. Es kann sein das alles gut geht, bei solch schwammigen "Projekten" ist das aber eher unwahrscheinlich. Von der Verhandlungsposition her bist du dann auch noch auf der Looserseite. Der Preis steht fest, aber der Lieferumfang nicht. Das ist selbst bei gutem Willen aller Beteiligten eine schlechte Basis.
Mark B. schrieb: > Übrigens fehlt die grundlegendste Information: Wo (in welcher Region) > denn die zu steuernde Anlage steht. Bei dem Budget wird wohl keiner > Hunderte von Kilometern weit fahren wollen, um die Software vor Ort in > Betrieb zu nehmen und zu testen. Das ist doch egal. Reisekosten und Reisetage werden doch sicherlich fair vergütet.
> Woher willst du das wissen. Der TE hat wohl eher wenig Plan.
Zwei Temperatursensoren und drei Relais löte ich nachts besoffen um halb
drei an einen ATMega wenns sein muß.
Das einzige was daran anspruchsvoll ist, ist das Display und "ein paar
Tasten". Wenn man damit eine komplette Benutzerführung bauen soll, dann
kostet das Zeit. Aber die Grundfunktionen sind schnell erledigt.
Also, ich würds wohl machen, wenn Du in der Nähe bist. Für das Geld mit Dir zusammen. Heisst so etwa 3-4 Tage ein paar Stunden: 1.Tag: Du stellst das Projekt vor, wir gehen die Dinge durch, Codereview 2.Tag: Ich zeige Informationen und Alternativen zu den Kernbaustellen 3.Tag: Wir begutachten den von Dir refaktorierten und geänderten Code 4.Tag: Resümee, Betrachtungen und Rückfragen zu einzelnen Gebieten, damit Du die Dokumentation machen kannst. --> Prinzipiell kannst Du das auch hier online umsonst machen.
Jens M. schrieb: > Reisekosten und Reisetage werden doch sicherlich fair vergütet. Wohl kaum, wenn für die eigentliche Arbeit schon so wenig Budget verfügbar ist.
Ben B. schrieb: > Ich denke aber, für diese Aufgabe wirst Du einen Spezi brauchen, der > sich mit diesem Clion-Wasauchimmerdasist so gut auskennt, Clion ist bloß ein Editor / IDE.
A. S. schrieb: > Prinzipiell kannst Du das auch hier online umsonst machen. Also als selbsternannter µC Net Consulter empfehle ich einen Logo Starterkit. Da ist alles drin (inkl Schraubendreher) und nen geilen Festo clone Koffer gibt's obendrauf. Den gibt es bei Voelkner, Conrad, Reichelt, RS, Bürklin, dem örtlichen Elektrogroßhandel oder ..... . Das bisschen Klötzchengeschiebe (aka Funktionsbausteine) in der Software hat man nach ein paar Stunden drauf. Notfalls macht ihm das jeder Mechatronik Azubi II Lehrjahr von der örtlichen Berufsschule (ohne Reisekosten ;-) ). Alternativ auch was von KlöMö, Beckhoff, Legrand, Mitsubishi ... Für Voelkner hätte ich sogar noch einen 5 Euro Gutschein. Als Schmerzensgeld für den TE das er meine Ergüsse lesen muss. Wer allerdings lieber die Abgründe der I2C programmierung erforschen will soll das tun. Würde ich dann aber auch entsprechend formulieren.
Ich kann definitiv nicht empfehlen angefangene Projekte, die zu 95% fertig sind, quasi laufen, es braucht nur noch Wenig.., anzufassen Denn Derwelche, der's angefangen aber nicht beendet hat, hattte Gruende. - Das Konzept war falsch - er war ueberfordert - er kam mit den Kosten nicht hin - es geht so genau nicht - eigentlich sollte man's neu machen Ein Neubau kann 4 mal so teuer wie die erste Schaetzung. Ich wuerde obiges Projekt mit 10kEuro schaetzen.
Wenn mir jemand für dieses Projekt 10k Euro bezahlt, würde ich sofort eine Firma dafür eröffnen!! Naja egal, ich halte mich jetzt aus diesem Thread hier raus. Jedenfalls versuche ich das. Falls der TE nochmal wiederkommt und was von mir möchte (wobei ich das nicht glaube), soll er 'ne PN schreiben.
Zitronen F. schrieb: > Ich wuerde obiges Projekt mit 10kEuro schaetzen. Das ist doch unseriös. Woher weißt Du was die genauen Anforderungen sind? Woher weißt Du, wie gut die Anforderungen definiert sind und wie lange Du brauchst um die zusammen mit dem Auftraggeber in einen brauchbaren Zustand zu bekommen? Woher weißt Du wie der Code jetzt aussieht und wie umfangreich er ist? In 12KB Binary kann einiges drin stecken. Woher weißt Du wie umfangreich die vom Auftraggeber gewünschten Unit-Tests sind? Selbst wenn Du es komplett neu entwickeln willst, brauchst Du diese Infos um ein seriöses Angebot abgeben zu können.
Jens M. schrieb: > Einfache Software schreibt man da in einer Stunde. Mach mal - und berichte :-) mit den 100 € für die Hardware liegt das ja voll im Budget ....
Dieter F. schrieb: > Mach mal - und berichte :-) Einen Treppenhausautomaten mit Auftauautomatik "schreib" ich dir in 10 Minuten ;-). Einfache Sachen gehen verdammt schnell weil die Dinger dafür optimiert sind. Was schlecht geht ist klassische Datenverarbeitung. Du kannst auch über das Netz eine Excel List live mit Daten füllen und ein SD Kartenlogger ist auch nur ein Funktionsbaustein. Das geht auf Variablenebene (z.B Temperatur mit Min- und Maxwert, meinetwegen auch ein PID dazu) wunderbar und reicht auch oft. Darüber hinaus wird es aber aufwendig bis unmöglich.
@Dieter Eine Logo wird wohl mehr als 100 EUR kosten. @TO Alleine wegen deine Anforderung(-en) wie zB "3 x 230V" würde ich aber auch auf eine SPS zurückgreifen.
Ich versuche noch mal einiges zu beantworten. Wobei das Kind wohl bereits in den Brunnen gefallen ist, weil ich im Eröffnungsbeitrag zu viel Infos gegeben habe, über die man streiten kann: Julian W. schrieb: > Wenn du mit C und Mikrocontroller nicht gut klar kommst, wäre vielleicht > jetzt auch der Zeitpunkt auf ein anderes System zu wechseln, egal ob was Sicherlich korrekt, aber der Kunde will/muss bei diesem alten Zeug bleiben. Es war schon ein Krampf als ich versehentlich eine Batteriehalterung für gängigere Knopfzellen verbaut habe. Julian W. schrieb: > Wenn es besser ist den Code komplett neu zu schreiben oder die Hardware > (teilweise) umzustellen weil > - günstiger > - besser zu warten > - für alle stressfreier Also es geht hier nicht drum, was für mich das beste wäre, sonder wie ich abliefern kann. Von der Hardware habe ich hier noch 20 Sätze liegen und es wäre kein Problem helfenden Kräften welche zuzusenden. Eagle Bild-Exporte lasse ich gerne per Mail zukommen (die möchte ich hier nicht öffentlich posten. Es ist jedoch eine extrem einfache Schaltung) A. S. schrieb: > Also, ich würds wohl machen, wenn Du in der Nähe bist. Danke! einer der wenigen Posts, die mir Hoffnung macht. Bremen (und Umzu, ich würde auch ca. einige km zu dir raus fahren) > 1.Tag: Du stellst das Projekt vor, wir gehen die Dinge durch, Codereview Vielleicht kann man auch einen ersten Eindruck per Telefon oder ScreenSharing vermitteln? > 2.Tag: Ich zeige Informationen und Alternativen zu den Kernbaustellen > 3.Tag: Wir begutachten den von Dir refaktorierten und geänderten Code > 4.Tag: Resümee, Betrachtungen und Rückfragen zu einzelnen Gebieten, > damit Du die Dokumentation machen kannst. zwischen Tag2 & Tag3 bräuchte ich entsprechend viel Zeit. Ben B. schrieb: > Das einzige was daran anspruchsvoll ist, ist das Display und "ein paar > Tasten". Wenn man damit eine komplette Benutzerführung bauen soll, dann > kostet das Zeit. Aber die Grundfunktionen sind schnell erledigt. Daher möchte ich noch mal auf meine 95% zu sprechen kommen. Hätte ich 99,9% geschrieben, hätten mich wohl noch mehr hier ausgelacht. Aber was Display und Taster angeht ist alles fertig. Letzendlich gibt es Menueebene "Config" & "Run". Der µC startet in Run durch und läuft seine Temperaturregelung an. Alles was in "Config" passiert braucht nicht betrachtet werden. "Run" und dessen Fehlerhandling sind maßgeblich. Jens M. schrieb: > Von der Verhandlungsposition her bist du dann auch noch auf der > Looserseite. Der Preis steht fest, aber der Lieferumfang nicht. Das kann man doch alles anständig besprechen und festhalten! Ich wollte mit der Spanne lediglich andeuten, dass ich hier keinen Großauftrag vergeben kann. Und sicherlich ist mir auch nicht damit geholfen, wenn sich irgendein Student mit einem Wissensstand ähnlich dem meinigen meldet, um sich ein Taschengeld einzustreichen ohne merklich etwas beizusteuern. Ich wenden mich auch NUR hier an dieses Forum, weil ich vielleicht dem einen oder anderen aus anderen Threads bekannt bin, wo ich bereits seit 4 Jahren quasi zum Nulltarif meine Dienste anbiete. Und weil ich das gerne mache hoffe ich halt kollegiale Hilfe, die selbstverständlich fair entlohnt werden soll. Grüße David
D a v i d K. schrieb: > zu viel Infos gegeben habe... D a v i d K. schrieb: > aber der Kunde will... D a v i d K. schrieb: > sonder wie ich abliefern kann... D a v i d K. schrieb: > dass ich hier keinen Großauftrag vergeben kann... D a v i d K. schrieb: > wo ich bereits seit 4 Jahren quasi zum > Nulltarif meine Dienste anbiete... Mit Ehrlichkeit kommst du weiter ;) D a v i d K. schrieb: > Von der Hardware habe ich hier noch 20 Sätze liegen ? Was hast du nochmal schnell gelernt? D a v i d K. schrieb: > Eagle Bild-Exporte lasse ich gerne per Mail zukommen > die möchte ich hier nicht öffentlich posten. Wenn du schon seit 4 Jahren dran bist, mache es mindestens richtig. Es wird sich sicher jemand finden, der dir gratis hilft.
Jens M. schrieb: > Mark B. schrieb: >> Das ist ja mal eine GANZ hervorragende Idee: >> Sicherheitskritische Steueranlagen, an die man übers Internet >> rankommt... :-) > > Die Problematik ist bekannt. Und wie löst man sie? Meiner Meinung nach gehören SPSen und generell technische Anlagen nicht ans Netz. Allenfalls an ein abgeschirmtes Intranet, an das kein Außenstehender so ohne Weiteres drankommt.
Mark B. schrieb: > Meiner Meinung nach gehören SPSen und generell technische Anlagen nicht > ans Netz. Allenfalls an ein abgeschirmtes Intranet, an das kein > Außenstehender so ohne Weiteres drankommt. Und wo jemand zur Fernwartung einen Schalter umlegen oder ein Kabel stecken muss. Bloss nichts, was wiederum von außen unbemerkt fernsteuerbar oder hackbar ist.
D a v i d K. schrieb: > A. S. schrieb: >> Also, ich würds wohl machen, wenn Du in der Nähe bist. > Danke! einer der wenigen Posts, die mir Hoffnung macht. > Bremen (und Umzu, ich würde auch ca. einige km zu dir raus fahren) Die Info hätte wie gesagt schon ins Eröffnungsposting reingehört. Für jemanden aus Süddeutschland macht so ein Projekt bei dem angedachten Budget wohl eher wenig Sinn. Jedenfalls kommen von Dir sinnvolle Infos, ich hoffe für Dich und wünsche Dir dass Du jemand geeigneten in Deiner Umgebung findest.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.