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
After looking at it a bit more in-depth, I have to concur that the design is somewhat awkward. Both the TCP and RTU sync clients internally wrap around a tokio runtime that is always blocked on any call to the sync context, but under the hood everything in this crate uses the async Modbus engine.
From what I can tell your example should run just fine... all calls that require a runtime should be piped through one, though one thing I found peculiar is a call to Serial::from_path, which eventually resolves to a default tokio-net::util::PollEvented that has not been registered with a reactor. However, it may require one in order to handle the later read_input_registers call here.
We have a very similar sync RTU example in #72 (and #76), but I haven't run it against any device so far. The above issue may be alleviated in the newer version of tokio-serial that is being used alongside the tokio v1 upgrades - someone may want to check that sync example against an actual machine, though.
With the async rtu client under windows I had massive
Permission denied
issues (A separate issue follows).Now I try to get the sync rtu part up and running and stumbled upon this one:
thread 'main' panicked at 'there is no reactor running, must be called from the context of Tokio runtime'
Here is my example
Does the "sync" rtu part differ from the sync tcp one? The tcp example looks for me really sync without a runtime I mean.
The text was updated successfully, but these errors were encountered: