RS232 Schnittstelle mit C über Visual Studio Bitweise auslesen

Tim schrieb:
> Ich habe ein ähnliches Projekt bereits vor einem halben Jahr auf
> einer
> Messe gesehen. Lösbar ist es auf jeden Fall

Sicher dass hier genau die Serial-Pins so eingelesen wurden?

Das ganze geht IIRC nur mit 2 Pins (RX und CTS) und nennt sich 
"Bit-Banging". Das ist aber eher ein Hack mit begrenzter Flexibilität 
und Geschwindigkeit.

Wenn du sowieso einen USB-Adapter nutzen willst (da keine echte serielle 
Schnittstelle vorhanden), kannst du direkt einen nehmen, der genau dafür 
gedacht ist. Da gibt es diverse, wie z.B.:

https://www.codemercs.com/de/io
https://www.microchip.com/wwwproducts/en/MCP2221A
Eigenbau, siehe z.B. mein USB-Tutorial mit STM32

Wie immer wäre es gut zu wissen was du genau vorhast.

Tim schrieb:
> Mein Ziel ist es abzufragen, ob ein Signal bzw mehrere Signale anliegen.

Wie schnell ändert sich dieses Signal? Muss das Abfragen in definierten 
Zeitabständen erfolgen? Wie groß darf die Reaktionszeit sein?

Tim schrieb:
> Bei USB habe ich nur mit den Protokollen etwas bedenken.
Dafür bieten die Hersteller der genannten Adapter entsprechende 
Bibliotheken.

Tim schrieb:
> Mein einziges großes Problem ist hierbei nur, dass ich nicht weis wie
> ich die einzelnen Inputleitungen des RS232 in Visual Studio abfragen
> kann.
Weil das eigentlich von RS-232 nicht vorgesehen ist, gibt es auch noch 
mehr Probleme dazwischen.

Die Handshakeleitungen der seriellen Schnittstelle lassen sich mit der 
Win32-API-Funktion GetCommModemStatus einlesen.

Beispiel:

1

   DWORD dwModemStatus;

2

   BOOL  fCTS, fDSR, fRING, fRLSD;

3

4

   if (!GetCommModemStatus(hComm, &dwModemStatus))

5

      return; // fehlerbehandlung?

6

7

   fCTS = MS_CTS_ON & dwModemStatus;

8

   fDSR = MS_DSR_ON & dwModemStatus;

9

   fRING = MS_RING_ON & dwModemStatus;

10

   fRLSD = MS_RLSD_ON & dwModemStatus;

hComm ist hier ein Handle auf eine mit CreateFile korrekt geöffnete 
Schnittstelle.

"RLSD" ist eine alternative Bezeichnung für DCD.

https://docs.microsoft.com/en-us/windows/desktop/api/winbase/nf-winbase-getcommmodemstatus

Tim schrieb:
> Bei der Abfrage reicht eine Tastrate von einer halben Sekunde.

Ok, das ist nicht sehr kritisch.

Tim schrieb:
> - Steht ein Not-Halt an oder
Hoffentlich wird die Sicherheit nicht beeinträchtigt, wenn diese 
Bastelei nicht funktioniert :-)

Tim schrieb:
> Wenn ich es mit einer USB Leitung versuchen würde müsste ich auch diese
> auftrennen was Softwaretechnisch glaube ich dann schwer zu lösen ist.
Die USB-Leitung musst du nicht auftrennen. An die USB-Leitung schließt 
du statt des USB-Seriell-Adapters einen USB-GPIO-Adapter an, der 
Eingänge hat, an welche du deine Signale anschließen kannst. Über die 
Herstellerbibliothek lässt sich das dann komfortabel abfragen.

Tim schrieb:
> Mit Visual Basic ist das aber glaube ich möglich
Es ist auch in C möglich (rufus hat es gezeigt), aber nicht alles was 
möglich ist, ist auch eine saubere Lösung... Da sowieso ein Adapter 
erforderlich ist, kannst du auch direkt einen Adapter nehmen, der 
genau dafür gemacht ist!

Hey Tim,

also wenn du keine "richtige" RS232 hast und auf USB Adapter ausweichen 
muss, dann müsstest du darauf achten, dass dieser auch alle 
Steuerleitungen unterstützt, einige USB-RS232 Adapter sind abgespeckt.

Aber die Idee mit dem Missbrauch der Steuerleitungen der RS232, naja...
ich würds so nicht machen.

Was hälst du von dieser Idee (da du ja C kannst):
Nimm dir z.B. ein kleinen µC (ATtiny) definiere dort bis zu 8 Eingänge 
und sende jede 500ms ein Byte (in dem die 8 Eingänge als Bits hinterlegt 
sind) über die UART an den PC und dort kannst du dieses direkt per 
Serieller Schnittstelle auslesen und interpretieren.
Da kannst dann RS232 oder USB-Adapter nehmen, egal.

Dies wäre zumindest eine saubere Lösung bei der du dich auch in der 
Software nicht verbiegen müsstest.

Gruß

Adam P. schrieb:
> Nimm dir z.B. ein kleinen µC (ATtiny)

Oder direkt einen Controller mit USB, wodurch man sich den Adapter und 
den Ärger mit dessen Treiber spart.
Von wegen Schaltschrank... Haben SPS nicht sowieso eine Möglichkeit 
Signale an den PC zu schicken?

Niklas G. schrieb:
> Da sowieso ein Adapter erforderlich ist, kannst du auch direkt einen
> Adapter nehmen, der genau dafür gemacht ist!

Für den bräuchte man aber wiederum passende Treiber. Das ganze auf eine 
serielle Schnittstelle zu abstrahieren, und diese mit der dafür 
vorgesehenen API anzusteuern, bietet die Flexibilität, ohne Änderung des 
Programmes sowohl mit "echten" seriellen Schnittstellen als auch mit 
USB-UART-Bridges oder gegebenenfalls anderen Lösungen 
(Ethernet-Device-Server) zu arbeiten.

Die Win32-API bietet neben dem einfachen Pollen der Handshakeleitungen 
auch die Möglichkeit, Events beim Ändern der Handshakeleitungen 
auszulösen, das geschieht mit den Funktionen SetCommMask und 
WaitCommEvent.

https://docs.microsoft.com/en-us/windows/desktop/DevIO/monitoring-communications-events

Handshakeleitungen zum Transportieren von Statusinformation zu 
"missbrauchen" ist durchaus üblich; sehr lange Zeit wurde beispielsweise 
der Zustand von USVn auf diese Art und Weise transportiert (und von 
einem bis einschließlich XP/2003 zu Windows gehörenden Systemdienst 
ausgewertet).

Niklas G. schrieb:
> Oder direkt einen Controller mit USB

Ja gut, aber je nachdem welche Kenntnisse vorhanden sind, kann sich die 
Implementierung von USB nicht ganz so leicht gestallten wie eine UART.

Und die meisten UART-USB Seriell-Adapter stellen gar keine 
Treiberprobleme dar. (z.B. FTDI TTL-232R-3v3) hatte damit noch nie 
Probleme und selbst die Sticks von Digitus.

Aber natürlich, ein µC mit USB wäre natürlich die sauberste Lösung.
(Vorrausgesetzt man verwendet eine USB-Klasse die keine zusätzlichen 
Treiber benötigt)

Tim schrieb:
> eine kostengünstigere Lösung zu erzielen

Ein µC der Größenortnung von ATtiny ist kostengünstig.

Tim schrieb:
> Diese Lösung soll lediglich eine
> Leitung benötigen.Vorgeschlagen wurde mir hier gerade die RS232.

Mit einer Leitung meinst du: Eine Leitung mit mehreren Adern, oder?


Aber dann hast du doch schon deine Lösung.
Klar ein Pi ist nicht wirklich kostengünstig, aber eine kleine Platine 
mit nem µC, kannst sogar dort direkt ein FTDI IC verbauen und dann 
brauchst nur noch ein USB Kabel an deine Schaltung anschliessen.

Serienproduktion involviert vermutlich Kunden, welche Probleme mit der 
Konfiguration/Auswahl des korrekten COM-Ports haben könnten, was wieder 
neuen Ärger für den Support bedeuten könnte... Besonders wenn noch 
andere Industrie(?)-Geräte auf RS232-Basis angeschlossen sind.

Gute USB-RS232-Adapter (FTDI) sind auch nicht so ganz billig, aber 
vermutlich einfach aufgrund des Produktionsvolumens doch etwas billiger 
als USB-GPIO-Adapter oder gar Eigenbau-Lösungen mit uC. Eine solche 
würde dann auch eine eigene USB-VID erfordern, was leider auch nicht 
ganz billig ist, aber immerhin nur Einmal-Kosten. Dafür ist das am 
Flexibelsten und man könnte später leicht noch mehr Funktionen 
nachrüsten. Der kleinste IO-Warrior (16 Pins) kostet z.B. ca 8€ ab 100 
Stück...

Wie ist denn der Preisrahmen? Hat der Schaltschrank wirklich überhaupt 
keinen uC/SPS/sonstige programmierbare Logik die man erweitern könnte?

Oder du sparst dir das mit der Neuentwicklung und kaufst etwas fertiges 
und schreibst nur noch die paar Zeilen Code:

https://www.ebay.de/itm/MINI-USB-Nano-V3-0-ATmega328P-CH340G-5V-16M-Micro-controller-board-for-ArduinoAB/163278927025?_trkparms=aid%3D555018%26algo%3DPL.SIM%26ao%3D2%26asc%3D20160908110712%26meid%3D31a97a6c53f2473ba54560270f036942%26pid%3D100677%26rk%3D1%26rkt%3D26%26sd%3D183161243119%26itm%3D163278927025&_trksid=p2385738.c100677.m4598

Die gibts auch mit originalem FTDI Chip.

Adam P. schrieb:
> Ein µC der Größenortnung von ATtiny ist kostengünstig.

Braucht aber eben noch den USB-Adapter!

Adam P. schrieb:
> Ebay-Artikel Nr. 163278927025

Möchte man sowas wirklich im Industrie-Umfeld professionell verkaufen...

Tim schrieb:
> Preisrahmen direkt gibt es keinen.

Dann nimm den IO-Warrior o.ä. Das ist eine günstige (aber wohl nicht die 
allergünstigste) Lösung, die sowohl für dich als auch für den Kunden am 
Einfachsten sein dürfte.

Tim schrieb:
> Daher sollen die Analogsignale der Schütze und Klemmen
> durch eben dieses nun neue System abgefragt werden.
Analogsignale? Sollen Spannungen gemessen werden?

Wenn es billigst aber einigermaßen ordentlich sein soll (dafür etwas 
mehr Aufwand), kaufe man sich so etwas wie das (ebay: 401603371806), 
programmiere eine entsprechende USB-Firmware darauf (Beispiele und 
Bibliotheken sind vorhanden) und steuere das über libusb oder WinUSB aus 
Visual Studio aus an. Nur mit der VID muss man sich was überlegen.

Niklas G. schrieb:
> Möchte man sowas wirklich im Industrie-Umfeld professionell verkaufen...

Eher weniger, war nur ein Bsp. bzgl. "Kostengünstig", aber anscheinend 
sind die Kosten nun doch egal.

Niklas G. schrieb:
> kaufe man sich so etwas wie das (ebay: 401603371806)

Klar das wäre besser, aber wie du sagtest, VID Problem, hätte er beim 
FTDI nicht...ABER

Wenn er eine eigene Schaltung entwerfen würde, um diese zu verkaufen, 
dann würde ja noch Zulassung, EMV usw. dazukommen.

Da muss man echt abägen, was sich lohnt bzw. ausreichend ist.

Tim schrieb:
> Danke der sieht klasse aus. Hoffe mit der Software komme ich zurecht,
> wenn
> ja ist das eine wesentlich einfachere Lösung.

Auf einmal gehen auch Lösungen die sogar teurer als der Raspberry-Pi 
sind? ? Ähnlich einfache aber viel billigere wurden ja genannt, aber 
eben nicht isoliert.

Cppbert schrieb:
> naja 40 EUR plus Library mit einer Handvoll Funktionen ist schon näher
> an einer Lösung als der Raspberry - wenn er jetzt nicht so Erfahren ist

Eine R-PI Lösung hat Tim nach eigener Aussage ja schon, die aber zu 
teuer sei - obwohl billiger als der OptoIn, dessen Hauptfeature der 
isolierten Eingänge ja gar nicht gefordert war. Der R-PI hat ja direkt 
GPIOs und braucht somit gar keinen zusätzlichen Adapter. Alles etwas 
mysteriös.

There is a ready made ASCII terminal available in Windows (DOS) console.
I think this is much easier then all the .NET hassle.
Just read or write your ASCII file to/from COM5.


I use USB-serialcoverter that has COM5.

Run cmd.exe then type "mode /?".

(Make sure the converter is on, otherwise "Serial port:" will be 
missing, you only get CON: then.)
Result:
========================================================================

C:\Users\geerth>mode /?
Configures system devices.

Serial port:       MODE COMm[:] [BAUD=b] [PARITY=p] [DATA=d] [STOP=s]
                                [to=on|off] [xon=on|off] [odsr=on|off]
                                [octs=on|off] [dtr=on|off|hs]
                                [rts=on|off|hs|tg] [idsr=on|off]

Device Status:     MODE [device] [/STATUS]

Redirect printing: MODE LPTn[:]=COMm[:]

Select code page:  MODE CON[:] CP SELECT=yyy

Code page status:  MODE CON[:] CP [/STATUS]

Display mode:      MODE CON[:] [COLS=c] [LINES=n]

Typematic rate:    MODE CON[:] [RATE=r DELAY=d]

========================================================================
This is the default setting of COM5:

C:\Users\geerth>mode COM5

Status for device COM5:
-----------------------
    Baud:            1200
    Parity:          None
    Data Bits:       7
    Stop Bits:       1
    Timeout:         OFF
    XON/XOFF:        OFF
    CTS handshaking: OFF
    DSR handshaking: OFF
    DSR sensitivity: OFF
    DTR circuit:     ON
    RTS circuit:     ON


C:\Users\geerth>

========================================================================

BTW: I recommand YAT terminal for experiments.
https://sourceforge.net/projects/y-a-terminal/

You can also run YAT in cmd.exe. Get help instructions this way:
C:\Users\geerth>"C:\Program Files\YAT\YATConsole.exe" /?