So, ich habe das mal ganz unprofessionell aufgemalt:
Takt und Strobe (Latch) liegen an allen Registern parallel an, die Dateneingänge des n-ten Registers werden mit dem Überlauf des (n-1)-ten Registers verbunden.

Im Schaltplan fehlen ganz grundlegende Bauteile: so fehlen Widerstände an den Dateneingängen, die für definiertes Potential sorgen, wenn kein PC angeschlossen ist sowie Maßnahmen, um Störungen zu dämpfen.

Parallel zu jedem IC muss ein Keramikkondensator 100nF.

Die Leuchtdioden kannst du direkt an die Schieberegister anschließen, wenn du durch sie maximal 2mA fließen lässt.

Das macht man normalerweise nicht, da das schon 16mA sind, wenn alle leuchten. In der Praxis funktioniert das aber .
(Die Logikpegel kannst du danach vergessen )

_________________

Achso, jetzt versteh ich...

Man schreibt die Bits also seriell in den ersten Schieberegister. Dieser reicht, wenn er voll ist, die, in ihm gespeicherten, Bits über den seriellen Ausgang weiter an den nächsten Schieberegister. Und diese Prozedur wiederholt sich so lange, bis alle Bits geschrieben wurden.

Jetzt sind dann also die ersten Bits am Ende des 9. Registers gespeichert und die letzten Bits am Anfang des 1. und dann sendet man ein Latch-Signal und alle Bits werden über die parallelen Ausgänge weiter an die Dioden gesendet!

Vielen Dank

Das war aber ein schwere Geburt aber letztendlich doch erfolgreich, so hoffe ich zumindest

vielen Dank

Edidt: Ach so, noch eine Frage, welches Programm hast du zum Erstellen des Logikschaltplanes verwendet?

[ Diese Nachricht wurde geändert von: gruenemoehre am  7 Aug 2010 13:11 ]

gschem - der Schaltplaneditor des gEDA-Projekts

Momentan meines Wissens nach nur für Linux verfügbar.


_________________

Danke für die Info

Moin,
bitte

P.S.: du hast das völlig richtig verstanden.

Und du siehst: du kommst mit drei Datenleitungen aus.

Das große Problem ist wie gesagt wirklich nur, an die Infos zu kommen, wie die Bitmaske gefüllt werden muss.
Am besten fragst du da mal den Administrator, der sollte (hoffentlich... ) die Infrastruktur ausreichend kennen. Eventuell ist er ja so freundlich, euch eine Schnittstelle zu programmieren, die nur die relevanten Daten zur Verfügung stellt (z.B. über einen Socket, also über eine Netzwerkschnittstelle.)

Das wäre quasi optimal, da ihr euch dann auf die Hardware konzentrieren könnt und soweit ich weiß, kann man Sockets in VB übelst einfach ansprechen.

_________________

Super endlich gerafft

ja, danke für den Hinweis. Ich werde ihn mal fragen, ob er uns das zurecht schreiben kann

nochmals vielen Dank an alle für die schnelle und hervorragende Hilfe!!

So nun kann der Thread wirklich geschlossen werden

Nö, den lassen wir auf, schließlich wollen wir wissen, wie es weitergeht .

_________________

Moin,

habt ihr euch mal das POP3-Protokoll angeschaut?
Wenn mich nicht alles täuscht, fragen die Mailclients nach dem Login die Anzahl neuer Nachrichten vom Server ab. Erst danach werden die neuen Nachrichten heruntergeladen und in der lokalen Datenbank abgelegt.
Damit arbeiten wahrscheinlich auch die ganzen Taskbar-Progrämmchen, die einem neue Mails anzeigen.

Ihr könntet euch dafür einen Mini-Client bauen, der nur den Status abfragt und sich sofort wieder ausloggt. So wird auf keinen Fall im Account etwas geändert und ihr habt mit dem Inhalt der Nachrichten garnichts zu tun.
Weil euer Client auch keine weiteren Befehle unterstützt oder auf Funktionen Zugriff hat, wie das z.B. bei einem Thunderbird-Addon der Fall wäre, kann hier auch relativ wenig schief gehen.
Ein sauber konfigurierter Server schmeißt im schlimmsten Fall euren Client aus dem Netzwerk, wenn der Amok fährt.

Als zusätzliche Sicherheit könntet ihr die Zugangsdaten auf einem Netzlaufwerk hinterlegen. Sollte sich dann jemand eure Kiste unter den Arm klemmen, wäre das Programm für ihn nutzlos.

Vielleicht lässt sich auch der Mailserver konfigurieren, dass er für euch "Dummy-Nutzerkonten" anbietet.
Euer Programm würde sich dann nicht mit den echten Mailadressen einloggen, sondern mit einem Account wie z.B. "statusabfrage.müller.heinz@schule.de".
Dieser Account hat im Postfach keine Schreibrechte und ist im Idealfall soweit abgeriegelt, das er nur den Status abfragen kann.

Ihr solltet auch darüber nachdenken, die Abfragen zeitlich zu verteilen.
Es ist sicher ausreichend, wenn die 70 Mailkonten über die Schulstunde verteilt abgefragt werden und der Status zu jeder großen Pause aktuell ist.
"Wichtige" Lehrer können natürlich ein kürzeres Intervall bekommen.

Zum lesen, Kapitel 7: http://webee.technion.ac.il/labs/co.....x.htm

Edit: Neee, doch eher Kapitel 5 "The TRANSACTION State" bzw. den "STAT"-Befehl.

_________________
We now return you to your regularly scheduled nonsense.

[ Diese Nachricht wurde geändert von: LeoLöwe reloaded am  7 Aug 2010 15:41 ]

Ich bleibe dabei: um den Mailkrams soll sich der Admin kümmern, wenn so ein Projekt schon durchgeführt werden soll.


Ich kenne Software, die ähnlich ist (auch für Lehrer), die mit propritären Protokollen (Also nix POP3) arbeiten.

Soll also der Admin die paar Zeilen kode reinhacken und an Port 12345 zur Verfügung stellen. Die Jungs können sich die Daten dann dort abholen.

So würde ich es machen, wenn ich Admin wäre: an meine Sachen lasse ich niemanden ran. Auch an den Lehrerkonten hat absolut niemand was zu suchen, auch nicht eingeschränkt.

_________________

Der Knackpunkt ist die Maillösung in der Schule. Je nach Serverprogramm ist es möglich, dort Erweiterungen oder Dienste zu erstellen, die den Status abfragen und im Netzwerk bereitstellen. Hierzu solltet ihr euren Admin befragen, die Lösung wie DonComi sie angibt wäre jedenfalls die sinnvollste und sicherste. Die POP3-Lösung direkt in eurem Programm wäre zwar vom Serverprogramm weitgehend unabhängig, aber entsprechend auch unsicher.
Das erste und letzte Wort bei der Abfrageart hat jedenfalls euer Administrator. Um einen Tipp zu geben müsste ich den Programmnamen des Mailservers und mit welchem Programm eure Leerer die Mails abfragen (Webinterface, Outlook, oder sonstige Clients).

_________________
Reboot oder be root, das ist hier die Frage.

Also ok, dann bleibt der Thread offen

Und ich werde versuchen euch über den neusten Stand des Projektes auf dem Laufenden zu halten

Zitat : LeoLöwe reloaded hat am  7 Aug 2010 15:39 geschrieben :

habt ihr euch mal das POP3-Protokoll angeschaut? Wenn mich nicht alles täuscht, fragen die Mailclients nach dem Login die Anzahl neuer Nachrichten vom Server ab. Erst danach werden die neuen Nachrichten heruntergeladen und in der lokalen Datenbank abgelegt.

Also, ich habe das Protokoll so verstanden, dass POP3 nicht nach neuen und alten Mails unterscheiden kann, sondern nur prüft, ob überhaupt Mails im Posteingang sind. Die Prüfung auf neu bzw. alt nimmt das lokale Programm vor.

Zitat :

Das habe ich aus einem VB snippet ... ich weiß... selber schreiben ist immer besser, aber wenn man mal nicht weiter weiß, hilft einen das auch weiter... ' There is nothing in the POP3 protocol that allows for "new" or "unread" emails ' to be downloaded. The read/unread status of an email is not available via the ' POP3 protocol. This means programs must save the read/unread status locally.

was darauf hinaus laufen würde, dass man die Anzahl aller Mails hat, und daher den Betreff einer jeden Mail ebenfalls runterladen und mit schon vorhandenen, gespeicherten Betreffen vergleichen müsste.

Aus diesem Grund finde ich die Lösung von DonComi mit Propritären Protokollen arbeitet gar nicht mal schlecht. Da müsste sich halt nur der Admin hinsetzen und die von ihm geschriebenen Zeilen uns zur Verfügung stellen. Müssen wir mal schauen, ob wir ihn dazu überreden können
Aber wie gesagt, weiteres kann ich euch erst morgen oder villeicht auch erst Dienstag mitteilen...

Bis dahin

gruenemoehre

Er muss euch die geschriebenen Zeilen nicht zur Verfügung stellen, sondern auf dem Server laufen lassen. Euch zur Verfügung stehen muss das Ergebnis.

Zu POP3 zur Vollständigkeit noch etwas Erklärung: Ursprünglich war es gedacht wie die Postfächer bei der Post. Es kommen Mails rein und werden dort gespeichert, bis ein Client diese abruft. Ist das geschehen, sind die Mails auf dem Client und vom Server gelöscht. Somit sind alle Mails, die laut POP3 vorhanden sind auch neu. Dann kam die Funktion mit dem Kopie auf dem Server belassen. Wenn diese (imho schwachsinnige) Funktion eingeschaltet ist wäre eurerseits keine Prüfung mehr möglich. Bei einer rein clientseitigen Ausführung wäre ein Plugin im Mailprogramm erforderlich, welches die gelesenen Mails an euch meldet.
Dann kam irgendwann IMAP, mit dem die Mails grundsätzlich auf dem Server bleiben und dort organisiert werden können (war das schon ein früher Schritt zum kommenden Cloud Computing oder ein Nachzügler aus der Mainframe- und Großrechner-Zeit ). In Kombination mit POP3 ist es meistens so, dass POP3 nur den Posteingang auf Mails prüft, die anderen Ordner aber unangetastet lässt.

Daraus ergibt sich bei erneutem Nachdenken: Da die Mailboxen hoffentlich zentral auf einem Server liegen und nicht mit POP3 und Thunderbird gearbeitet wird (nichts gegen Thunderbird, nur die Kombi passt nicht ins "geschäftliche Umfeld"), vergiss die POP3-Lösung wieder. Euch bleibt nur die Möglichkeit über den Admin, dass dieser euch den Status irgendwie per Netzwerk zur Verfügung stellt oder (zumindest aus technischer Sicht und sofern der Server mitspielt) IMAP und bekannten Passwörtern.

_________________
Reboot oder be root, das ist hier die Frage.

Moin,

Schönes Missverständnis:

Zitat :

Aus diesem Grund finde ich die Lösung von DonComi mit Propritären Protokollen arbeitet gar nicht mal schlecht. Da müsste sich halt nur der Admin hinsetzen und die von ihm geschriebenen Zeilen uns zur Verfügung stellen

Wie gesagt, mir ist die Software einer Firma bekannt, die für interne Mailfunktionalität auf propritäre Protokolle setzt, also i.d.R. auf selbstentwickelte Protokolle. Diese Protokolle werden nur Programmierern der Firma zur Implementierung offengelegt, andere Entwickler haben keinen Zugriff auf die Spezifikationen (oder nur für viel Geld).

In Anlehnung an clembras Beitrag: der Admin wird euch, wenn es der MAilserver erlaubt, eine Erweiterung programmieren müssen. Diese ermittelt, welche Konten ungelesene Mails hat und stellt euch diese Informationen über Netzwerk bereit.

Damit wird diese Erweiterung genaugenommen zu einem Server, mit dem ihr euch als Client verbinden könnt. Über ein eigenes Protokoll (sei es noch so einfach) übermittelt der Server euch die Zustände aller Konten (siehe Server-Client-Modell).

Das hat viele Vorteile:
1. ihr müsst nichts am Mailserver machen - das wird normalerweise auch nur über Sprachen wie C, C++ oder Java (odr perl, ruby, python, sh, ... ) möglich sein, also nicht in VB.
2. ihr kommt über Netzwerk und eine definierte Schnittstelle an die relevanten Daten, die ihr auch über VB verarbeiten könnt.

Einfacher gehts kaum noch und ihr verletzt nicht den Datenschutz.

_________________