tsuitoar / visa-rs Goto Github PK

This is related to my comments on #19 but more specific to the functionality of this binding lib to the open source version of VISA.
While trying to run through the example code, I only get: Error: Insufficient location information or the device or resource is not present in the system. when i try to send any resource string into find_res.
I've tried explicit TCPIP0::192.168.0.100::inst0::INSTR, which was used on pyVisa and worked, all way way down to simply ?*. No matter what I type I get the error above. That error seems to come from the VISA library itself as I don't see that string in the code.
Curious if anyone else has had this issue or is it most people use the NI lib?
Thanks!

The VISA library has lots of CompletionCode, currently this crate discards this information and treat them all the same.

This should be improved, but I don't know a Rust style to handle this kind of return value.

There are some operations that are not covered by this crate currently, check NI-VISA API for the operations list.

Besides several variadic functions like viPrintf that is not compatible with Rust, most of them are used for memory operations such as viMemAlloc, viMove, viInx and viOutx.
To be honest, I'm not familiar with these low-level ops. Despite they are easy to wrap since they have simple function types, I'm not sure whether the environment in which these functions are used has Rust compiler and the wrapped version would look a lot like raw FFI functions.

I've been looking for a visa-sys fill for ages! Thankyou!
I've read most of the "book" and would like to start contribute to projects.
How would I go about doing this?

Building in both versions 0.4.0 and 0.5.0 gives the following error on Ubuntu 22.04:

error[E0308]: mismatched types
  --> /home/fbordwell/.cargo/git/checkouts/visa-rs-657bd5cc4c91eb01/a805029/src/flags.rs:12:25
   |
12 |         const NO_LOCK = vs::VI_NO_LOCK;
   |                         ^^^^^^^^^^^^^^ expected `u64`, found `u32`

error[E0308]: mismatched types
  --> /home/fbordwell/.cargo/git/checkouts/visa-rs-657bd5cc4c91eb01/a805029/src/flags.rs:13:32
   |
13 |         const EXCLUSIVE_LOCK = vs::VI_EXCLUSIVE_LOCK;
   |                                ^^^^^^^^^^^^^^^^^^^^^ expected `u64`, found `u32`

error[E0308]: mismatched types
  --> /home/fbordwell/.cargo/git/checkouts/visa-rs-657bd5cc4c91eb01/a805029/src/flags.rs:14:29
   |
14 |         const SHARED_LOCK = vs::VI_SHARED_LOCK;
   |                             ^^^^^^^^^^^^^^^^^^ expected `u64`, found `u32`

error[E0308]: mismatched types
  --> /home/fbordwell/.cargo/git/checkouts/visa-rs-657bd5cc4c91eb01/a805029/src/flags.rs:15:29
   |
15 |         const LOAD_CONFIG = vs::VI_LOAD_CONFIG;
   |                             ^^^^^^^^^^^^^^^^^^ expected `u64`, found `u32`

For more information about this error, try `rustc --explain E0308`.
error: could not compile `visa-rs` due to 4 previous errors

This crate wraps two async operations, async_read and async_write, they rely on Callback added to EventIoCompletion event that VISA is listening to.

There are several aspects that need to be aware of and should be improved:

• Under some circumstances that are unclear, the callback would not be called even the IO is completed, this happens occasionally by running tests in this repo on my machine.
• If there are other callback installed by user, and the callback return SuccessNchain internally to VISA, althought it should not be possible only use safe API provided, not for the unsafe functions. So the SuccessNchain (VI_SUCCESS_NCHAIN) will tell VISA not to invoke other callbacks installed, which will cause a permanent wait.
• The Future contains the ref of the buf passed to these two async functions, so they are not Sync and Send.
  • Seems that it is common for async io to hold reference to buffer

The cause of the first problem is not clear, it might be related with running multiple VISA program synchronously, use cargo t --jobs 1 can usually pass all tests, without it, a function of the tests will not quit sometimes. Another is associated with the Waker mechanism of Rust future system.

They might be solved by adding another Waker that wakes the futures after some time no matter what.
I'm not familiar with low level async programing design and not sure if there are better solutions, any help would be grateful.