Thanks for the the concise video! Are you able to click 'next' to add the device at the address detected (10.1.1.11)? Is it possible that there is a conflict at this IP address? Is the device in configuration mode?
here is the manual for the gpib enet since we are back on the gpib side of things:
1.Yes, I can click "next" and the device is added but "Configure" is not working.
See the attached video.
2. How is GPIB_USB coming along for VISA64 under RHEL Linux?
(I know that NI was trying to accommodate some issues related to USB licensing.)
having tried 14.5 version (beta release) for interfacing ENET RS232/ETH devices. It works well on 64-bit machines (SL6)
I also would like to bump this.
Running CentOS 64 Bit and also would like to get pyVISA working.
But reading this threads probably that will not happend until I handed in my theisis in two month...
Or is maybe possible to hack something to get it working?
@danolo where did you found this beta version? Can I get it?
NI-VISA 15.0 will officially support 64-bit user-mode on Linux. It will be available as part of the NIWeek 2015 Driver DVD in August.
NI-VISA 15.0 adds support for 64-bit Linux applications.
NI Modular Instruments Application Software Get with your fellow OS users
[ Linux ] [ macOS ]
Principal Software Engineer :: Modular Instruments Application Software
Senior Software Engineer :: Multifunction Instruments Applications Group (until May 2018)
Software Engineer :: Measurements RLP Group (until Mar 2014)
Applications Engineer :: High Speed Product Group (until Sep 2008)
I'm curious, is there any chance the driver library stacks (e.g., libvisa.so and related) will become available as a 64bit version in the foreseeable future?
A clean engineering approach would be just write proper IIO drivers.
Takes about 4..8 man-weeks per device type (yes, I'm doing those things).
IIO is the standard Linux subsystem for those kind of devices - no reason for having a separate fat proprietary stack (which also needs to rewrite applications just for using some particular hardware), that eats up hundreds of megabytes, when the standard infrastructure already can handle everything.
Unfortunately, NI still refuses to tell us how to use their expensive hardware, so we can't use their products. Well, then we just don't buy them, period. (I've already personally killed a >10 Mio $ deal for exactly that reason).
I had numerious conversations (including calls) on that issue for the cRIOs. They don't hand out any specs, so we can't develop drivers. Therefore my client had to drop NI from the vendor list and so doesn't spend millions there.
Our 488.2 driver cannot currently support USB GPIB devices on certain Linux kernels due to some changes in the licensing for the underlying USB driver.
Yes, those things happen, if some hw vendor refuses to tell us how to use (talk to) their devices and doesn't want to play by the rules. The Linux USB subsystem is gpl-only. I really wish, the whole kernel would be that way.
This seems to match what you're experiencing except that I would expect you to be able to install the software and use the GPIB-USB device on the older kernel.
Asking users to install an ancient kernel is just insane. (and in many cases doesn't even work).
By the way, very interesting terminology: "wizards" ... magic.
Something really secret is happening somehow, only the initiate high-grade priests and magicians have an idea on whats going on here. The merely mortals fully depend on their mercy.
Quite the opposite of structured engineering or scientific method. But a pretty good description for the situation with proprietary drivers.
Now the interesting question: how can engineers and scientists put all their cards on magic ? Can anybody solve that contradiction ?