Opensource Lichtsteuerung PC_DIMMER2008

[christian.noeding]

PC_DIMMER2012 - Das Opensource Lichtprogramm


Im Folgenden möchte ich den vor einiger Zeit begonnenen Post zu meinem Opensource-Projekt "PC_DIMMER" aktualisieren, damit in der DP nicht veraltete Informationen herumgeistern :) Das Projekt ist besonders in den letzten Monaten stark ausgebaut worden, sodass man vom programmiertechnischen einiges Interessantes finden kann. Zudem kann man im Sourcecode von mir etliche Anregungen für eigene Problemlösungen finden.

Der PC_DIMMER2012 ist ein von mir entwickeltes Opensource-Lichtprogramm, mit dem man inzwischen jedes Bühnengerät steuern kann, was der Markt so hergibt. Darunter zählen Bewegtscheinwerfer (Scanner, MovingHeads, etc.), LED-Pars, Stroboskope und vieles mehr.


Hier einmal Stichpunktartig die Funktionen:

- Steuerung von bis zu 8192 Kanälen (16 DMX Universes)
- Unterstützung für DMX512-Sender (über Ausgabeplugins erweiterbar)
- Programmfunktionen über Plugins erweiterbar
- Gerätebasierte Oberfläche. Über eine Skriptsprache können für jedes Gerät eigene Oberflächen in das Programm integriert werden, sodass man gezielt die Gerätefunktionen verwenden kann
- Ein Audioeffektplayer erlaubt das zeitgenaue abspielen einer Lichtshow zu einer Audiodatei ähnlich einem Videoschnittprogramm
- Eine umfassende Befehlssteuerung erlaubt das Steuern von Programmfunktionen aus allen Bereichen der Anwendung
- Eine grafische Bühnenansicht erlaubt das schnelle Einstellen von Bühnenparametern
- Über geometrische Kompensationsverfahren werden Bewegungen von zur Bühne verdrehten Bewegtscheinwerfern kompensiert
- MIDI-, Joystick- und andere Steuerungen werden unterstützt
- Webserver zur Steuerung der wichtigsten Funktionen über das Internet (Szenen, Kontrollpanel, Geräteübersicht, etc.) - für Architekturbeleuchtung sehr interessant


Weitere Informationen findet man unter http://www.pcdimmer.de


Vielen Dank auch an die diversen Leute, die mir hier in der DP mit Rat und Tat geholfen haben - besonders an die vielen anderen Opensource- und Teilquellcode-Schreiber, ohne die mein Projekt nie den heutigen stand erreicht hätte.



PS: die nachfolgenden Posts beziehen sich zum Teil auf die ersten Programmversionen. Inzwischen ist der Sourcecode entsprechend angepasst und modernisiert worden. :zwinker:

[Robert Marquardt]

Wie waere es mal mit einer kraeftigen Vereinfachung des Codes?

Delphi-Quellcode:

var
  List: array [1..128] of TStringList;

und eine entsprechende Umstellung auf Schleifen und Index.
Dieses List1 bis List128 ist ja ein grauenvoll ineffizientes Codegrab.

[christian.noeding]

Hey, ich habe im Dezember erst mit Delphi angefangen - bin froh, dass ich das Programm soweit zum Laufen bekommen habe ;)


Für konstruktive Vorschläge bin ich mehr als offen und dankbar :)
Besonders bei meiner Zuweisung der Namen von Buttons, Funktionen, Prozeduren usw. werden sich einigen die Fußnägel hochrollen - aber mittlerweile bin ich schon etwas mehr dahinter gekommen, gleich beim Programmieren den Sourcecode aufzuräumen... bisher bin ich aber zeitlich nicht dazu gekommen, die komplette Source zu bereinigen. Werde das wohl als nächstes mal in Angriff nehmen, da mir die Ideen für Zusätze für das Programm ausgegangen sind und das Programm soweit so gut läuft :)

bis denn,
Christian :)

[christian.noeding]

Ich habe mal die gigantischen "List"-Methoden durch Einzeiler ersetzt. Die Software ist prompt knapp 1500 Zeilen geschrumpft und die Schleifen laufen jetzt viel schneller ab...

Danke für den Tipp, ich habe irgendwie nicht dran gedacht, dass man das alles viel schneller per Array erledigen kann :)


bis denn,
Christian

[franktron]

Sagmal du hast da 2 Ver. einmal Deu und einmal ENU.

Warum hast du das alles Doppelt scuh mal im Form nach Mehrsprachigen Anwendungen da gibst echt gute Tips das würde wohl den Verwaltungsaufwand stark verrigern

[Robert Marquardt]

Kann man die .dcu und .ddp Files aus dem naechsten Download entfernen? Ich habe heute 4.5KByte/Sec von SourceForge bekommen.

Kommen wir zur naechsten Vereinfachung.
Delphi kann keine Arrays von Komponenten in der IDE.
Die Loesung ist es selber zu machen.

Beispiel:

Delphi-Quellcode:

public
  Scrollbars: array [1..8] of TScrollBar;

Im FormCreate:

Delphi-Quellcode:

  // die zusammengehoerigen Komponenten finden und ins Array eintragen
  for I := Low(Scrollbars) to High(Scrollbars) do
    Scrollbars[I] := FindComponent(Format('ch%d', [I]));
  
  // abklappern und initialisieren
  // je nach Zweck sollte dies in eine Methode gepackt werden
  for I := Low(Scrollbars) to High(Scrollbars) do
    Scrollbars[I].Max := maxres;

Nach dem obigen Prinzip kann man bestimmt noch ein paar Tausend Zeilen wegbekommen und gewinnt gleichzeitig Strukturen.


Alles in allem gefaellt mir die MainForm. Sie ist einfach und klar strukturiert.
Es gibt noch ein paar Nickligkeiten, die man beseitigen sollte.
Konsequenter deutsch schreiben. z. B. "Serielle Schnittstelle"
Einheitliche Begriffe. Immer "Script" oder "Skript", nicht gemischt. Ich empfehle "Skript", aber "Level" sollte englisch bleiben.
Die Feinheiten des GUI-Designs beachten. Es sollte z. B. "COM x..." heissen, da zur Durchfuehrung der Aktion des Menuepunktes eine Benutzereingabe notwendig ist (Dialog).
Ebenfalls sollten alle Menuepunkte ein Tastenkuerzel haben. Das "Szene löschen" kein Kuerzel hat, aber "Alle Szenen löschen" doch, ist inkonsequent.

[Robert Marquardt]

Ich empfehle auch noch die "User Interface Hall of Shame" zu lesen (archiviert hier: http://web.archive.org/web/200211050....com/shame.htm ).
Es ist ist lehrsam, auch wenn es so freundlich wie ein Schlag in die Fresse ist.

[franktron]

Zitat:

Zitat von Robert Marquardt

Ich empfehle auch noch die "User Interface Hall of Shame" zu lesen (archiviert hier: http://web.archive.org/web/200211050....com/shame.htm).
Es ist ist lehrsam, auch wenn es so freundlich wie ein Schlag in die Fresse ist.

Der Link funktioniert nicht so richtig da kommt nur Werbung.

[Robert Marquardt]

Korrigiert und getestet.

[christian.noeding]

Hallo Leute,


besten Dank für Lob, Kritik und Ideen. Werde mich dransetzen und die Vorschläge soweit wie möglich umsetzen.


Wenn man Sachen wie mit den Scrollbar-Arrays weiß, fragt man sich natürlich, warum man das nicht schon vorher gemacht hat ;)



Für weitere Vorschläge und Ideen bin ich offen und werde sie dankend annehmen :)


@franktron: nachdem ich bereits wenige Zeit nach Veröffentlichung Rückmeldungen aus Kanada und Australien bekommen habe (über das DiscoLitez-Forum auf www.discolitez.com) habe ich so schnell wie möglich das ganze Programm einfach übersetzt und die Erstbeste Methode genommen. Seitdem sah ich keinen Grund, nach was anderem zu suchen, obwohl ich schon so manches Problem mit dem Delphi-Internen Übersetungstool hatte. Werde aber mal in der nächsten Zeit nach Alternativen oder Optimierungen suchen :)

@Robert Marquardt: die .dcu und .ddp Files fliegen in der nächsten Source-Zip raus - sorry ;). Werde auch die Strings nocheinmal überarbeiten. Gibt's eigentlich ne Möglichkeit, ohne großen Aufwand konkrete Strings, die nicht in der IDE angezeigt werden mit dem Resource-Tool von Delphi zu übersetzen? Da habe ich nämlich so manchen Text, den ich nur auf Deutsch habe... Wahrscheinlich werde ich nochmla gründlicher suchen (siehe @franktron)




Bis denn,
Christian :D

[christian.noeding]

Hi,

soeben lade ich den neuen Sourcecode auf Sourceforge.net. Ich habe etliche hundert Code-Zeilen eliminieren können und einige Funktionen laufen jetzt auch flotter ab. Zudem ist die größe der Exe von 1,53 auf 1,43 MB geschrumpft - schon mal sehr angenehm.

Ich habe die Vereinfachungen allerdings nicht über Arrays umgesetzt, sondern habe im Code nur "FindComponent" Deklarationen mit Schleifen genutzt, da ich zwar die Komponenten in Arrays packen und damit auch die ganzen Funktionen laufen lassen konnte, mir aber die Komponenten auf der MainForm nicht aktualisiert wurden. Wenn ich dann eine Zuweisung der MainForm-Komponenten zu den Array-Komponenten machen wollte, gabs immer Fehlermeldungen aufgrund Inkompatibilität!? Ich hätte das jetzt umgehen können, indem ich eine Zusatzfunktion zum Aktualisieren der Oberfläche,wie z.B.

Delphi-Quellcode:

for i:=1 to 8 do
TScrollBar(FindComponent('ch'+inttostr(i))).position:=scrollbars[i].position;
// ch1..ch8 sind die Fader und scrollbars[1..8] sind dann die Komponenten-Arrays ;)

aber schon wieder ne Aktualisierungsfunktion einbauen, wollte ich dann auch nicht.

Jetzt bleiben halt die etlichen Zeilen bestehen, die zum Initialisieren der Komponenten notwendig sind - schön ist aber, dass die riesigen Zeilenblöcke durch einzeilige For-Schleifen ersetzt werden konnten :D


Danke nochmals, für die Tipps...

bis denn,
Christian

[DGL-luke]

ohne irgendwie OT werden zu wollen, ein ausschnitt aus einem projekt von mir:

Delphi-Quellcode:

//globale vars:
var
  Form1: TForm1;
  labels:array[0..255] of TLabel;
  bars:  array[0..255] of TRBProgressbar;
//formcreate:
procedure TForm1.FormCreate(Sender: TObject);
var i:integer;
begin
dragacceptfiles(handle,true); //diese funktion gar nicht anschauen, ist unwichtig
for i:= 0 to 127 do
 begin
  labels[i]               := TLabel.Create(RBPanel1);
  labels[i].Parent        := Panel1;
  labels[i].Left          := 4 + (95*(i mod 4));
  labels[i].Top           := (i div 4)*17 + 8;
  labels[i].Caption       := '#'+format('%.3d',[i])+':'+chr(i);
  labels[i].Tag           := i;
  labels[i].OnDblClick    := bardblclick;
  labels[i].OnClick       := barclick;

  bars[i]                 := TRBProgressbar.Create(RBPanel1);
  bars[i].Parent          := labels[i].Parent;
  bars[i].Left            := labels[i].Left+48;
  bars[i].Top             := labels[i].Top;
  bars[i].Width           := 40;
  bars[i].ShowHint        := true;

  labels[i+128]           := TLabel.Create(RBPanel1);
  labels[i+128].Parent    := Panel2;
  {ganz viel mehr init-kram, genaugenommen der selbe wie oben}

  bars[i+128]             := TRBProgressbar.Create(RBPanel1);
  bars[i+128].Parent      := labels[i+128].Parent;
  {noch mehr init-kram, wieder so wie eins weiter oben}
 end;

panel2.Hide; //unwichtig
panel1.Show; //unwichtig
end;

hilft dir das evtl. bei deinem problem weiter?

wie du siehst, gibt es bei mir keinen unterschied zwischen array-komponenten und "auf der form"-komponenten.
der array wird direkt auf die form gelegt, mit den zuweisungen an left und top werden die kompos einzeln positioniert.

fincomponent kannst du dann endgültig knicken, wenn ich das richtig verstanden habe :-D

(dass ich keine scrollbars sondern labels und progressbars in meinem projekt habe, sollte dich ja nicht weiter stören, hoffe ich!)

[christian.noeding]

Danke für das Code-Beispiel :D das werde ich mir in Ruhe mal anschauen und sehen, ob und wie ich es anwenden kann. Aber ich müsste dann ja komplett mein Design umändern, also von IDE-Aufbau weg zu Form-Aufbau über Code... das scheint mir etwas aufwendig, da ich ja keine dynamischen Erweiterungen meiner Oberfläche geplant habe... andererseits wäre es sicher sinnvoll, alles per Array auf deine Weise zumachen, um so vielleicht z.B. das Andocken zweier Panels zu vereinfachen. Ich müsste dann ja nur zwischen zwei Arraykomponenten die Nähe abfragen und nicht zwischen 20 verschiedenen einzelnen Panels (aber das ist ein anderes Problem)


also nochmals Danke ;)
Gute Nacht,
Christian

[Robert Marquardt]

Kommen wir mal zum schwachen Verstaendnis von booleschen Ausdrucecken.

Delphi-Quellcode:

procedure TMainForm.CheckBox1MouseUp(Sender: TObject; Button: TMouseButton;
  Shift: TShiftState; X, Y: Integer);
begin
  if checkbox1.checked=true then data.manfade[(data.page*8)+1]:=true else data.manfade[(data.page*8)+1]:=false;
  if checkbox2.checked=true then data.manfade[(data.page*8)+2]:=true else data.manfade[(data.page*8)+2]:=false;
  if checkbox3.checked=true then data.manfade[(data.page*8)+3]:=true else data.manfade[(data.page*8)+3]:=false;
  if checkbox4.checked=true then data.manfade[(data.page*8)+4]:=true else data.manfade[(data.page*8)+4]:=false;
  if checkbox5.checked=true then data.manfade[(data.page*8)+5]:=true else data.manfade[(data.page*8)+5]:=false;
  if checkbox6.checked=true then data.manfade[(data.page*8)+6]:=true else data.manfade[(data.page*8)+6]:=false;
  if checkbox7.checked=true then data.manfade[(data.page*8)+7]:=true else data.manfade[(data.page*8)+7]:=false;
  if checkbox8.checked=true then data.manfade[(data.page*8)+8]:=true else data.manfade[(data.page*8)+8]:=false;
end;

Abgesehen das man nicht explizit auf "= true" abfragen muss, geht es natuerlich so viel einfacher:

Delphi-Quellcode:

procedure TMainForm.CheckBox1MouseUp(Sender: TObject; Button: TMouseButton;
  Shift: TShiftState; X, Y: Integer);
begin
  data.manfade[data.page*8+1] := CheckBox1.Checked;
  data.manfade[data.page*8+2] := CheckBox2.Checked;
  data.manfade[data.page*8+3] := CheckBox3.Checked;
  data.manfade[data.page*8+4] := CheckBox4.Checked;
  data.manfade[data.page*8+5] := CheckBox5.Checked;
  data.manfade[data.page*8+6] := CheckBox6.Checked;
  data.manfade[data.page*8+7] := CheckBox7.Checked;
  data.manfade[data.page*8+8] := CheckBox8.Checked;
end;

Die Checkboxen in einem Array wuerden das jetz nochmals deutlich vereinfachen.
Im Uebrigen ist dies ein klassischer Fall von Copy & Paste Code. An einer anderen Stelle habe ich genau die gleichen Zeilen gesehen.
Dies ist auch offensichtlich eine Basisaktion im Code. Es sollte eine eigene Methode geschrieben werden, um die Aktion zu kapseln.

Der naechste Fehler liegt in Zeilen wie dieser:

Delphi-Quellcode:

  device1.Caption:=inttostr(strtoint(device1.Caption)+4);

Hier wird ein Wert in der Caption der Control aufbewahrt. Das ist schlechter Stil, da keine Trennung von Controls und Algorithmus vorliegt.
Besser den Wert getrennt in einer Variablen aufbewahren. Die Funktionsweise des Programms sollte die Eingaben des Benutzers in eine
Zustandsaenderung der Variablen = Eingabewerte umsetzen und dann die Algorithmen aufrufen. Diese aendern den Zustand, der dann auf die
Benutzeroberflaeche zurueckuebertragen wird.

Man koennte zumindest die Tag-Property ausnutzen, aber fuer diese gibt es eine bessere Verwendung. Indem man dort den Index des
Control-Arrays ablegt, kann man mit Ausdruecken der Art "Checkboxes[TCheckbox(Sender).Tag]" allen diesen Checkboxen einen einzigen Handler geben.

Delphi-Quellcode:

procedure TMainForm.CheckBox1MouseUp(Sender: TObject; Button: TMouseButton;
  Shift: TShiftState; X, Y: Integer);
begin
  data.manfade[data.page*8 + Checkboxes[TCheckBox(Sender).Tag] := TCheckBox(Sender).Checked;
end;

Damit wird auch klar das die Uebertragung aller acht Werte Overkill ist.

[Robert Marquardt]

Zitat:

Zitat von christian.noeding

Ich habe die Vereinfachungen allerdings nicht über Arrays umgesetzt, sondern habe im Code nur "FindComponent" Deklarationen mit Schleifen genutzt, da ich zwar die Komponenten in Arrays packen und damit auch die ganzen Funktionen laufen lassen konnte, mir aber die Komponenten auf der MainForm nicht aktualisiert wurden. Wenn ich dann eine Zuweisung der MainForm-Komponenten zu den Array-Komponenten machen wollte, gabs immer Fehlermeldungen aufgrund Inkompatibilität!? Ich hätte das jetzt umgehen können, indem ich eine Zusatzfunktion zum Aktualisieren der Oberfläche,wie z.B.

Delphi-Quellcode:

for i:=1 to 8 do
TScrollBar(FindComponent('ch'+inttostr(i))).position:=scrollbars[i].position;
// ch1..ch8 sind die Fader und scrollbars[1..8] sind dann die Komponenten-Arrays ;)

Hier hast du den Trick nicht ganz verstanden.
Die Komponenten-Arrays sind Aliase zu den Komponenten auf der Form.
Nur im FormCreate werden ch1 bis ch8 ueberhaupt direkt angefasst. Im Rest des Programms wird dann nur noch Scrollbars verwendet.
Die Elemente von Scrollbars sind ch1 bis ch8 selbst, nicht Kopien. Die obige Source ist also Unsinn da sie ueberhaupt nichts macht.

[Robert Marquardt]

..und der naechste Schnipsel uneleganten Codes:

Delphi-Quellcode:

case data.preheatvalue of
0: begin vorwaermung:=127; vorwaerm0.Checked:=true; StatusBar1.Panels.Items[1].Text:='Vorwärmung: 0%'; end;
1: begin vorwaermung:=125; vorwaerm1.Checked:=true; StatusBar1.Panels.Items[1].Text:='Vorwärmung: 1%'; end;
2: begin vorwaermung:=124; vorwaerm2.Checked:=true; StatusBar1.Panels.Items[1].Text:='Vorwärmung: 2%'; end;
3: begin vorwaermung:=123; vorwaerm3.Checked:=true; StatusBar1.Panels.Items[1].Text:='Vorwärmung: 3%'; end;
4: begin vorwaermung:=121; vorwaerm4.Checked:=true; StatusBar1.Panels.Items[1].Text:='Vorwärmung: 4%'; end;
5: begin vorwaermung:=120; vorwaerm5.Checked:=true; StatusBar1.Panels.Items[1].Text:='Vorwärmung: 5%'; end;
6: begin vorwaermung:=119; vorwaerm6.Checked:=true; StatusBar1.Panels.Items[1].Text:='Vorwärmung: 6%'; end;
7: begin vorwaermung:=118; vorwaerm7.Checked:=true; StatusBar1.Panels.Items[1].Text:='Vorwärmung: 7%'; end;
8: begin vorwaermung:=116; vorwaerm8.Checked:=true; StatusBar1.Panels.Items[1].Text:='Vorwärmung: 8%'; end;
9: begin vorwaermung:=115; vorwaerm9.Checked:=true; StatusBar1.Panels.Items[1].Text:='Vorwärmung: 9%'; end;
end;

Offensichtlich gibt es hier eine Tabelle von konstanten Werten fuer die Vorwaermung.
Na dann deklarieren wir die doch einfach als Konstante.

Delphi-Quellcode:

const
  Vorwaermungstabelle: array [0..9] of Integer =
    (127, 125, 124, 123, 121, 120, 119, 118, 116, 115);

  Vorwaermung := Vorwaermungstabelle[data.preheatvalue];
  VorwaermCheckboxes[data.preheatvalue].Checked := True;
  StatusBar1.Panels.Items[1].Text := Format('Vorwärmung: %d%%', [data.preheatvalue]);

[Robert Marquardt]

Weiter gehts mit den Verbesserungsvorschlaegen.
Nochmals zur Erinnerung. Das Hauptfenster ist recht gelungen. Viele kommerzielle Programme sind schlechter designt.
Trotzdem gibt es noch genug zu meckern :-)

Die initiale Beschriftung der Buttons ist falsch. Es muss nicht genannt werden das es ein Button ist, sondern die auszuloesende Aktion muss benannt werden.
Also "Szene 1" bis "Szene 8" und "Effekt 1" bis "Effekt 8". Durch die Trennung der Nummerierung entfaellt auch der falsche Zusammenhang.
es waere noch sehr praktisch wenn die Buttons ein Popupmenue zur individuellen Umbenennung bekommen koennten. Es sollte nicht zum grossen Umbenennungsdialog fuehren, sondern zu einem Dialog mit nur einem Eingabefeld fuehren.

Kommen wir wieder zur Source.
FormCreate:
Der SplashScreen gehoert ins .dpr File. Nur dort kann er vor der Erstellung der MainForm angezeigt werden. Dazu gibt es glaube ich einen Code-Library-Eintrag.
Alles ab "// Statusleiste bereit machen" bis (ausschliesslich) "startfademem := 1;" sind Einstellungen die in der IDE an den Komponenten gemacht werden sollten.
Das Laden des Konfigurationsfiles gehoert in eine eigene Methode, da es vielleicht auch an anderer Stelle zu gebrauchen ist.
Die folgenden Zuweisungen lassen sich natuerlich mit Komponenten-Arrays entscheidend vereinfachen.
"case data.comport of" ist wiederum ein typischer Fall fuer eine konstante Tabelle.
"// Kanäle 1-32 von Opto Control Deluxe 32 auf 0 setzen" schreit nach einer eigenen Methode "ResetOCDChannels".
"// Alle Toolboxes wie zuletzt gespeichert anordnen" ist ein Kandidat fuer ein Komponenten-Array. Spaetestens wenn es eine Aktion zum Aufraeumen gibt.
"case data.preheatvalue of" wurde ja schon in der vorigen Message behandelt.

"TMainForm.Senddataout" sollte anders organisiert werden. Das zu sendende Datenpaket erst in einem Puffer zusammenstellen und dann in einem comport.senddata senden.

Delphi-Quellcode:

var
  Puffer: array [0..15] of Byte;
begin
  // alles auf 0 setzen
  FillChar(Puffer, SizeOf(Puffer), 0);

  // ... die einzelnen Bytes eintragen

  // in einem Rutsch senden (auf die verschiedene Laenge pro Firmware achten)
  comport.senddata(Puffer, 15);

Der Grund ist, das bei einem USB zu RS232-Adapter das Senden eines einzelnen Bytes 3 ms dauert, ein laengerer Puffer aber nicht mehtr Zeit braucht.

Delphi-Quellcode:

procedure TMainForm.CheckBtns();
var
  B: Boolean;
begin
  B := listbox.items.count <= 0;
  AddBtn.Enabled := B;
  AddPMnu.Enabled := B;
  RunBtn.enabled := not B;
  ...

und die Methode schrumpft auf die Haelfte zusammen.

Exit1Click() sollte einfach nur Close audfrufen. Der Dialog wird in den OnCloseQuery-Event der Form verlegt, dann kommt die Abfrage immer egal wie man die Form schliesst.

Es folgen Codewuesteneien, die der Komponenten-Arrays beduerfen.

Bei COMx1Click() hoer ich jetzt mal auf.
Mit dem obigen und besonders mit Komponenten-Arrays duerften noch mehrere Tausend Codezeilen verschwinden, ohne das das Programm irgendetwas verliert.

[christian.noeding]

Puh, das sind etliche Korrekturen und Verbesserungsvorschläge, die mir durchaus einleuchten... ich werde versuchen, sie bestmöglich umzusetzen (aber nicht heute und morgen, da ich noch andere Dinge zu machen habe ;-))

Sicher werde ich trotz Anleitung an manchen Dingen hängenbleiben (wie gesagt: ich habe mit Delphi erst im November/Dezember 2004 angefangen) - bisher war ich zufrieden, wenn der erstbeste Weg funktioniert hat (-> siehe irre lange Listen)




Zur Boolschen Algebra: die Ausdrücke habe ich z.B. bei Abfragen =true gesetzt, damit ich halbwegs die Übersicht behalte. Somit kann ich da gleich erkennen, dass ich boolsche Ausdrücke habe ;) aber ich kann da sicher auch drauf verzichten *g*



Zu dem Missverständnis:

Delphi-Quellcode:

for i:=1 to 8 do
TScrollBar(FindComponent('ch'+inttostr(i))).position:=scrollbars[i].position;
// ch1..ch8 sind die Fader und scrollbars[1..8] sind dann die Komponenten-Arrays ;)

ich hatte den Trick schon halbwegs verstanden, nur nicht umsetzen können. Mit obigen Zeilen wollte ich die Oberfläche aktualisieren (hatte bei Tests auch geklappt), da ich ja die Verlinkung von Komponenten-Arrays und MainForm-Komponenten nicht hinbekommen hatte - aber mit der erneuten Beschreibung werde ich das nochmals versuchen :D



Ich werde also doch noch einiges am Programm zu tun habe ;) ich habe auch immer noch nicht die Menüeinträge überarbeitet (-> Script=Skript,etc.) und die ganzen anderen (wichtigeren) Vorschläge :D...



schönen Abend noch,
Christian :)

[christian.noeding]

:D es hat mir doch keine Ruhe gelassen und ich habe ein paar Tipps heute noch umgesetzt. Allerdings noch nicht den ganzen Code auf Arrays umgebaut, was ich ja für weitere Vereinfachungen dann brauche.

Mal sehen, da ich in den nächsten Wochen dann mit dem Programm die Theaterproben beleuchten und dann im September schon den Auftritt habe, werde ich wohl nichts großartiges mehr am Code ändern, sondern ihn jetzt mal ausgiebig auf Fehler testen und schauen, ob er stabil in jeder Situation läuft. :D


dennoch nehme ich gerne noch ein paar Tipps entgegen ;) :coder2:

Die aktuelle Version lautet nun 2.0.3.0 und ist wieder hier downloadbar :)



schönen Restmontag noch,
Christian :hi:

[christian.noeding]

Hallo,

bis gestern hatte ich gedacht, ich hätte jetzt alle schlimmen Fehler aus meinem Programm, aber jetzt gibt es ein Problem, welches ich nicht eingrenzen kann...

Wenn ich eine Windows-Fehlermeldung produziere oder ein Open-/Savedialog aufrufe, dann bleibt die Titelleiste meines Programmes deaktiviert nachdem ich die Dialogfelder per OK oder Abbrechen schließe und ich kann auf keine Funktionen (auch nicht mehr das "X" der Form) klicken.

Es sieht so aus, als würde das Programm nicht mehr als "Active" gelten...


ich habe den Sourcecode hier zum runterladen: Sourcecode 2.0.3.6 Beta


Es wäre toll wenn einer da mal drübergucken könnte, oder falls das Problem bekannt ist, mir vielleicht einen Tipp geben könnte, wo ich suchen soll - ich bin da jetzt recht ratlos.



Besten Dank,
Christian! :coder2:

[christian.noeding]

Nachdem ich zum x-ten mal alles durchgegangen bin, habe ich den Fehler gefunden.


Die PowerButton-Komponente hier aus dem Forum hat den Fehler verursacht! :wall: Ich werde jetzt mal in den Sourcecode der Komponente reinschauen, was die Komponente alles macht und woran das liegen kann...



:dance: dummdidumm, irres Gefühl wenn Fehler plötzlich weg sind *g* :dance:


schönen Abend noch!
Christian :D

[mh166]

Zitat:

Zitat von christian.noeding

:dance: dummdidumm, irres Gefühl wenn Fehler plötzlich weg sind *g* :dance:

Jepp, DAS sind die Adrenalinstöße, die das Programmieren so spannend und schön machen! :D

mfg, mh166

[christian.noeding]

Hi Leute,

nach etlichen Zwischen-Releases habe ich nun wieder eine neue Version des PC_DIMMERs rausgebracht. Also wollte ich das hier mal etwas publik machen. Zwar habe ich es immer noch nicht geschafft, alle Verbesserungsvorschläge aus dem Forum hier umzusetzen, allerdings sind einige neue Funktionen hinzugekommen (Einheitliche Projektdatei, Effekttimeline, Szenenablaufliste, Bugfixes, etc.).

Falls jemand den PC_DIMMER verwendet, kann er die neue Version hier runterladen:
230V 128 Kanal PC_DIMMER v2.1.0.0


Der aktuelle Sourcecode ist noch nicht online, wird aber sicher in den kommenden Tagen passieren.


Die offizielle Homepage liegt wie gehabt hier: http://www.pcdimmer.de



Schönes Wochenende :D
Christian

[Codehunter]

Also als Elektroniker der sich schon mal eine 5-kanalige Lichtorgel gebaut hat interessiert mich das Projekt schon.

Also habe ich mir die Schaltpläne mal reingezogen. Was ich da jetzt ganz und gar nicht verstehe: Die gezeigte Schaltung steuert jeweils 8 Kanäle mit einem µProzessor. Gut. Dann gibts da eine vierbittige Adressierung per DIP-Schalter welcher wohl für den µProzessor eine ID von 0 bis 15 vergibt. Auch klar. Also 8x16=128 Kanäle.

Nur was mir aus der Schaltung überhaupt nicht klar wird: Wie bitte soll man, wie auf der Website angegeben, mit einem einzigen COM-Port 128 Kanäle steuern? So wie ich die Schaltung sehe braucht je 8 Kanäle einen COM-Port. Eine Datenübergabe an den nächsten µProzessor sehe ich in der Schaltung jedenfalls nicht. Auch die gezeigten Hardwarelösungen betreiben alle nur jeweils 8 Kanäle.

Also wie kriegt man jetzt 128 Kanäle in Hardware realisiert? Ich hab mal vor vielen Jahren Spezial-ISA-Karten gesehen die über ein Steckpanel 8 COM-Ports lieferten und DOS kannte ja auch die Ports COM1 bis COM9. Aber 16? Gib mir mal nen Schubs wie ich das verstehen soll.

[christian.noeding]

Hallo Codehunter,

du kannst tatsächlich mindestens 128 Kanäle mit nur einem Comport regeln. Du musst dir das wie ein Bussystem vorstellen: an einen Comport kommen alle 8 Mikrocontroller dran. Da alle Mikrocontroller jedesmal das gleiche empfangen bekommt jeder eine eindeutige ID, sodass man jeden Controller einzeln ansteuern kann. Somit kann man sogar wie bei DMX ein einziges langes Kabel durch alle Geräte durchschleifen.

Das hat sich in der Praxis bereits sehr bewährt und die Hardware läuft sicher und stabil.

Wenn du weitere Fragen hast, dann steht dir auch unser Forum (forum.pcdimmer.de) zur Verfügung, in dem ich gern alle Fragen beantworte ;-)


viele Grüße,
Christian :)

[Codehunter]

Also alle 8 Controller (wieso eigentlich jetzt 8? Müßten doch 16 sein oder?) hängen praktisch parallel geschaltet an den RX/TX-Leitungen vom COM-Port? Interessante Idee, ist mir noch nie in den Sinn gekommen.

Aber wenn man das logisch durchdenkt tun sich da zwei Probleme auf. Erstens würde so eine Durchschleifgeschichte in Verbindung mit einem Laptop kaum mit so vielen "Bus-Hosts" funktionieren. Dafür sind die Signalpegel am RS232 eines Laptops zu schlapp weil jede Schaltung die Signalleitung mit 10 kOhm gegen Masse belastet.

Das zweite Problem dürften die Waitcycles sein. Das heißt je mehr "Bus-Hosts" auf diese Weise verschaltet werden, umso träger wird das Ganze. Denn je mehr "Hosts" an dem Bus hängen umso weniger Zeitanteile entfallen pro "Host". Haben denn die µProzessoren einen internen Puffer und reicht die Baudrate um 128 Kanäle so schnell anzusteuern daß sagen wir mal 3 Hz Blinkfrequenz pro Kanal möglich sind?

[christian.noeding]

Sorry, ich meinte 16... ich war in Gedanken bei "8-Bit" der Mikrocontroller - warum auch immer *g*

Nun, die 10kOhm gehen ja nicht direkt gegen Masse, sondern nur auf die Basis des Transistors. Die Ströme zwischen Basis und Emitter sind sehr gering und belasten den Comport nur wenig - von daher sind hier keine Probleme zu erwarten. Bislang funktioniert meine Schaltung mit 7 angeschlossenen Geräten einwandfrei. Man könnte natürlich eine Art Signal-Booster verwenden, aber dafür sehe ich noch keinen Grund, da selbst mit meinem USB-2-RS232-Adapter für den Laptop das alles gut funktioniert.

Und ja, alle 16(!) Geräte hängen parallel. Man könnte hier sogar noch weiterausbauen, indem man z.B. statt einer 7-Bit Adressierung eine z.B. 8-Bit Adressierung (255 Geräte) verwendet. Dies wäre lediglich eine kleine Firmwareanpassung (und natürlich dann auch an der Software, obwohl die Hardware auch mit DMX-Software über entsprechende Plugins funktioniert: z.b. DMXControl)


Derzeit läuft die Übertragung mit 115,2kBit/s und damit kann man alle 128 Kanäle recht schnell ansprechen. Natürlich steigt die Zeit mit der Anzahl der Kanäle. So kann ich z.B. 4 Kanäle viel schneller wechseln (ca. 4-7 Hz) als alle 128 Kanäle gleichzeitig (max. 1 Hz), aber das Problem gibt es auch bei DMX *g*

Die µController haben einen internen Puffer. Diese speichern erstmal den kompletten RS232 Rahmen und verarbeiten ihn dann. Somit ist der Bus sofort wieder frei und es kommt zu keinem Datenstau. Eine interne Fehlerkorrektur verhindert falsche Adressierung bzw. fehlerhafte Daten. Allerdings ist derzeit kein Repeating bei Fehlern vorgesehen, sodass bei Übertragungsfehlern der Befehl manuell erneut gesendet werden muss.

Man hat hier also viele Vorteile von einer komplexen DMX Hardware aber kann mit geringsten Mitteln einen Dimmer aufbauen. Von Flimmereffekten bishin zu stundenlangen Fadeins ist hier alles möglich. So nutze ich z.B. den Dimmer auch bei mir im Wohnzimmer über ein Wandpanel ;)


ciao,
Christian.


PS: es werden am Comport nur Änderungen, nicht aber laufend das gesamte Universe (wie z.B. bei DMX) übertragen. Die µController speichern intern die Werte und erhalten nur neue Anweisungen!

[Codehunter]

Also lassen wir das Problem der Signalpegel auf dem COM mal beiseite, da gibts gute und schlechte Hersteller von UART-Chips. Zur Not halt einen MAX232xxx dazwischen und gut is.

115 kBaud ist ja schon mal recht flott :) Sollte man die Leitung aber nicht allzu lang machen und sauber verlöten am Stecker.

Wie viele Fade-Stufen hat das System eigentlich? Hab ich irgendwie nicht rausgefunden auf der Website.

Das "Next Big Thing" dürften sicherlich LED-Lichtquellen sein. In der Richtung schläft DMX nämlich derzeit noch den Schlaf der Gerechten ;) Zwar hast du da einen 0..10-Volt Treiber aber das ist eben mit Netzteil, Vorwiderstand und LED auch schrecklich ineffizient. Eine LED dimmt man ja typischerweise auch nicht über die Spannung sondern über das Impuls-Pause-Verhältnis bei konstanter Frequenz. (Ok ok eine Phasenanschnittsteuerung ist das Selbe in Grün, nur ist das halt "schrecklich altmodisch analog" ;) )

In der Praxis würde das dann so aussehen daß man die 230 Volt Netzspannung per Grätzbrücke gleichrichtet, ein oder zwei dicke Elkos dran und dann gehts damit ab in ein Array von Thyristoren. Weil bei LED-Lichtquellen wesentlich kleinere Ströme fließen brauchts hier kaum Kühlung. Allerdings brauchste dann zwischen Thyristor und Lichtquelle ein geschirmtes Kabel. Denn wenn du 300 Volt mit sagen wir mal 50 kHz schaltest und das auf eine 20-Meter-Strippe legst, dann hast nen prima Mittelwellensender ;)

Nur wie müßte dann die Steuereinheit aussehen? Ein Taktgenerator mit steuerbarem Impuls-Pause-Verhältnis. Wenn man den jetzt geschickt konstruiert (diskret mit ein paar Bauteilen und Taktmultiplikator) könnte man den direkt an der Lichtquelle plazieren. Das Ganze bestünde dann aus 4 billigen 1N4148, einem Elko zum Glätten, besagtem Taktmultiplikator der aus den 50 Hz Netzfrequenz gespeist wird und dem Impuls-Pause-Regler. Der müßte idealerweise einen kleinen Puffer haben und einen 8-Bit-Wert verarbeiten. So beschickst du diese Einheit nur jeweils mit einem neuen Datenwert und der behält diesen dann bis zum Eintreffen des nächsten Wertes. So hast dann 256 Helligkeitsstufen.

Vorteil bei dem Verfahren: Du brauchst pro Kanal und Helligkeitsänderung nur ein einziges Byte senden. Dadurch kannst du viel mehr Kanäle deutlich schneller mit Daten versorgen. Und du hast im Leistungsbereich sehr kurze Leitungswege wodurch Störungen auf dem Netz gegen Null gehen.

Stell dir mal eine parallele statt einer seriellen Steuerung vor. Du hast eine 16-adrige Steuerleitung. 8 Bits für die Adressierung, 8 Bits Daten. Macht 256 Kanäle a 256 Helligkeitsstufen mit einer einzigen Word-Variable. Du brauchst keine riesigen Geräte-Kästen mehr wo die ganzen Leistungssteller und Schukodosen verbaut werden. Du kannst da ganz neue Effekte ermöglichen mit so einer affig schnellen Steuerung :)

[christian.noeding]

Tja, bislang scheint das ganze bis ca. 100m stabil zu laufen. Das liegt aber mitunter daran, dass ich nur eine Tx-Leitung und keine Tx/Rx-Leitung habe, sodass keine Störungen auf die jeweils andere Leitung aufinduziert werden.

Die Faderstufen sind wie folgt: steuere ich vom Computer den Dimmer per Fader, dann nutze ich (aus Protokollgründen) 128 Schritte (ich habe nur 7 Bit frei). Dimmt der µController selber, dann nutzt er die vollen 256 Schritte aus. Das ist ja das dolle, dass ich dem Controller nur den Endwert und die Zeitspanne übermitteln muss, sodass er dann fröhlich alleine ohne PC vor sich hindimmt ;-)

Das mit den Thyristoren an Gleichspannung habe ich überhört... versuche mal die zu löschen. ich glaube du meinst eher MOSFETs, Transistoren, oder IGBTs? Und ich nutze als Gate-Signal für die TRIACs ja ein 100 Hz PWM-Signal. Das kann man ohne weiteres direkt ans Gate eines MOSFETs klemmen. Mit entsprechender SK-Drossel glättet sich der Strom auch gleich ein wenig und die LEDs bleiben etwas länger Leben =) Natürlich könnte man hier auch überlegen, die Frequenz aus Flimmergründen etwas zu erhöhen...


Als Taktgenerator kann man doch wieder einen Mikrocontroller nutzen? der schafft locker ein 20-50 kHz Signal und man kann ihn natlos in den PC_DIMMER BUS einklemmen. Nur warum du jetzt mit paralleler Technik anfangen willst, kann ich nicht ganz nachvollziehen? Ich bin gerade froh, dass das ganze seriell abläuft, da auf diese Weise auf der Bühne die geringste Menge an Leitung nötig ist. Zudem kann man prima die XLR Leitungen nutzen.
Derzeit muss ich auch lediglich ein Byte Adresse und ein Byte Helligkeit übertragen. Die anderen 4 Bytes meines Protokolls enthalten die Informationen für das automatische Dimmen und für Steuerungen, wie z.B. die Adressvergabe per Software oder das Auslesen der µController-Informationen (Frequenz, Firmwareversion, etc.)


Ich werde auch jetzt nicht mit einem neuen Projekt anfangen, da sich der PC_DIMMER durchaus in der Praxis auf der Bühne, wie auch in der Wohnung durchaus bewährt hat :bounce2:


:spin2: ciaociao!

[Codehunter]

Das mit der Leitungsmenge ist bei meiner Idee relativ betrachtet auch nicht mehr. Du hast dann mit der Spannungsversorgung weniger Kabelei weil du im Gegensatz zur zentralen Steuerung nicht jeweils ein Stromkabel vom Steuergerät zur Lampe ziehen must. Kannst du ja bequem Mehrfachdosen-Verteiler verwenden da du mit LED-Lampen nur kleine Ströme hast.

Denk das doch mal ein Stück weiter. Du kannst ja wieder einen Bus aufbauen, seriell oder parallel ist doch dir überlassen. Also baust du eine Reihe von kleinen Steuergeräten auf, die jeweils eine 8-adrige Steuerleitung zur Lampe führen. Die Steuergeräte hast du dann direkt im Bühnengerüst hängen.

Mit LED-Lichttechnik wird sich ja einiges grundlegend verändern, die alten Gebräuche bei der Verkabelung eingeschlossen. Ich hab ja sogar schon LED-Module gesehen die Leistungssteller eingebaut hatten inkl. Empfänger für eine Infrarot-Fernbedienung. Dahin wird die Reise gehen: Lampenmodule mit eingebauter Steuerung und direkter Adressierung. Irgendwann gibts dann auch noch WLAN-on-a-Chip und du steuerst den ganzen Laden per WLAN und USB-Stick vom Laptop :)

PS: Mit dem Thyristor hast du natürlich recht, ich meinte Leistungstransistor.

[christian.noeding]

Per WLAN wär ne feine Sache :) Endlich kein Kabelsalat mehr *g*

Das mit den LED Strahlern werde ich mir zukünftig mal etwas genauer anschauen. Vielleicht ist da ja sogar was für meine Bühne mit dabei :)

Was die normalen Halogenlampen in Wärme umsetzen ist bald nicht mehr schön *g*

[Codehunter]

Jo im Winter brauchst bei Halogen und LED Handschuhe. Nur bei Halogen wegen der Hitze und bei LED um nicht festzufrieren ;)

Das Kernproblem bei LED's ist ja die prinzipbedingt kleine Leuchtfläche und damit bei ultrahellen LED's die hohe Lichtdichte im Vergleich zur Gehäusegröße. Ich denke vorallem im Bereich SMD-LED wird sich da noch viel tun (Stichwort Luxeon). Mit den Dome-förmigen LED's ist jedenfalls auf Dauer kein Blumentopf zu gewinnen.