mal wieder: china meßschieber - 2x24bit-Protokoll mit PIC auslesen

[wicki (Gast)]

Hi zusammen,

ich habe mal meine alte DOSen-Software ausgegraben (China-Schieber an 
Parort) und das nun fuer PICs (18F14k50) umgebaut.

Das Ding kann z.Zt. einen einzelnen Schieber mit Strom versorgen,
auslesen und via seriellem Output an den PC schicken.

Wenn Interesse besteht, dann koennte ich die Software bei gleicher
Hardware auf 5 Schieber erweitern.

Der PIC bezieht seinen Strom aus dem USB-Port und benoetigt keine
externen Bauteile. Die Ausgabe ist ASCII mit 2 Nachkommastellen.

0000000140.36
0000000140.37
0000000140.36

Gibts dafuer einen Bedarf?
Falls Interesse besteht, einfach hier posten.
Denn anmelden kann ich mich derzeit nicht.

Munter bleiben

Wicki

[Ulrich F. (Gast)]

Mich würde eher ein Link zu den billig China Messchiebern interessieren.
Oder Produktbezeichnungen (Futter für Google)
(Bin nix PIC User, sondern Arduino Fan)

[MaWin (Gast)]

wicki schrieb:
> Gibts dafuer einen Bedarf?

Im Prinzip ja.

Das Problem der verbreiteten Schaltungen ist ja, dass sie nicht mit dem 
Messschieber laufen den man hat, nicht so viele unterstützt wie man 
braucht, nicht mit dem uC aufgebaut ist für den man ein Programmiergerät 
hat, und nicht mit der Software zusammenarbeiten, die man für die CNC 
verwendet, und daher blödereeise nicht 1:1 passt. Und zur Anpassung 
fehlen Mechanikern die Kenntnisse.

Allerdings sehr ich nicht den Vorteil deiner Lösung. Der uC ist 
exotisch, die (serielle USB) Weitrrleitung endet im Nirvana. Niemand 
lässt dafür ein WinTerm laufen. Es müsste wenigstens ein Porgramm für 
Windows und/oder Linux her, was die Anzeige auf dem Bildschirm 
bildschirmfüllend mit Achsenbezeichnungen und winzigklein always on top 
kann, und ein Mach3/emc2 Integration die die Werte dort in der 
Oberfläche anzeigt.

Dinge wie Vorzeichenwechsel und *2 und addieren von Achsen sollte auch 
unterstützt werden.

[wicki (Gast)]

MaWin schrieb:
> Das Problem der verbreiteten Schaltungen ist ja, dass sie nicht mit dem
> Messschieber laufen den man hat, nicht so viele unterstützt wie man
> braucht, nicht mit dem uC aufgebaut ist für den man ein Programmiergerät
> hat, und nicht mit der Software zusammenarbeiten, die man für die CNC
> verwendet, und daher blödereeise nicht 1:1 passt. Und zur Anpassung
> fehlen Mechanikern die Kenntnisse.

ich habe bislang nur die mit 2x24-bit Protokoll gefunden.
Wenn jemand einen anderen hat, dann wuerde ich versuchen, auch den zum
laufen zu bekommen.
In meinem PIC steckt ein Bootloader, mit dem man den PIC selbst
programmieren kann - ohne Programmiergeraet. Also waeren eigene
Erweiterungen moeglich.


> Niemand lässt dafür ein WinTerm laufen. Es müsste wenigstens ein
> Porgramm für Windows und/oder Linux her, was die Anzeige auf dem
> Bildschirm bildschirmfüllend mit Achsenbezeichnungen und winzigklein
> always on top  kann, und ein Mach3/emc2 Integration die die Werte
> dort in der  Oberfläche anzeigt.

das ist doch relativer Kinderkram...
"cat /dev/ttyUSB" in einem X-term mit gewuenscher Schriftart und 
-groesse
ist die simpelste aller Loesungen. Man koennte auch in Java oder Python
was basteln.
Ich wuerde das in EMC2 integrieren wollen - das System ist ja ziemlich
offen.
Die Frage ist: braucht das wer?

> Dinge wie Vorzeichenwechsel und *2 und addieren von Achsen sollte auch
> unterstützt werden.

Das waere der naechste Schritt. Ein Billigschieber kann nur 150mm. Der
PIC koennte 2 (oder auch mehr) verketten. Und man kann dann 300 oder
450mm messen. Allerdings fuer den Preis der Verdrei- oder -vierfachung
des Messfehlers....
Will man das?

Und dann noch die Frage des "mehrere Schieber an einem PIC":
Ganz billig ist die Loesung des sequenziellen Lesens aller Schieber.
Dann gibts aber nur etwa 1 Messwert pro Sekunde.
Mehr Aufwand ist das parallele Lesen aller angeschlossenen Schieber.
Trotzdem kommen die Werte fuer eine Echtzeitsteuerung von Fraesen
oder Lathen eigentlich zu langsam (meine Schieber produzieren etwa
3 Werte/Sekunde).

[Thomas F. (igel)]

wicki schrieb:
> ich habe bislang nur die mit 2x24-bit Protokoll gefunden.
> Wenn jemand einen anderen hat, dann wuerde ich versuchen, auch den zum
> laufen zu bekommen.

Das 6x 4-Bit Protokoll ist ebenfalls weit verbreitet.
Beitrag "10stelliges 7-Segment DRO für WABECO Messschieber"
Beitrag "Messchieber auslesen - unbekanntes Protokoll"

[wicki (Gast)]

Thomas F. schrieb:
> Das 6x 4-Bit Protokoll ist ebenfalls weit verbreitet.

haben alle WABECOS dieses Protokoll?
Dann wuerde ich einen zum testen bestellen.
(denn noch einen 2x24bit brauch ich nicht)

[Dietrich L. (dietrichl)]

wicki schrieb:
> haben alle WABECOS dieses Protokoll?

Ich habe im Jahre 2009 3 Anbaumessschieber für meine Fräsmaschine bei 
WABECO gekauft.
Dazu verwende ich die Schieblehrenanzeige "SLA 1" von ELV (in der 
Zeitschrift "Maschinen im Modellbau" gab es einen Artikel, in dem stand, 
dass Messschieber und Anzeige zusammen passen), und es funktioniert.
Das Protokoll ist beim "SLA 1" beschrieben: siehe Anhang.

Da bei WABECO bei allen Messschiebern kein Hinweis über das Protokoll 
steht, nehme ich doch an, dass alle gleich sind.
Ob die Glasmaßstäbe auch dieses Protokoll haben, kann ich nicht sagen.

Gruß Dietrich

[Reiner W. (reiner_w)]

wicki schrieb:
> Trotzdem kommen die Werte fuer eine Echtzeitsteuerung von Fraesen
> oder Lathen eigentlich zu langsam (meine Schieber produzieren etwa
> 3 Werte/Sekunde).

Ja, dafür würde ich es auch nicht nutzen wollen.
Die Datagramme kommen:

2*24
Normal Mode  alle 350ms
fastmode     alle  20ms

6*4          alle 110ms

Ich hab mir ne Anzeige gebastelt die PSoC /ARM verwendet. Ich lese 3 
Kanäle simultan in voller Geschwindigkeit, auch im 2*24 Fastmode.
Die Unterschiede in der Datagramm-Folge/Länge benutze ich auch zur 
automatischen Protokollerkennung.
In letzter Zeit (2015) sind mir eigentlich nur noch Messschieber mit 6*4 
Protokoll untergekommen Aldi/Lidl/Norma/China/Webaco-Anbaumessschieber

6*4 solltest du also unbedingt implementieren.

Ob du mit dem Pic das auch simultan hinbekommst, kann ich nicht 
beurteilen. Mit dem M0@24MHz war es kein Problem

Reiner

[wicki (Gast)]

Danke fuer die Hinweise.


Reiner W. schrieb:

> Normal Mode  alle 350ms
> fastmode     alle  20ms

Aber wie bekomme ich das Ding in den fast-Mode?
Als Tasten haben die nur "mm/inch", "zero" und "ON/off"
iIgendwo hatte ich mal was dazu gelesen - aber ich finds nicht mehr
wieder.


> 6*4          alle 110ms

und ich hab noch 2 etwas neuere "kraft" Messer (norma? penny?)
die habe ich noch nicht getestet- vielleicht sind die 6*4

[Reiner W. (reiner_w)]

wicki schrieb:
> Aber wie bekomme ich das Ding in den fast-Mode?

Kann ich dir für deinen Messschieber auch nicht sagen. Meine Exemplare 
haben eine Modus-Taste. Kombiniert mit der Null-Taste kommt man damit in 
den Fastmode. Per uC kann man die Null-Taste durch 300ms High (1,5V) an 
der
clk-Leitung erreichen und die Mode-Taste durch 300ms an der data 
Leitung. Du kannst ja mal versuchen, ob das bei deinen Modellen auch 
funktioniert.

Anbei mein Zustandsdiagramm für die Messschieber. Den Fastmode erreichst 
du also durch einen Impuls auf der Data-Leitung gefolgt von einen Impuls 
auf der clk-Leitung. (Geht also über den Hold-Mode)
Zurück kommst du mit einem Impuls auf der Data-Leitung.

Achtung das hier gesagte gilt NUR für die 2*24bit Variante. Und ich kann 
auch nicht garantieren, dass das bei dir auch so geht;-) mir sind 
mindestens 3 verschiedene Bedienungen (SMs) für die alten 2*24er 
bekannt.
Deshalb hab ich auch meine eigene SM drübergesetzt, die dann allgemein 
bei allen Messschiebern (2*24, 6*4) gleich funktioniert. Statt der 
eingebauten Holdmodi (falls vorhanden) verwende ich eigene 
Software-Hold-Modi.

wicki schrieb:
> und ich hab noch 2 etwas neuere "kraft" Messer (norma? penny?)
> die habe ich noch nicht getestet- vielleicht sind die 6*4

Häng sie halt an einen Oszi.

Reiner

[Michael B. (laberkopp)]

wicki schrieb:
> Die Frage ist: braucht das wer?

Ja, wozu braucht er sonst Messchieber, wenn er sie nicht sehen kann ? 
Wenigstens sehen wenn er die Maschine manuell bedient möglichst gross 
und deutlich, der nächste (und sinnvolle) Schritt ist in der CNC 
zugreifbar haben.

Ein Beispiel für Messchieber: Abgleich Schritte vs. reale Position. 
Willst du das per Hand machen ? Man schreibt einen G-Code Skript, der 
bis zu einem Sollwert läuft. Dazu muss man auf den Messchieberwert von 
der CNC aus zugreifen können.

Oder man vermisst den Tisch, ob alle 1cm per Steppermotor auch wirklich 
1.000cm erreicht werden, und wie gross das Umkehrspiel ist. Willst du 
5000 Werte per Hand aufschreiben und abgleichen ? Das macht ein Skript, 
und dazu muss es, oh Wunder, auf die Messschieberwerte zugreifen könne. 
Und wenn du das nur für EMC2 zeigst wie es geht, werden die Mach3 Leute 
deine Messschiebersoftware gar nicht erst probieren.

[wicki (Gast)]

Reiner W. schrieb:
> Du kannst ja mal versuchen, ob das bei deinen Modellen auch
> funktioniert.

jau!
Danke - das klappt auch bei meinem.

Und ich habe einen gefunden, der offensichtlich das 6x4 Bit faehrt.
Der Schieber sieht optisch genauso aus wie die anderen.
Sollte eigentlich kein Problem sein, den ebenfalls zu lesen.
Die Anschlussbelegung der Kontaktleiste ist identisch:

+
Clock
Data
-

mal basteln.....

[wicki (Gast)]

Vollzug!

6x4 Bit geht auch ;-)

Dabei kommen die Werte dann aber quasi als echter Zahlenwert.
Bei dem 2x24 muss ich den 24-Bit Wert noch umrechnen (durch 1612 
teilen),
um auf den Messwert zu kommen.

Nun waere noch eine automatische Protokollerkennung wuenschenswert.
Ebenso die parallele Bearbeitung mehrerer Schieber.

Aber ich hab ja noch ein paar kb Platz ;-)

Bekommt man eigentlich irgendwo Stecker, die in den Anschluss passen?
Man muesste eigentlich einfach was aus einer kupferbeschichteten
Leiterplatte fraesen koennen und mit einem kleinen Federchen auf
die Anschluesse pressen.

[Reiner W. (reiner_w)]

wicki schrieb:
> Nun waere noch eine automatische Protokollerkennung wuenschenswert.

Hängt natürlich von deinem Algorithmus ab. Ich verwende ein 
Abtastfenster für das Datagramm. Da definiert sich das Protokoll aus 
clk-Impulse innerhalb einer bestimmten Abtastlänge. Bei den beiden 
Protokollen 24*4(SYLVAC) und 6*4 (Aldi) reicht das, weil es da keine 
Überschneidungen gibt. (siehe Bild1)
Die Protokollermittlung mache ich dann während jedem datagram. Das klapp 
dann natürlich auch, wenn im laufenden Betrieb umgesteckt wird;-)
Bild 2 Zeigt das Vorgehen.
Beim Einschalten (oder auch nach mehreren Fehlern - dann wurde 
umgesteckt)  bekommt jeder Messschieber das Protokoll FIRSTRUN 
zugewiesen, wird also nicht ausgewertet. Das ist nötig, da beim 
Einschalten ja der Messschieber sich innerhalb eines datagrams befinden 
kann und die gezählten Restimpulse genau einem anderen Protokoll 
entsprechen könnte.
Ab dem 2. datagramm wird das Protokoll dann ermittelt.

wicki schrieb:
> Bekommt man eigentlich irgendwo Stecker, die in den Anschluss passen?

Also ich kenne zumindest Messschieber mit MINI-USB und solche, die 
zumindest einen Footprint für Mini-USB drauf haben. Einige Anbieter 
vertreiben auch direkt passenden Kabel für den 0815-Messschieber. (Must 
du gurgeln, hab grad keinen zur Hand)
Ich selber verwende inzwischen JST siehe Bild3 (falls unbedingt Stecker 
sein muss). Die bekommst die preiswert bei den üblichen Kandidaten.

wicki schrieb:
> Man muesste eigentlich einfach was aus einer kupferbeschichteten
> Leiterplatte fraesen koennen und mit einem kleinen Federchen auf

Würde ich nicht unbedingt empfehlen. Die meisten Probleme hatte ich 
bisher mit Steckverbindungen, zumal der Einsatzort ja i.d.R. nicht der 
Sauberste ist.

Ich rate zu löten und versiegeln.

Reiner

[Thomas F. (igel)]

Reiner W. schrieb:
>> Man muesste eigentlich einfach was aus einer kupferbeschichteten
>> Leiterplatte fraesen koennen und mit einem kleinen Federchen auf
>
> Würde ich nicht unbedingt empfehlen.

Ist auch meine Erfahrung: Mit selbstgefrästen Kontakten hatte ich immer 
Wackelkontakte. Ich habe dann die Leitungen direkt angelötet und durch 
eine Bohrung im Deckel durchgeführt.

[Wicki W. (wicki)]

Reiner W. schrieb:
> zumal der Einsatzort ja i.d.R. nicht der
> Sauberste ist.
> Ich rate zu löten und versiegeln.

ja - das ist n Argument...

Nun mal was anderes: wie macht Ihr das mit der galvanischen Trennung?
Die Schieber jetzt einfach auf die Fraese aufschrauben oder
mit isolierter Halterung?

Die, die ich hier habe, haben zwar alle dem "+" als Masse, aber
a) ist das ja nicht wirklich schoen
b) kann man sich u.U. nicht darauf verlassen, dass das immer so ist
c) lasse ich die Schieber momentan gegen ein vom PIC erzeugtes
   "schwebendes -" laufen. Ein also irgendwo zwischen 1 und 3 Volt
   angesiedeltes Potenzial

Insbesondere "c" ist nicht wirklich aesthetisch, bringt aber den 
Verzicht
auf jede Art von zusaetzlichem Bauteil.

Wie seht Ihr das ?

Munter bleiben

Wicki

[Reiner W. (reiner_w)]

Wicki W. schrieb:
> Nun mal was anderes: wie macht Ihr das mit der galvanischen Trennung?

Ich hab mal eine Variante mit Digital Isolatoren Si8420 getestet, das 
ging perfekt. Habt sie dann allerdings in der V1.0 nicht verwendet. Das 
ist etwas aufwendiger, weil die Dinger nicht bidirektional arbeiten und 
auf der data/clk Leitung ja auch geschalten werden muss.
In der nächsten Version will ich das aber so machen.

Derzeit mach ich das höchst unprofessionell etwa nach c)
Die Versorgungsspannung stelle ich direkt mit einem Pin vom uC pro 
Messschieber zur Verfügung. Damit ist es einfach, die 6x4 Schieber zu 
nullen. Dabei wird die Spannung dann für ca. 100ms unterbrochen. Einen 
Fastmode kennen die ja nicht.

Der Nullpegel der Schieber wird mit einem Transistor auf 0,7V angehoben. 
Damit liegt der Ausgangspegel der Schieber dann im TTL Bereich und kann 
direkt gekoppelt werden.
Auf die Z-Dioden hab ich dann auch noch verzichtet, da reichen mir die 
im PSoC Chip integrierten (in V1.0).
Die data/clk Pins werden bidirektional betrieben, deshalb der 
Spannungsteiler am Eingang. Die beiden C's sorgen dann wieder für eine 
ordentliche Impulsqualität.

ACHTUNG!
Diese Version darf nur eingesetzt werden, wenn alle 3 Schieber gleiches 
Messepotential (+/-) haben oder sicher isoliert montiert sind. Und die 
Masse der Auswerteelektronik muss natürlich auch isoliert sein.

Bei der Spannungsversorgung mit einem Innenwiderstand von 3,3k passiert 
allerdings im Kurzschlussfall (Messschieber unterschiedliches 
Messepotential und nicht isoliert) nicht wirklich was;-)

Bei mir arbeitet die Variante an einer großen Fräse bei 3 2x24bit 
Schieber und ca. 2m Kabellänge am Schieber, seit ca. 6 Monaten ohne 
Problem

Die Variante ist zwar recht preiswert und tuts auch, aber professionell 
geht anders;-)

Wicki W. schrieb:
> b) kann man sich u.U. nicht darauf verlassen, dass das immer so ist

Ich hab beide Versionen, was ich erst bemerkt habe, als ich verzweifelt 
nach dem Kurzschluss gesucht habe;-)

[Thomas F. (igel)]

Wicki W. schrieb:
> Die Schieber jetzt einfach auf die Fraese aufschrauben oder
> mit isolierter Halterung?

Meine drei Messschieber sind metallisch fest verschraubt, also über die 
Maschine auf PE-Potential. Versorgungsspannung kommt aus einem alten 
PC-Netzteil. Bisher keinerlei Probleme.

[Wicki W. (wicki)]

Hi nochmal,

also so wie es aussieht, ist es wohl kaum machbar, mit einem PIC
(16MHz interner IRC) mehrere Schieber simultan auszulesen.
Zumindest bei den 2x24-Protokollen.
Ich muss mit hoechstens 5uSec abtasten und auswerten und dafuer
habe ich in der Zeit nicht genug Befehle zur Verfuegung. Und um einen
kompletten Bitstream vom 5 Schiebern abzuspeichern und diesen dann
spaeter auszuwerten - dafuer fehlt mir der Platz.

Also muss ich es entweder:
a) sequenziell
oder
b) mit mehreren PICs
oder
c) mit externem OSC und hoeherem Takt
lesen

Mit "c" muesste es gehen - waere aber mit Softwareaufwand und
-optimierung verbunden. (10 Eingaenge innerhalb vom 5 uSec abfragen
und die Ergebnisse verwertbar abspeichern - das koennte auch bei 48Mhz
eng werden)

"b" waere Hard- und Softwareaufwand. Aber beliebig skalierbar.

"a" reduziert die Zahl der pro Sekunde auswertbaren Messwerte.
(statt 50/Sekunde waren es dann nur noch ca. 10)


Und nun weiss ich nicht so recht, was ich nun bevorzugen soll.
Oder habe ich irgendwo n Denkfehler da drin?

Munter bleiben

Wicki

[Reiner W. (reiner_w)]

Wicki W. schrieb:
> Ich muss mit hoechstens 5uSec abtasten und auswerten und dafuer
> habe ich in der Zeit nicht genug Befehle zur Verfuegung.

Wie sieht denn dein Algorithmus aus? Ich löse bei jedem clk einen IR aus 
und in der ISR schreib ich die date-leitung dann weg. Da ist die ISR 
dann extrem kurz. Beim 2*24 sind's ja nur ca. 70kHz

Reiner

[Wicki W. (wicki)]

Reiner W. schrieb:
> Wie sieht denn dein Algorithmus aus? Ich löse bei jedem clk einen IR aus


hmmm.... klar.... interessanter Ansatz.
Interrupt on change hatte ich irgendwie voellig verdraengt.

Bei 5 Schiebern koennen ja theoretisch 5 IRs gleichzeitig auftreten.
Das duerfte auch recht komplex werden - denn jeder kann ja gerade an
einer anderen Stelle in seinem Protkoll haengen.
Aber es ist wert mal drueber nachzudenken.

[Michael B. (laberkopp)]

Wicki W. schrieb:
> Oder habe ich irgendwo n Denkfehler da drin?

Obwohl es sicherlich auch ein PIC schafft, kann ein Design, das pro 
Messschieber einen uC verwendet, ja sinnvoll sein, wenn man die Platine 
so aufbaut, daß davon mehrere nebeneinander anordnungsbar sind, und ihre 
Daten über möglichst nur ein USB Port zum PC (Mach3 etc.) transportieren 
können, also von uC zu uC reichen bis zum uC der das USB bedient.

Und du wolltest gar keine Anzeige, so wie ich dich verstand.

[Wicki W. (wicki)]

Michael B. schrieb:

> Obwohl es sicherlich auch ein PIC schafft,

das mit dem einen PIC, das frage ich mich ja grade, ob das wohl
wirklich geht.
Es soll absolut minimalistisch sein. Also ohne externe Bauteile.

Ich muss moeglichst ein Abtastraster von 5 uSec einhalten und der PIC 
ist
mit 16 MHz getaktet (sonst brauch ich einen Quarz). Also habe ich
16*5/4=20 Befehle zur Verfuegung - so grob gerundet.
Mit diesen 20 Befehlen muss ich 5 Taktleitungen testen, den Status
des Protokolls abfragen und den Datenleitungsstatus zur Auswertung 
abspeichern.
Das klingt verdammt knapp....

[Reiner W. (reiner_w)]

Wicki W. schrieb:
> Ich muss moeglichst ein Abtastraster von 5 uSec einhalten und der PIC
> ist

Ich kenne zwar deinen konkreten Algorithmus nicht, da hast du noch 
nichts zu geschrieben. Und leider habe auch vom PIC keine Ahnung;-) aber 
das klingt fast so, als würdest du die Leitungen pollen.
Damit hast du in der Tat bei dem 2*24 Protokoll keine Freude.
Anbei ein Auszug aus dem Sylvac_Protokoll.
Interessant sind die beiden letzten Zeilen, demnach ist die DatenLeitung 
nur +/- 1us an der steigenden clk-Flanke gültig. Und ich habe bei 
längeren Anschlussleitungen (ca. 2m) die Erfahrung gemacht, dass man 
sich da tunlichst dran halten sollte, weil die Signalqualität dann schon 
ziemlich schlecht ist.
Das geht eigentlich sinnvoll nur noch mit einem IR an der steigenden 
clk-Flanke.
Innerhalb der ISR brauchst du ja dann nur noch die data-leitung in ein 
Array schieben. Das sollte auch der Pic in 1us schaffen.
Die Auswertung machst du dann nachdem das Abtastfenster abgelaufen ist. 
Selbst beim schnellsten Protokoll (2*24 Fastmode) hast du dann 20ms Zeit 
dafür.
Selbst für den extrem unwahrscheinlichen Fall, dass bei 3 Messschiebern 
2 clk-Impulse unterschiedlicher Messschieber exakt synchron sind, und 
eine ISR somit eine Verzögerung > 1us und die data-leitung nicht mehr 
korrekt gelesen werden könnte (hatte ich eigentlich noch nicht) na dann 
ist halt ein Datagramm falsch. Aber so schnell würde das dein Auge nicht 
mitbekommen;-)
Du brauchst also pro Messschieber einen IR_on_rising_edge und evtl. 
einen zusätzlichen timer-IR, je nachdem, wie du das Abtastfenster 
realisiert.
Also ich kann nur sagen, ich habe damit bei 3 Messschiebern simultan 
keine Probleme. Und ich kann mir auch nicht vorstellen, dass das der PIC 
nicht schaffen sollte. Aber der letzte Satz ohne Gewähr.

Reiner

[Wicki W. (wicki)]

Reiner W. schrieb:

> Also ich kann nur sagen, ich habe damit bei 3 Messschiebern simultan
> keine Probleme. Und ich kann mir auch nicht vorstellen, dass das der PIC
> nicht schaffen sollte. Aber der letzte Satz ohne Gewähr.

ich wiederum kann sagen: mehr als ein Schieber wird mit einem
pic 18f14k50 ohne Quarz schon ganz schoen eng. (simultan)
Interrupt on edge gibt es nur 3, ICOs gibts zwar mehr, aber die
Unterscheidung, welcher Pin und welcher Level uns welcher Status des
Protokolls es ist - das braucht so viele Befehle, dass Interrupts
verloren gehen. Insbesondere sind die IOCs der PICs auch nicht
unproblematisch (http://www.xargs.com/pic/portb-change-bug.html).

Also bin ich von der "ein-Pic-fuer-5-Schieber"-Loesung weg und baue nun
eine skalierbare "ein-Pic-pro-Schieber"-Loesung.
Bei 2 EUR/PIC ist das wohl wirtschaflicher..... ;-)

Ich werde aber die "ein-Pic-liesst-5-Schieber-sequenziell"-Loesung
auch mal testweise probieren.

[Paul (Gast)]

http://www.fingers-welt.de/Postille/Ausgabe2/Postille_2015.pdf

Hier, ab Seite 34 inkl. Signalaufbereitung, Link zum Quellcode im Text.

Viele Grüße
Paul

[Wicki W. (wicki)]

Hi mal wieder...

also ich kann jetzt mit einem PIC 18f14k50 6 Schieber
mit 2x24-Protokoll lesen und schaffe etwas mehr als 40 Messungen
pro Sekunde. (also nicht ganz 10/Schieber/Sekunde)
Die Daten werden als ANSI/ASCII-Stream mit 115200 Baud ausgeworfen, 
werden
von einem 2303 nach USB umgesetzt und koennen z.B. in einem
Terminalfenster in 98-Punkt-(oderwasauchimmer)-Schrift anzeigt werden.

Nun muss ich noch das 6x4-Protokoll mit einbauen (laufen tuts ja schon)
und dann mal testen, wie es mit 6 echten Schiebern gleichzeitig laeuft.
(momentan simuliere ich alles mit einem einzigen Schieber)
Es koennte dadurch u.U. schneller werden.

Ausserdem sollte das noch skalierbar sein, weil der serielle Output
abgeschaltet wird, wenn keine Daten gesendet werden. D.h.: auch 12,
18 oder 24 Schieber sollten ueber einen einzigen USB-Port gehen.

Wenn sich nun noch ein Irrer findet, der das mal testen moechte:
Einfach mailen....

munter bleiben

wicki

[Michael B. (laberkopp)]

Wicki W. schrieb:
> momentan simuliere ich alles mit einem einzigen Schieber)

Das ist aber Unsinn, weil 6 Schieber natürlich zeitlich versetzt ihren 
Takt und Startsignal senden. Das simultan auswerten musste 150ns pro Bit 
erfordern.

Aber da man sowieso nicht 1500 Messwerte/Sekunde senden muss/kann, 
reicht es, einen nach dem anderen zu erfassen, dauert ja höchstens 1ms 
bis der jeweils abgehörte sendet.

[Wicki W. (wicki)]

Michael B. schrieb:
>> momentan simuliere ich alles mit einem einzigen Schieber)
>
> Das ist aber Unsinn, weil 6 Schieber natürlich zeitlich versetzt ihren
> Takt und Startsignal senden. Das simultan auswerten musste 150ns pro Bit
> erfordern.

Daher sagte ich ja: mit echten Schiebern sollte es etwas schneller 
werden,
weil man ja momentan nicht mehr messen kann, als real Signale anliegen.
Wenn aber in den Sendepausen von Schieber 0 die anderen senden, koennen
diese Signale in der Zeit verarbeitet werden.
Das teste ich aber noch aus.
Simultan geht es mit dem PIC mit 16MHz definitiv nicht.
Mit einem auf 64MHz bequarzten koennte es vielleicht klappen.
Wuerde aber trotzdem sehr viel Codeoptimierung erfordern.

[Reiner W. (reiner_w)]

Wicki W. schrieb:
> Daher sagte ich ja: mit echten Schiebern sollte es etwas schneller
> werden,
> weil man ja momentan nicht mehr messen kann, als real Signale anliegen.
> Wenn aber in den Sendepausen von Schieber 0 die anderen senden, koennen
> diese Signale in der Zeit verarbeitet werden.

Ich weis ja nicht, wie dein Auslesealgorithmus aussieht, aber da du die 
Messschieber nicht veranlassen kannst synchron zu senden(jedenfalls 
wüsste ich nicht wie), müsstest du ja davon ausgehen, dass mehrere 
Schieber theoretisch zur selben Zeit senden. Das wird zumindest hin und 
wieder passieren, da die clk Frequenzen der einzelnen Schieber nicht 
exakt identisch und schon gar nicht besonders stabil sind.
Also das ohne Interrupt zu beherrschen stelle ich mir schon recht 
schwierig vor.
Hut ab, wenn du dass hinbekommst.
Was das senden der Daten angeht, so wirst du hoffentlich nur senden, 
wenn sich der Wert eines Messschiebers geändert hat.
Wenn du unbedingt ohne IR arbeiten musst/willst, würde ich das Konzept 
ein PIC, ein Messschieber sicher bevorzugen.

Aber he, probiere es aus, da lernt man am meisten bei.

[Reiner W. (reiner_w)]

Michael B. schrieb:
> Das simultan auswerten musste 150ns pro Bit
> erfordern.

Wie hast du da gerechnet ?

[Wicki W. (wicki)]

Reiner W. schrieb:
> Also das ohne Interrupt zu beherrschen stelle ich mir schon recht
> schwierig vor.

Ist einfacher als mit IR.
Ich schaue nach, ob eine Leitung laenger als x-uSec LOW ist.
Ist sie es, dann ist sie in einer Telegrammpause und ich warte y-uSec
auf den Start der Telegramms. Kommt es nicht, nehme ich die naechste 
Leitung.
Daher sollte er mit mehreren Schiebern schneller werden, als wenn ich
mit einem einzelnen sechs simuliere.

> Was das senden der Daten angeht, so wirst du hoffentlich nur senden,
> wenn sich der Wert eines Messschiebers geändert hat.

Coole Idee ;-)
Das Senden dauert zwar nur 3-4ms pro Schieber-Telegramm aber da ist
tatsaechlich Optimierungspotenzial....


> Wenn du unbedingt ohne IR arbeiten musst/willst, würde ich das Konzept
> ein PIC, ein Messschieber sicher bevorzugen.

Fuers Senden der Daten, dafuer koennte eine IR-Routine was bringen.
Dann haette ich die 4 ms auch noch zum Schieberdaten lesen zur
Verfuegung.

> Aber he, probiere es aus, da lernt man am meisten bei.

jau - schaun wir mal.