>>>> For those wanting an open source (GNU) alternative to NI closed
>>>> source code here is a VXI11 set of source code by Steve D.
>>>> Sharples. The linux package can be compiled on Cygwin/Windows.
>>>> Hopefully this can be of use to someone.
>>> Did you read the start of this thread?
>>> As you can see at
>>> https://github.com/dac922/octave-instrument-control-toolbox/blob/master/vxi11_tb/build.sh >>>
>>> I use this package for my octave VXI11 toolbox.
>> Is this exclusively the only package you use? Does your code link to
>> non-free libraries? If it does link to non-free libraries, please take
>> it down, as this is a GPL violation.
> vxi11_tb uses source code from Steve D. Sharples VXI11 library. Except of vxi11.x (which has it's own open source license) all GPL.
> gpib_tb uses linux-gpib (GPLv2)
> usbtmc_tb and tcp_tb uses libc
> dummy visa_tb uses openvisa (GPLv2)
>>>> It would be more useful if you could add your code to the existing
>>>> instrument-control package in OF and merge your instrument-control
>>>> with the one that Andrius Sutas wrote for SOCIS.
>>>> Do you have the time and interest to do so?
>>> I have ported the TCP and USBTMC part. Could you take a look,
>> Andrius Sutas or Juan Pablo Carabajal may be better qualified than I
>> to judge this contribution. I am CC'ing them here.
>> As an aside, it's not "GNU/Octave". There should be no slash there.
>> The slash in "GNU/Linux" is meant to indicate that the operating
>> system is a combination of GNU with the Linux kernel. "GNU Octave"
>> isn't an operating system of which Octave is a kernel; it is merely a
>> GNU package.
> Monitor your physical, virtual and cloud infrastructure from a single
> web console. Get in-depth insight into apps, servers, databases, vmware,
> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
> Pricing starts from $795 for 25 servers or applications!
> http://p.sf.net/sfu/zoho_dev2dev_nov > _______________________________________________
> Octave-dev mailing list
> [hidden email] > https://lists.sourceforge.net/lists/listinfo/octave-dev
(I edited the topic to move out of the previous thread)
This is so great!
I do not have a card to test around (old INES DAQ, but never got them
to work under linux), I will take a look at the tcp part.
I suggest the following plan:
1.- Integrate your code to the current instrument-control package
(Andrius and Stefan, are you ok with this?)
a. I suggest we use the sub-package structure that, for example,
geometry has (http://sourceforge.net/p/octave/code/11459/tree/trunk/octave-forge/main/geometry/inst/).
b. We will need to update the makefile in the top folder to deal
with the new subfolders.
Stefan, have you ever look at comedi? They used to support many NI
cards, where there also using proprietary libraries? Is there we can
scavenge something from that project (it has been abandoned for a long
Juan Pablo Carbajal wrote:
> I do not have a card to test around (old INES DAQ, but never got them
> to work under linux), I will take a look at the tcp part.
> Stefan, have you ever look at comedi? They used to support many NI
> cards, where there also using proprietary libraries? Is there we can
> scavenge something from that project (it has been abandoned for a long
My instrument control is just for communicating with external (standalone) instruments over different interfaces. There's no direct driver support for DAQ devices.
Some time ago I looked at comedi library, but there's no support for my NI-5421 DAC. Unfortunately, I had to build a standalone exe, link it to NI's fgen and made a system call from octave. Terrible workaround, but it should be GPL save. :)
> My instrument control is just for communicating with external
> (standalone) instruments over different interfaces. There's no
> direct driver support for DAQ devices.
> Some time ago I looked at comedi library, but there's no support for
> my NI-5421 DAC. Unfortunately, I had to build a standalone exe, link
> it to NI's fgen and made a system call from octave. Terrible
> workaround, but it should be GPL save. :)
The technical details (pipes or dynamic or static linking) aren't what
makes the exe a derivative work of Octave or not, but rather the
fundamental nature of the communication and the kind of the data
exchanged. For example, is your exe producing output that only Octave
would understand and is only meant to be used with Octave? If so, this
is a GPL violation.
What kind of effort would it take to make comedi support your NI
hardware? This is the real long-term solution.