Hallo Leute
bin gerade dabei einen AD-Wandler von conrad(vielleicht kennt den einer) über LabVIEW über seriell anzusprechen hängen schon ewig dran
. Dabei sollen verschiedene Kanäle angesprochen und spannungswerte zurück geben werden. Dabei werden nur die rts, dtr und cts benutzt. Über die cts-leitung sollen die daten ankommen.
Nun habe ich das problem das ich die daten über cts leitung nicht gescheit in spannungswerte umrechnen kann.
Ich habe es mit einer for schleife, case, sequenz struktur versucht damit die 0 und 1 nacheinander abgefragt werden, aber es hat garkeinen einfluß.
wie kann ich es machen das der proberty node meine cts leitung abfragt, nach einer bestimmten zeit oder wenn ein wert ankommt?
muss dazu sagen das ich neu bin in LabVIEW
' schrieb:Hallo Leute
bin gerade dabei einen AD-Wandler von conrad(vielleicht kennt den einer) über LabVIEW über seriell anzusprechen hängen schon ewig dran . Dabei sollen verschiedene Kanäle angesprochen und spannungswerte zurück geben werden. Dabei werden nur die rts, dtr und cts benutzt. Über die cts-leitung sollen die daten ankommen.
Nun habe ich das problem das ich die daten über cts leitung nicht gescheit in spannungswerte umrechnen kann.
Ich habe es mit einer for schleife, case, sequenz struktur versucht damit die 0 und 1 nacheinander abgefragt werden, aber es hat garkeinen einfluß.
wie kann ich es machen das der proberty node meine cts leitung abfragt, nach einer bestimmten zeit oder wenn ein wert ankommt?
muss dazu sagen das ich neu bin in LabVIEW
Hi,
denke mal das es sich da um eine serielle Daten übertragung handelt, denn ein 3bit-ADC hätte ja nicht viel sinn..
Dabei wäre es wohl das beste den Status von CTS in einer Schleife mit festem Takt abzufragen, und dann das Ergbnis nach 8 (gehe mal von einem 8Bit-ADC aus) Durchläufen umzurechnen.
Schau doch mal in die Beispiele ob sich Dazu vielleicht was findet.
Gruß, Rob
Ich hab' jetzt hier gerade mal wieder kein LV, sodass ich nicht ankucken kann, was du programmiert hast. Ich würde aber folgendes sagen.
' schrieb:Dabei werden nur die rts, dtr und cts benutzt. Über die cts-leitung sollen die daten ankommen.
Ich würde sagen, hierbei handelt es sich um eine SPI Schnittstelle - o.ä. Du taktest die DTR-Leitung und empfängst über CTS Daten. Über RTS könntest du Daten senden.
Nur alleine durch Abfragen der CTS-Leitung kannst du keine Daten übertragen. Irgendwer muss einen Takt machen. Wie sonst (außer z.B. Manchestercode) könntest du lauter gleiche Bits übertragen? Steht in der Beschreibung etwas von einem Taktsignal an DTR?
' schrieb:Ich hab' jetzt hier gerade mal wieder kein LV, sodass ich nicht ankucken kann, was du programmiert hast. Ich würde aber folgendes sagen.
Ich würde sagen, hierbei handelt es sich um eine SPI Schnittstelle - o.ä. Du taktest die DTR-Leitung und empfängst über CTS Daten. Über RTS könntest du Daten senden.
Nur alleine durch Abfragen der CTS-Leitung kannst du keine Daten übertragen. Irgendwer muss einen Takt machen. Wie sonst (außer z.B. Manchestercode) könntest du lauter gleiche Bits übertragen? Steht in der Beschreibung etwas von einem Taktsignal an DTR?
Richtig, an die Variante I2C oder SPI hab ich gar nicht gedacht..
Was mich nur wundert ist das dass ganze über die RS232 gemacht wird und nicht über den Parallelport, wo man sich den Pegelwandler sparen könnte.
Gruß, Rob
' schrieb:Was mich nur wundert ist das dass ganze über die RS232 gemacht wird und nicht über den Parallelport, wo man sich den Pegelwandler sparen könnte.
Jede Menge Gründe: Die RS232 ist kurzschlussfest und EMV-fester. Ist Parallel nicht noch outer als RS232? In VB etc. gibt es Komponenten für RS232, für Parallel hab' ich noch keine gesehen. Auch in der Win32-API/SDK scheint es für das direkte Ansteuern des Parallelportes nichts zu geben (was aber nicht heißt, dass es jede Menge DLLs gibt, die aber eigentlich nur einen Port-IO auf beliebige Adressen unter Win32 erlauben).
' schrieb:Hi,
denke mal das es sich da um eine serielle Daten übertragung handelt, denn ein 3bit-ADC hätte ja nicht viel sinn..
Dabei wäre es wohl das beste den Status von CTS in einer Schleife mit festem Takt abzufragen, und dann das Ergbnis nach 8 (gehe mal von einem 8Bit-ADC aus) Durchläufen umzurechnen.
Schau doch mal in die Beispiele ob sich Dazu vielleicht was findet.
Gruß, Rob
' schrieb:Hi,
denke mal das es sich da um eine serielle Daten übertragung handelt, denn ein 3bit-ADC hätte ja nicht viel sinn..
Dabei wäre es wohl das beste den Status von CTS in einer Schleife mit festem Takt abzufragen, und dann das Ergbnis nach 8 (gehe mal von einem 8Bit-ADC aus) Durchläufen umzurechnen.
Schau doch mal in die Beispiele ob sich Dazu vielleicht was findet.
Gruß, Rob
Hi
ja genau das ist das Problem. Wie mache ich das denn in LabVIEW, dass man den Status von CTS in einem festen Takt abfrägt. Die Wile und for schleifen haben komischer Weise keinen Einfluß.
Oder gibt es einen anderen Weg den CTS Status abzufragen als über den proberty node.
In der Anleitung vom AD Wandler gibt es ein demo-programm in Turbo basic.
Im Prinzip versuche ich das in LabVIEW umzusetzen.
' schrieb:Hi
ja genau das ist das Problem. Wie mache ich das denn in LabVIEW, dass man den Status von CTS in einem festen Takt abfrägt. Die Wile und for schleifen haben komischer Weise keinen Einfluß.
Oder gibt es einen anderen Weg den CTS Status abzufragen als über den proberty node.
In der Anleitung vom AD Wandler gibt es ein demo-programm in Turbo basic.
Im Prinzip versuche ich das in LabVIEW umzusetzen.
Hi,
So hab ich das mit für meine Taktausgabe auf den Parallelport gelöst.
Die Boolsche Variable 0_det (rechts oben) ist ein Steuereingang des Parallelport, über welchem ich ein Signal auslesen könnte.
das ganze Vi ist aber eher dazu da die Drehrichtung und den Takt auszugeben.
Gruß, Rob