You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When multiple druids are open connected to the same port there is a race condition which makes it ambiguous where the returned values will appear. This is very confusing for new users when they don't realize they have druid open in a different window.
I've tried to simply set the exclusive = True param in the serial.Serial call in crowlib, but this is even more confusing. The <disconnected> message never appears in druid, and I'm not sure if it's possible to check why the serial connection failed. If we can test if the port exists but is locked by a different process, then it would be great to print a message "another instance of druid is already open".
The text was updated successfully, but these errors were encountered:
I think what we'd want is exclusive access to a single crow, not a necessarily a single instance of druid (I can have two crows and might want to connect to both of them with a separate druid instance for example).
tldr; This issue for me is about the confusing situation where 2 instances of druid connect to the same serial port but only one of them receives responses.
// Below is some ramblings about the difficulties of supporting multiple simultaneous crows.
Having 2 crows that you want to speak to with independent druid sessions seems like an incredibly niche use-case to me. I think this is a context where we can be opinionated about how this should be done, rather than make everything possible. We should choose one of the following (or others?):
Druid can only speak to a single crow, repatch usb cable to speak to another
Druid can only speak to a single crow, but can forward messages via i2c
One instance of druid that can talk to multiple devices
A separate instance of druid per device
My inclination is that there's a bunch of way-more mainstream features we can add than worrying about the implementation of 3 or 4 above. In particular, both of those options require adding user-controls for choosing serial ports / devices which feels like it will be even more confusing for novice users.
trentgill
changed the title
Only allow a single instance of druid to open at once
Only allow a single instance of druid to attach to a given crow
Oct 22, 2019
witnessed a real-world pre-show debug that eventually found this as the culprit. on macos. symptom was everything worked, but ^^connected was being printed over and over
When multiple druids are open connected to the same port there is a race condition which makes it ambiguous where the returned values will appear. This is very confusing for new users when they don't realize they have druid open in a different window.
I've tried to simply set the
exclusive = True
param in theserial.Serial
call in crowlib, but this is even more confusing. The<disconnected>
message never appears in druid, and I'm not sure if it's possible to check why the serial connection failed. If we can test if the port exists but is locked by a different process, then it would be great to print a message "another instance of druid is already open".The text was updated successfully, but these errors were encountered: