Replies: 1 comment
-
This could definitely be it. It could also be that all/many those devices have the 120R termination resistance which when all put together causes the RS485 bus to overload. Can you post some more details about the kind of failure you are encountering?
This unfortunately will not work by design; you'd have to mimic the "bus" nature of RS485 bus in software. ie., each write from the CP has to be duplicated to every PD on the network as would be the case on the bus. You can do this by creating a process that reads from the USB-RS485 adapter and then creates virtual serial ports over unix domain socket (or some other method) and then pass that to the PD threads. I do something similar in the testing scripts but nothing you can directly use. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
I have an OSDP network with a CP and upto 40 PDs attached. I've noticed that whilst a PD will communicate just fine when there are less than 10~20 devices connected, as the number of PDs increases the reliability of my PD deteriorates (I suspect memory issues and the overhead of checking and discarding the sheer volume of messages not destined for PD).
To aid in my debugging of the PD, I would like to emulate
X
many PDs from a single Python script, talking via a USB->RS485 adaptor. This will generate a sufficiently 'chatty' bus that I can use to debug with.I've made an attempt to spawn a single Serial connection, that I then pass to each PD which is constructed as per example code. Each PD is then passed to a new thread which runs a loop. From what I can see though, as the first PD reads buffered data from the CP it will either act on the packet or discard the packet, rather than leaving that payload available for the next PD to attempt to use / acknowledge.
Is there an example for how multiple PDs can be registered to the same serial connection?
Beta Was this translation helpful? Give feedback.
All reactions