Nicols Lighting LED Scanner

Dem Pult muss bei 16bit modus gesagt werden auf welchen zusätzlichen kanälen die "fine" liegen.

Bei Scannern ist meiner ansicht nach die 16bit auflösung nicht so wichtig da der Aktionsradius ja begrenzt ist, bei MH sind die möglichen bewegungen ja wesentlich größer nd daher fallen die schritte auch größer aus. Durch den projektionsabstand vergrößern sich die Schritte nochmals so das ma gerade bei MH nach nicht um 16 bit herumkommt.

Das häufige "ruckeln" billiger Scanner hängt aber erst in 2. Linie von der art der ansteuerung ab, meistens sind es einfach billige Stepper oder Treiber die viel weniger als 8 bit. das erklärt auch das wieso manche mit 8 bit ruckeln, andere relativ sauber fahren.

Nun zu dem Scanner, meinst du den Hop´s Led ? Zumindest optisch sieht er gleich dem jb systems micro scan led aus, hat nur 10W mehr Leistung, vielelicht hat damit jemand erfahrung.

Ansonsten ruf doch mal bei world media an, die haben den Vertrieb für Nicols

Zitat

Bei Scannern ist meiner ansicht nach die 16bit auflösung nicht so wichtig da der Aktionsradius ja begrenzt ist, bei MH sind die möglichen bewegungen ja wesentlich größer nd daher fallen die schritte auch größer aus

Es ist doch egal ob du 160° oder 360° nimmst, es kommt auf die Winkel der Schritte an und die sind für alle gleich da ja auf 360° gerechnet wird. Steht aber alle oben super erklärt.

Und was machst du nach deiner Theorie bei nem MH der z.B. nen Pan von 540° hat weil er über einen Riemen angetrieben ist?
Oder da sich die 256 steps ja auf 360° beziehen wie du schreibst - läuft der Scanner dann schon bei dem halben DMX wert in den Anschlag weil er nur 170° Pan hat?

Das Problem liegt wohl eher darin das bei günstigen Geräten an Stelle der microstepper günstigere Servomotoren einebaut werden.

Es lässt sich also auch beim Scanner die "Schrittlänge" in Grad einfach errechnen, z.b. 170° Pan geteilt durch 256 Schritte, sind also ungefähr 0,6 ° .

Zitat

Es lässt sich also auch beim Scanner die "Schrittlänge" in Grad einfach errechnen, z.b. 170° Pan geteilt durch 256 Schritte, sind also ungefähr 0,6 ° .

Nach dieser Taktik hätte ein Scanner mit weniger Pan eine höhere Genauigkeit, dachte aber dass die Winkel vom Steppermotor vorgegeben werden. Die ändern sich ja dann nicht.

Wenn ich nun falsch liege habe ich es wohl nicht verstanden. Vielleicht erklärt es mir ja einer.

Du kannst ganz einfach gesehen die genauigkeit ausrechnen wenn du den weg des Spiegels durch die Anzahl der der Schritte teilst.

Trotzdem kann es natürlich sein das der Servomotor oder Stepper insgesamt weniger als 256 Schritte hat, dan würde er eben jeden 2. oder 3. Schritt nur anfahren und es würde zum "rucken" kommen. Das dies bei "billigen" Geräten so ist mag sein, bei jedem halbwegs vernünftigen sollte aber die Auflösung des DMX-Signales die Schrittmenge begrenzen und icht der verbaute Motor!

zum Beispiel der Scanner mit 170° Pan.

DMX 0 Spiegel bei 0° (z.b. ganz links)
DMX 256 Spiegel bei 170° (z.B. ganz rechts)

Bei 8 bit währen das 256 Schritte
Bei 16 bit dann 512 Schritte

Der Stepper dessen Ansteuerung für 16 bit ausgelegt ist der aber nur mit 8 bit über dmx angesteuert wird macht also auch nur 256 Schritte.

Ganz interessant wird es dann wenn die Scan´s dann noch zwischen vector und Tracking mode unterscheiden, dann sind nämlich auch mit 8 bit schöne ruhige Fahrten möglich!

Danke!

Nun frage ich mich wieso meine dann nicht ruckeln wenn ich sie ganz langsam große Radien fahren lasse. Beim GLP Scan Operator FX ist ja nur der erste PAN und der erste TILT Kanal für die Moves angegeben. Daher müssten sie ja mit 8 Bit angesteuert werden. Aber da ruckt und zuckelt nix auch wenn ich die langsamste Bewegungsgeschwindigkeit und den größten Bewegungsradius auswähle. Sollte aber nach der bisherigen Erklärung ja so sein, oder?

Nicht unbedingt, wenn du Scanner verwendest die gute microstepper sowie gute treiber haben fahren sie auch mit 8 bit ruhige fahrten! aus eigener Erfahrung könnte ich da die alten roboscans sowie miniscans nennen die trotz 8 bit schöne ruhige spiegelfahrten ermöglichen. Die ich glaube von dir genannten Joy 300 gehören da auch zu.

Was sich dort mit 16 bit dann nur verbessern würde wäre die Positionierbarkeit auf weite Projektionsentfernungen, welche bei dem eingeschränkten Bewegungsradius der Scanner aber auch nicht so schlimm auffält!

Zitat von "Gamer254"

[...]16bit verarbeiten. Also kann dieser mit 2x 256 Schritten[...]

Sorry, aber das ist quark. Jeder der 256 Schritte des Grob-Kanals ist durch den Fine-Kanal in nochmal 256 Schritte unterteilt. Dadurch ergeben sich 2^8 * 2^8 = 2^16 = 65536 mögliche Schritte und nicht nur 256 *2.
Jo

PS: Wenn mein Pult keine 16bit kann, bediene ich eben nur die Grob-Kanäle, also nur 8bit. Damit kann ich zu einem Ende, jedoch nicht ganz bis zum anderen Fahren. Wen das stört, der patcht sich beide "8-Bit-Nibbles", also den Grob- und Fein-Kanal auf einen einzigen Fader.

Dann zeig mir mal bitte einen Steppermotor der Schritte in 0,0055° Schritten macht. Was ja laut deiner tollen Methode so ein muss?!
Das schafft selbst die Mikrotechnik nicht. Zu dem kannst du mit jedem Kanal den Spiegel ganz hin und her fahren was deine Methode sogar praktisch belegt. Also glaube ich nicht das dem so ist.
Außderdem hätten wir dann eine Auflösung von 8x8bit=64bit und nicht 16bit. Also wird das wohl quatsch sein was du sagst. Warum die Kanäle allerdings Grob und Fein heißen weiß ich nicht. Aber so wird es wohl nicht sein!

Hmmm ...

also wenn ich die Scanner mit dem groben Kanal positioniere kann ich bei den Joy mit dem Fine-Kanal die Positionierung sehr genau auch auf große Entfernungen vornehmen. Aber ich kann nicht den ganzen Aktionsradius des Scanners mit dem Fine-Kanal nutzen. Das zwischen den einzelnen Schritten 255 Positionen liegen ist sicher nicht möglich, das würde ja bedeutet, dass ich mich bei einer Entfernung von 30m im Zentimeter bis Millimeterbereich bewege. So fein kann ich da nun auch wieder nicht positionieren. Aber ich kann ja mal einen anschmeißen und dies in der Praxis überprüfen.

Zitat

Nicht unbedingt, wenn du Scanner verwendest die gute microstepper sowie gute treiber haben fahren sie auch mit 8 bit ruhige fahrten! aus eigener Erfahrung könnte ich da die alten roboscans sowie miniscans nennen die trotz 8 bit schöne ruhige spiegelfahrten ermöglichen. Die ich glaube von dir genannten Joy 300 gehören da auch zu.

Was sich dort mit 16 bit dann nur verbessern würde wäre die Positionierbarkeit auf weite Projektionsentfernungen, welche bei dem eingeschränkten Bewegungsradius der Scanner aber auch nicht so schlimm auffält!

So habe ich bisher auch den Eindruck. Grundarbeit mit 8Bit und Positionierbarkeit sehr genau mit 16 Bit. Die Positionierbarkeit ermöglicht erst die effektvolle Beleuchtung von z.B. einem Barocksaal etc. Mal schaun Ende April sind sie alle gebucht, bis dahin ist es meist nur DJ Job oder nur ein paar EF2 und Grundlicht, dann werde ich es mal ausprobieren.

Zitat von "Gamer254"

Dann zeig mir mal bitte einen Steppermotor der Schritte in 0,0055° Schritten macht. Was ja laut deiner tollen Methode so ein muss?!
Das schafft selbst die Mikrotechnik nicht. Zu dem kannst du mit jedem Kanal den Spiegel ganz hin und her fahren was deine Methode sogar praktisch belegt. Also glaube ich nicht das dem so ist.
Außderdem hätten wir dann eine Auflösung von 8x8bit=64bit und nicht 16bit. Also wird das wohl quatsch sein was du sagst. Warum die Kanäle allerdings Grob und Fein heißen weiß ich nicht. Aber so wird es wohl nicht sein!

Aua, zurück in die 5. Klasse und Binärsystem lernen!

[8bit] * [8bit] <> [64bit]!!!
[8bit] * [8bit] = 256 * 256 = 65536

Ja, ein 16bit Kanäl benutzt in der Tat 65536 Schritte, kann also die Werte 0 - 65535 annehmen.
Natürlich kennt DMX zunächst nur 8bit, aber man kann problemlos im Pult 2 8bit Kanäle zu 16bit zusammenfassen. Die Gerätebibliothek muss nur dem Pult gegeben, welches Gerätekanal der Grob-Kanal (most significant bit MSB) und welches der Fein-Kanal (least significant bit LSB) ist, dann schickt es die entsprechenden Werte auf die entsprechenden Kanäle. Der Scheinwerfer wiederum weiß natürlich wiederum, welche zwei 8bit Kanäle er zur 16bit Position zusammenfassen muss. In der Tat liegen ansteuerungsseitig zwischen jedem Schritt, den der Grob-Kanal weiterschaltet, 256 Fein-Schritte. Wenn man also nur den LSB Kanal ansteuern würde, bewegt sich am Scheinwerfer eher wenig. Bei den entsprechenden Pulten merkt man eben nur nichts davon, da sie automatisch die beiden Kanäle verwursteln und man nicht getrennt an grob und fein kurbeln muss.

Der nächste Fehler besteht darin, die 65536 Schritte direkt auf die 360° der Schrittmotorpositionierung umzurechnen: die 65536 bzw. 256 beziehen sich auf den physikalischen Bewegungsbereich der jeweiligen Funktion (Pan/Tilt, Gobo-Indizierung), schließlich sind die Mechanik und der Schrittmotor nicht 1:1 gekoppelt, sondern durchaus über eine entsprechend Übersetzung. Sonst könnten sich Geräte wie der MAC III kaum von kompakten Schrittmotoren bewegen lassen... Natürlich entspricht dennoch nicht jeder einzelne der bis zu 65536 Schritte direkt einem Schrittmotorschritt, aber wer mal mit der entsprechenden Hardware gespielt hat, wird sehen, dass er nichts sieht - nämlich keine sichtbaren Positionssprünge, wenn man durch die Werte scrollt.

Was hat das nun mit der "Geschmeidigkeit" langsamer Bewegungen zu tun: Es ist eine Komponenten davon. Die andere Komponente ist die interne Umsetzung der DMX Daten auf die Schrittmotoransteuerung.
Während bei Scannern 8bit durchaus ausreichend für die Bewegung sein können, wenn die Elektronik mehr oder weniger Zwischenwerte beim Wechsel zwischen zwei Werten an die Motoren schickt, so dass der eigentlich harte Wechsel vom "digitalen" Schritt zum nächsten quasi weichgerechnet wird, ist bei Moving Heads da weniger zu machen. Bei den üblichen 540° Pan kommen bei 8bit auf jeden Schritt mehr als 2° Rotation. So viel kann die Elektronik eigentlich nicht mehr weichrechnen. Also braucht es einfach ein paar Schritte mehr. Und da DMX nur 8bit Pakete kann, ist der nächste Schritt eben 16bit. Aber selbst hier gilt: Besitzt die Scheinwerfersoftware nicht die notwendigen Algorithmen, um gegebenenfalls Zwischenwerte zu berechnen, kann auch hier trotz der vielen Werte eine Bewegung durchaus ruckelig sein.

Dementsprechend muss schon die Kombination aus interne Aufbereitung und Schrittzahl passen, damit am Ende wirklich weiche, langsame Bewegungen ohne Ruckeln möglich sind.
Dass jeweils eines der beiden alleine nicht ausreicht, haben ja hier schon genug festgestellt.

Ich hoffe, dass jetzt für jeden der Mythos 8bit vs. 16bit entzaubert ist :wink: