Hi Chris and Dave,
I’m trying to use the python bridge to change variables in MWorks. Is
this intended to work?
I’m attaching a reduced example chopped down from my code. The
callbacks get events as desired, but nothing I do seems to get any
data down to MWorks. The example is untested.
I wanted to touch base to see if I’m missing something about what
version of MWorks I need, etc. This is a nightly from last December,
so something close to 0.4.5. I’m happy to test with any version you
like if it’s a bug that needs to be tracked down.
Thanks!
Mark
Attachment: test1.py (1.25 KB)
Hi Mark,
The short answer: No, that’s not intended to work at present.
The long answer: It looks like all the machinery to make it work is in place. Using the attached experiment and Python bridge script, I’ve confirmed that MWClient receives the variable-update event from the script. However, it doesn’t forward the event to the server, so it’s just dropped.
Since I didn’t write the Python bridge, I don’t know whether it was intended to be strictly one-way, or if two-way communication is planned but not yet implemented. Dave is the person to ask about that.
Chris
Thanks! I appreciate the information.
Dave, I’d like to register my interest in two-way communication; I could certainly use it in the future, but I think I have a way to work around this for now.
Best
Mark
Hey Mark,
I’ll look into this. As Chris says, the infrastructure is all there so it’s just a matter of refreshing my memory, hooking things up and testing.
We also have a server-side conduit plugin that already achieves bi-directional communication (it’s the same idea as the client plugin but, you know, for the server). If this suits your needs, I can give you access to this now (we currently use this to manage communications with a variety of in-house IO devices).
Dave,
Thanks. Yes, I wanted to use it to manage communications with IO devices.
What are the advantages of getting events from the client instead of the server (in other words, why did you start with a Client conduit rather than a Server conduit)? I don’t know enough about MWorks internals to know if there are any limitations to talking to the server.
This is not a big rush for me, I don’t think. Anything that’s on your plate in the next few weeks to months I’m happy to test; whether the Server conduit or a bidir Client conduit.
Thanks,
Mark
The client conduit was meant to facilitate online data analysis (which is why those using it were happy as soon as it supported read-only communication). The server-side conduit was created for cases in my own lab where communications throughput/latency was more important, or where, for a variety of reasons, the communicating process needed to be on the same machine as the server.
I need to move that plugin into a repository of its own (currently it is in a “coxlab_mwcore_plugins” repository with a bunch of other stuff), but I am happy to share it. Give me a day or two.