Linux Users

cancel
Showing results for 
Search instead for 
Did you mean: 

GPIB-HS-USB Support for Newer Linux Kernels

+1 the previous remarks.  I would be very keen to see NI's GPIB updated to the latest 3.x kernels currently in use.

Peter

0 Kudos
Message 11 of 20
(2,052 Views)

+1 from me.

Is there any news concering this issue. Any hope at all it will be solved? In the near future?

If not I think it would be just fair to include this issue in your product pages, because there you still claim to support Linux with the GPIB USB HS.

But support for kernel version that old is not really a support - think of using a new computer for measurment - that will be hardly possible with that old Linux driver.

I know this is a licensing issue that wasn't caused by NI - but you still have the choice of updating your license for this module to GPL

Well anyway. An update to this issue and I think a good FAQ hint about it would be really nice - or did I missed that?

0 Kudos
Message 12 of 20
(2,052 Views)

Would you please either move to libusb or support the opensource driver in LabView and other products?

Shouldn't be to hard to build this.

http://sourceforge.net/projects/linux-gpib/

0 Kudos
Message 13 of 20
(2,052 Views)

I think it should be fairly easy to make this work if you use VISA IO. This project supports a VISA driver interface that should be accessible from LabVIEW without many hassles, since VISA is designed to be a plugable interface. And OpenVISA claims to support the linux-gpib driver for interfacing to GPIB devices.

Accessing GPIB through the old GPIB API in LabVIEW is more than legacy technology and almost no intstrument driver out there does do that nowadays.

Rolf Kalbermatter
My Blog
0 Kudos
Message 14 of 20
(2,052 Views)

any update on this, would really like to get scope working with linux

0 Kudos
Message 15 of 20
(2,052 Views)

Thank you all for providing valuable input as we are always trying to improve our products and appreciate customer feedback. There is an ever increasing portion of the market that desires suppoprt for GPIB-USB-HS(+) on the latest Linux kernels. Unfortunately, the demand is not high enough to justify an investment at this time. We will continue to re-evaluate the stiuation as demand continues to rise.

Jeff L
National Instruments
0 Kudos
Message 16 of 20
(2,052 Views)

... which is why our company turned to another vendor recently regarding instrument control.

0 Kudos
Message 17 of 20
(2,052 Views)

@Bumba wrote:

 

I know this is a licensing issue that wasn't caused by NI

 

It indeed was caused by NI. They just refuse to play by the rules - technically and socially.

Obviously they just dont want us to buy their products. But still they're making false claims. 

Linux Embedded / Kernel Hacker / BSP / Driver development / Systems engineering
0 Kudos
Message 18 of 20
(1,905 Views)

Unfortunately, the demand is not high enough to justify an investment at this time. We will continue to re-evaluate the stiuation as demand continues to rise.


Not high enough for investing few man-weeks (maybe 15k$) ?

 

Can't speak for the GPIB stuff, but for the cRIOs lost >10 Mio$ by not providing usable free drivers and not even publishing specs. I had numerous conversations (including calls) w/ them, but it was just a waste of time. Finally, my client (a big electrical company) dropped NI from the vendor list.

 

Linux Embedded / Kernel Hacker / BSP / Driver development / Systems engineering
0 Kudos
Message 19 of 20
(1,448 Views)

Changing NI-KAL license to GPL is not possible at the moment. Our main driver is not GPL. Sorry..

Then why not just changing the driver license (and publish the full source) or at least publish proper specs ?

Proprietary Linux kernel drivers are always extremly painful and expensive, and just russian roulette.

 

As long as NI is so hostile against FOSS, they'll be under fire. My recent full disclosure (which interestingly correlated with a huge stock slump of amost 10%) was just a tiny piece of that. And we're currently in process of building up a direct competition with completely free specs and drivers by day one.

 

We can still support this in the future by leveraging libusb, which is the sanctioned way in Linux to do closed-source USB..

Fine, that would make reverse-engineering a lot easier.

 

Maybe we (the community) really should spend some time for that and upload full specs to github, where everybody can find it. If a company is so keen on keeping those things secret, that's exactly the point where we should hit them as hard as possible.

Linux Embedded / Kernel Hacker / BSP / Driver development / Systems engineering
Message 20 of 20
(1,446 Views)