Python Serial Port, mehrere Nodes

Matze schrieb:
> Bestenfalls würde ich den doch zum Programmstart öffnen und zum
> Ende schließen.
Warum machst du es dann nicht einfach so?

1

class Sensor:

2

    def __init__(self, com_port_obj):

3

        self.com = com_port_obj

4

5

6

def main():

7

    com_port = serial.Serial(...) # com port oeffnen

8

9

    sensor_1 = Sensor(com_port)

10

    sensor_2 = Sensor(com_port)

11

    sensor_3 = Sensor(com_port)

12

    sensor_4 = Sensor(com_port)

13

14

    # com port schliessen

15

    com_port.close()

16

17

if __name__ == '__main__':

18

    main()

Matze schrieb:
> Wie verhält sich das bei Python?
Was meinst du?
So wie du es in deinem Beispielcode zeigst, wird jedes neue Objekt von 
MeinSensor versuchen den Com-Port zu oeffnen. Ist es jedesmal ein 
anderer Port, ist das kein Problem. Ist es aber immer der selbe Port, 
koennte das vielleicht zu problemen fuehren (Schnittstelle schon 
geoeffnet/blockiert). Erzeuge einfach ein Objekt fuer den Com-Port, und 
gib dieses Com-Port-Objekt in deine Klasse rein. (siehe mein Beispiel).

Matze schrieb:
> Hallo,
>
> ich habe vier gleiche Sensoren die per RS232 an einer COM hängen. Im
> String wird dann jeweils eine entsprechende ID gesendet.

RS232 ist für Punkt-zu-Punkt-Verbindungen gedacht. Es ist kein Bus, und 
IDs gibt es da nicht. Wenn du mehrere TX-Leitungen parallel schaltest, 
schließen sie sich gegenseitig kurz.

Rolf M. schrieb:
> Es ist kein Bus, und IDs gibt es da nicht.
Von Natur aus nicht, das ist Richtig. Aber ein entsprechendes Protokoll 
gibt das her, z.B. ccTalk.

Rolf M. schrieb:
> Wenn du mehrere TX-Leitungen parallel schaltest,
> schließen sie sich gegenseitig kurz.
Auch hier als Beispiel: ccTalk
Alle RX und TX liegen auf einer einzigen Leitung, und das funktioniert 
ganz wunderbar. Praktisch ein "One-Wire-Bus" ueber RS232.

1

master        slave 1       slave 2       slave n

2

 |  |          |  |          |  |          |  |

3

rx  tx        rx  tx        rx  tx        rx  tx

4

 |  |          |  |          |  |          |  |

5

 +--+----------+--+----------+--+----...---+--+

https://en.wikipedia.org/wiki/CcTalk

1

The protocol uses an asynchronous transfer of character frames in a

2

similar manner to RS232. The main difference is that it uses a single

3

two-way communication data line for half-duplex communication rather

4

than separate transmit and receives lines. It operates at TTL voltages

5

and is ‘multi-drop’ i.e. peripherals can be connected to a common bus

6

and are logically separated by a device address. Each peripheral on the

7

ccTalk bus must have a unique address.

Ja, wir wissen nicht was die Sensoren fuer ein Protokoll sprechen. Aber 
prinzipiell ist das, was der TO da schreibt, weder unmoeglich noch 
ungewoehnlich, sondern wird genau so in der Industrie gemacht.

Kaj G. schrieb:
>[...]
> Ja, wir wissen nicht was die Sensoren fuer ein Protokoll sprechen. Aber
> prinzipiell ist das, was der TO da schreibt, weder unmoeglich noch
> ungewoehnlich, sondern wird genau so in der Industrie gemacht.

Moinsen,
unwidersprochen, aber das setzt ein entsprechendes Protokoll bei Sendern 
und Empfängern voraus.
Nichts führt aber darum herum, eine einzige Empfängerinstanz auf dem 
(einzigen) seriellen Port zu haben, die die Empfangstelegramme 
auseinanderflöht und den verschiedenen Endabnehmern zuweist. Es ist 
nicht möglich (und obendrein auch nicht sinnvoll) einen seriellen Port 
mehrfach von unabhängigen Instanzen zu öffnen und zu nutzen.

Es grüßt
Baku

Kaj G. schrieb:
> Alle RX und TX liegen auf einer einzigen Leitung, und das funktioniert
> ganz wunderbar. Praktisch ein "One-Wire-Bus" ueber RS232.

Naja, aber das:

Kaj G. schrieb:
> It operates at TTL voltages

ist eigentlich auch kein RS232. Wenn man mit einem anderen Physical 
Layer arbeitet und ein passendes Protokoll draufsetzt, geht das 
natürlich. Ich hatte das Ursprungsposting aber so verstanden, dass hier 
eine echte RS232 in einem PC verwendet wird.

self.com.write(lesekommando)
return_value = self.com.read

wird nicht funktionieren.

Dazwischen muss eine Pause rein. Das Betriebsystem braucht Zeit zum 
Senden, dann muss empfangen werden und je nach Baudrate kann das lange 
dauern. Aber es dauert auch bei hoher Baudrate länger als im 
Pythonskript die zweite Zeile ausgeführt wird. Du wirst also nichts 
lesen oder wenn du zyklisch liest, dann die Daten vom vorherigen Zyklus.

Gustl B. schrieb:
> Dazwischen muss eine Pause rein. Das Betriebsystem braucht Zeit zum
> Senden, dann muss empfangen werden und je nach Baudrate kann das lange
> dauern. Aber es dauert auch bei hoher Baudrate länger als im
> Pythonskript die zweite Zeile ausgeführt wird. Du wirst also nichts
> lesen oder wenn du zyklisch liest, dann die Daten vom vorherigen Zyklus.
Schwachsinn. Lies mal bitte die Doku bevor du hier so einen Unfug 
verbreitest.

https://pyserial.readthedocs.io/en/latest/pyserial_api.html#serial.Serial.read

1

Read size bytes from the serial port. If a timeout is set it may return

2

less characters as requested. With no timeout it will block until the

3

requested number of bytes is read.

OK, sorry, stimmt. Daran hatte ich nicht gedacht. Ich verwende immer 
timeout=0 und muss dann eben manuell warten. Weil ich von einem 
Datenstrom lese der mal mehr mal weniger schickt kann ich auch nicht fix 
auf eine feste Größe warten.