INFO: Dieses Forum nutzt Cookies...
Cookies sind für den Betrieb des Forums unverzichtbar. Mit der Nutzung des Forums erklärst Du dich damit einverstanden, dass wir Cookies verwenden.

Es wird in jedem Fall ein Cookie gesetzt um diesen Hinweis nicht mehr zu erhalten. Desweiteren setzen wir Google Adsense und Google Analytics ein.

Antwort schreiben 
 
Themabewertung:
  • 0 Bewertungen - 0 im Durchschnitt
  • 1
  • 2
  • 3
  • 4
  • 5
Kompressor
05.08.2017, 13:13
Beitrag #1
Kompressor
Hallo Arduinos,

das geht hier vermutlich etwas länger...

Die PDF für das Kick off stelle ich hier noch einmal ein.

Gruß
Rainer

Prozessfließbild

Damit jeder verstehen kann was was ist, muß das Bild lesbarer sein. Ein Hilfsmittel dazu ist eine Liste die technologische Namen, Klartextbezeichnungen, Variablen- Name und Typ enthält. Später kommen noch zusätzliche Spalten mit wichtigen Informationen dazu. Hier mal Beispiele was gemeint ist...

Code:
Technologischer Name: V3.1
Beschreibender Text:    Bypass-Ventil 1.Stufe
Variablen-Name:          AA1[0] (Analog Ausgang)
Variablen-Typ:             int

Technologischer Name: V3.2
Beschreibender Text:    Bypass-Ventil 2.Stufe
Variablen-Name:          AA1[1] (Analog Ausgang)
Variablen-Typ:             int

So eine Liste werde ich mal Vorbereiten
Rainer


Angehängte Datei(en)
.pdf  Kickoff Kompressor.pdf (Größe: 222,44 KB / Downloads: 279)
Diese Nachricht in einer Antwort zitieren
05.08.2017, 13:38
Beitrag #2
RE: Kompressor
Hallo Rainer,
dein Projekt sieht nach richtig viel Arbeit aus. Big Grin

Deine Vorgaben als pdf sind schon recht ausführlich und eine solide Basis, allerdings dennoch an manchen Stellen lückenhaft. Aber das ist wohl auch so beabsichtigt um erst mal einen Überblick zu erhalten.

Ich habe in der Vergangenheit schon öfter Kompressoren in der Leistungsklasse ab 100kW automatisiert. Jedoch nie mit einem Arduino sondern immer mit "ausgewachsenen Leitsystemen". Deshalb könnte ich vielleicht auch hier etwas beitragen.

Erst mal eine Frage:
Ist dein Kompressor real existent oder ist es nur ein Demoprojekt?

Gruß
Arne

Gruß Arne
Mit zunehmender Anzahl qualifizierter Informationen bei einer Fragestellung, erhöht sich zwangsläufig die Gefahr auf eine zielführende Antwort.
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren
05.08.2017, 13:48
Beitrag #3
RE: Kompressor
Hallo Ardu Arne,

rein fiktiv, kein komerzieller Hintergrund, wenn Du das auch schon gemacht hast, weißt Du auch wie schwer es manchmal ist gestandenen Ingenieuren ein Konzept vorzustellen. Das hat mich während meiner aktiven Zeit immer etwas geärgert. Heute bin ich im Ruhestand- weit weg von Ärgern und möchte nur mal ein Modell eines Kompressor realisieren. Das ist auch gar nicht so schwer wie es auf dem ersten Blick aussieht. Es ist vielmehr eine Frage des Aufwandes. Viel Arbeit, viel Gespräche und sehr interessant weil für alle was dabei ist. Du bist mit deiner Hilfe sehr wilkommen.

Gruß
Rainer
Diese Nachricht in einer Antwort zitieren
05.08.2017, 14:06
Beitrag #4
RE: Kompressor
Ok, also fiktiv.

Wie weit soll das gehen?
Willst du für die Steuerung echte Hardware (Arduino) aufbauen und darin die auf Seite 1 gezeichnete Produktionsanlage simulieren oder soll die Produktionsanlage ein zweiter Arduino sein der den Prozess simuliert und alle Zustände so richtig per Draht an die Steuerung vorgibt.

Und ja, die Vorstellungen von Ingenieuren kenne ich allzu gut. Da kann man sich in stundenlangen Sitzungen mit so einem Thema beschäftigen um am Ende mit mehr Fragen als Antworten da zu stehen.

Ob ich wirklich helfen kann wird sich zeigen. Ich hätte meinerseits schon eine relativ konkrete Vorstellung wie ich an die Sache heran gehen würde. Ob die sich aber mit deiner Idee deckt?
Das könnte wieder so eine stundenlange Fachsimpelei über das Konzept werden. Big Grin

Gruß
Arne

Gruß Arne
Mit zunehmender Anzahl qualifizierter Informationen bei einer Fragestellung, erhöht sich zwangsläufig die Gefahr auf eine zielführende Antwort.
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren
05.08.2017, 14:18
Beitrag #5
RE: Kompressor
Hallo Arne,

Uno1 soll den Kompressor abbilden, Produktionsanlage ist wie Brömmel sagt ne jrosse schwatte Kist, Uno2 macht das Leitsystem und Motorsteuerung, Uno3 verwaltet und schiebt Werte.
Deine Vorstellungen interessieren mich sehr. Meine Ideen sind nicht der Weisheit letzter Schluss. Und der Sinn dieses Projektes liegt genau in diesem Austausch von Gedanken, Ideen und Lösungen. Hier sind wir frei von Zwängen. Profilierungsneurosen gibt es im Forum nicht.

Gruß
Rainer

zwischen Kompressor und Leitsystem DRÄHTE.
Diese Nachricht in einer Antwort zitieren
05.08.2017, 14:56
Beitrag #6
RE: Kompressor
(05.08.2017 14:06)ardu_arne schrieb:  Ob ich wirklich helfen kann wird sich zeigen. Ich hätte meinerseits schon eine relativ konkrete Vorstellung wie ich an die Sache heran gehen würde. Ob die sich aber mit deiner Idee deckt?
Das könnte wieder so eine stundenlange Fachsimpelei über das Konzept werden. Big Grin
Ich glaube jede Konzepterarbeitung wird eine längere Fachsimpelei.

Ich habe das oft genug erlebt, dass bei der Idee / Fachplanung ziemlich gut der "Hinweg" also das, was sie programmiert haben wollten (Bedingungen --> Aktion) durchdacht war, der "Rückweg" (Bedingung fällt weg) aber überhaupt nicht. Das war dann oft mein Part, den Fachingenieuren klar zu machen, dass das auch von ihnen geliefert werden muß, bevor man die Programmierung planen kann.

Gruß Tommy

"Wer den schnellen Erfolg sucht, sollte nicht programmieren, sondern Holz hacken." (Quelle unbekannt)
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren
05.08.2017, 15:38
Beitrag #7
RE: Kompressor
Meine relativ klaren Vorstelleingen muss ich etwas einschränken denn die beziehen sich derzeit nur auf UNO2. Dies soll aber nicht bedeuten dass ich zu UNO1 und 3 nichts zu sagen hätte und mir deren Aufgaben unbekannt wären.

Ich kenne es so dass man zwischen der Schaltanlage für die Aktoren und der Steuerung (UNO2) einen standardisierten (Hardware) Signalaustausch hat der für mehr als 90% aller Antriebe (Aktoren) passt.
Es gibt dort einen Standarttyp für Geradeausantriebe, für Klappenantriebe und für Magnetventile.

Bei Geradeausantrieben gibt es i.d.R. nur Rückmeldungen aus der Schaltanlage (Ein, Aus, Störung, ...).
Bei Klappenantrieben kommt aus der Schaltanlage oft nur ein Störsignal und dazu dann die echte Klappenstellung (Auf/Zu) aus der Produktionsanlage.
Bei Magnetventilen ist es möglich die Rückmeldung (Auf/Zu) aus der Schaltanlage zu gewinnen oder über echte Endschalter am Ventil.
Soweit der Standard wie ich ihn kenne und der gut 90% aller Fälle abdeckt. Darüber hinaus kann man viele Sondervarianten kreieren, z.B. eine zusätzliche analoge Stellungsmeldung von Klappen (0...100%).

Meine konkrete Vorstellung zu UNO2 würde folgendermaßen aussehen.
Ich würde mir für Typ der verwendeten Aktoren eine standard Sofware Funktion für UNO2 schreiben die in den Aufrufparametern die auszuführende Funktion entgegen nimmt und als Rückgabewert den realen aktuellen Zustand des Aktors liefert.
Richtig realitätsnah wird es dann wenn man in den Aufrufparametern noch eine zulässige Gesamtlaufzeit übergeben kann in der der Aktor den gewünschten Zielzustand erreichen muss. Wird diese Zeit überschritten soll eine entsprechende Meldung an UNO3 erfolgen und dieser leitet sie weiter an die Visualisierung.

Diese standard Sofware Funktionen stellen dann im UNO2 die unterste Ebene dar die stupide nur die Aktoren bespasst und überwacht.

Über dieser Ebene käme dann eine Schrittkette (Ablaufsteuerung) mit Ein- und Ausstrang zum Einsatz.

Vom BuB (Bedien und Beobachtunssystem, bei dir Bedienung und Visualisierung) sollte man dann rückwärts über den Weg PC-Netzwerk --> UNO3 --> I2C auf die untergeordneten Steuerungsfunktionen für die Aktoren und die Schrittkette Einfluss nehmen können.

In wie weit würde sich das mit deinen Ideen decken?

Was Tommy schreibt ist natürlich auch harte Realität und die gilt es zu berücksichtigen. Dazu muss man aber schon tiefer in die Details einsteigen und für alle möglichen Fehler eine entsprechende Fehlerbehandlung in die Steuerungssoftware einbauen.

Gruß
Arne

Gruß Arne
Mit zunehmender Anzahl qualifizierter Informationen bei einer Fragestellung, erhöht sich zwangsläufig die Gefahr auf eine zielführende Antwort.
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren
05.08.2017, 16:13
Beitrag #8
RE: Kompressor
Hallo Tommy, Hallo Arne,

wie Tommy sagt, der Rückweg wird sich gern gespart. Aber nicht nur von den Planern, sondern auch von den Kaufleuten. Ist ja weniger geworden- kostet dann auch weniger.
Ich habe beide Seiten bedient, so aber niemals argumentiert.

Ja, Arne, neben der Bestandsaufnahme was denn so an Sensoren und Aktoren im Kompressor verbaut ist (dargestellt in der Liste die ich angekündigt habe) sind die sogenannten Typicals als Standard zu definieren. Und genau wie Du ebenfalls sagtes, gibt es bewährte Prinzipien dazu. Diese Standards werden dokumentiert und damit wird für jeden die Aufgabe klar. Das wird auch der nächste Schritt sein, da bin ich mit Dir völlig konform. Die Typicals können wir beide entwerfen und diskutieren wenn Du willst.

Gruß
Rainer

Hallo Tommy,

wenn ich zur Inbetriebnahme vorgesehen war, habe ich die Rückwege oft beim Systemcheck und beim Loopcheck selbst programmiert. Da bekommst Du nämlich nicht den Programmierer der das gemacht hat, sondern einen Inder geschickt der sehr lange braucht um zu verstehen wie die Anlage tickt. Wenn überhaupt.

Gruß
Rainer
Diese Nachricht in einer Antwort zitieren
Antwort schreiben 


Gehe zu:


Benutzer, die gerade dieses Thema anschauen: 1 Gast/Gäste