low level I/O (GPIB, USBTMC, VXI11)

classic Classic list List threaded Threaded
32 messages Options
12
Reply | Threaded
Open this post in threaded view
|

low level I/O (GPIB, USBTMC, VXI11)

Stefan Mahr
Hi,

I just noticed that there were Summer of Code Project Ideas for low level I/O.

Some years ago I already posted my toolbox for serial, tcp, gpib (and visa) to this list. Meanwhile I have added VXI11 and USBTMC. National Instruments GPIBENET-100 support is started, but even more incomplete than the rest of the toolbox. However, basic I/O is working and I'm able to talk with all of my instruments.

I put the code to
https://github.com/dac922/octave-instrument-control-toolbox

Hope someone find it useful.

Best regards,
Stefan
_______________________________________________
Help-octave mailing list
[hidden email]
https://mailman.cae.wisc.edu/listinfo/help-octave
Reply | Threaded
Open this post in threaded view
|

Re: low level I/O (GPIB, USBTMC, VXI11)

Jordi Gutiérrez Hermoso-2
On 23 November 2012 10:34, Stefan Mahr <[hidden email]> wrote:


> Some years ago I already posted my toolbox for serial, tcp, gpib
> (and visa) to this list. Meanwhile I have added VXI11 and USBTMC.
> National Instruments GPIBENET-100 support is started, but even more
> incomplete than the rest of the toolbox. However, basic I/O is
> working and I'm able to talk with all of my instruments.

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?

- Jordi G. H.
_______________________________________________
Help-octave mailing list
[hidden email]
https://mailman.cae.wisc.edu/listinfo/help-octave
Reply | Threaded
Open this post in threaded view
|

Re: low level I/O (GPIB, USBTMC, VXI11)

Julien Salort
In reply to this post by Stefan Mahr
"Stefan Mahr" <[hidden email]> writes:

> Some years ago I already posted my toolbox for serial, tcp, gpib (and
> visa) to this list. Meanwhile I have added VXI11 and USBTMC. National
> Instruments GPIBENET-100 support is started, but even more incomplete
> than the rest of the toolbox. However, basic I/O is working and I'm
> able to talk with all of my instruments.

Hello,

This is very interesting !

Some colleagues and I have also been using Octave for VISA, DAQmx,
DC1394 and Modbus instrument control for a while.
(we have several experiments that use it every day)

We decided recently to put the code on Github too. Mostly because I am
now convinced that there is no legal issue (I was afraid of people
complaining if it somehow breaks their instruments), and because we are
three people committing changes, so a VCS was needed.

http://github.com/jsalort/OctMI

That makes 3 packages for the same purpose. However, I don't know about
yours, but mine uses National Instruments libraries for VISA and DAQmx,
and free libraries for FireWire cameras and Modbus.

I guess the NI part is not compatible with octave-forge policy of not
encouraging using proprietary software.

Julien

_______________________________________________
Help-octave mailing list
[hidden email]
https://mailman.cae.wisc.edu/listinfo/help-octave
Reply | Threaded
Open this post in threaded view
|

Re: low level I/O (GPIB, USBTMC, VXI11)

Stefan Mahr
In reply to this post by Jordi Gutiérrez Hermoso-2


Jordi Gutiérrez Hermoso wrote:
 >> Some years ago I already posted my toolbox for serial, tcp, gpib
 >> (and visa) to this list. Meanwhile I have added VXI11 and USBTMC.
 >> National Instruments GPIBENET-100 support is started, but even more
 >> incomplete than the rest of the toolbox. However, basic I/O is
 >> working and I'm able to talk with all of my instruments.
 >
 > 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?

c. wrote:
 > If you see room for improving either of the two packages maybe you'd
 > like to work on merging the two?

Merging to OC would probably mean a complete rewrite. At the moment I
don't have enough time for this effort.

Stefan
_______________________________________________
Help-octave mailing list
[hidden email]
https://mailman.cae.wisc.edu/listinfo/help-octave
Reply | Threaded
Open this post in threaded view
|

Re: low level I/O (GPIB, USBTMC, VXI11)

Stefan Mahr
In reply to this post by Julien Salort


Julien Salort wrote:
> That makes 3 packages for the same purpose. However, I don't know about
> yours, but mine uses National Instruments libraries for VISA and DAQmx,
> and free libraries for FireWire cameras and Modbus.
 >
 > I guess the NI part is not compatible with octave-forge policy of not
 > encouraging using proprietary software.

I wrote the toolbox for my work, where I use Windows and Linux. Since NI
VISA is very complicated to install on Ubuntu - if even possible on
actual 64bit installation - I had to find other ways. Besides that, I
think linking to NI VISA would violate the GPL.

For linux you can talk to all instruments without using any proprietary
software. For windows you still have a problem if you don't have serial
or LAN based instruments or at least a VXI11-GPIB gateway.

Of course, the best way to communicate with instruments would be using
the VISA interface, but you need a (working) free VISA library first.

Stefan
_______________________________________________
Help-octave mailing list
[hidden email]
https://mailman.cae.wisc.edu/listinfo/help-octave
Reply | Threaded
Open this post in threaded view
|

Re: low level I/O (GPIB, USBTMC, VXI11)

Stefan Mahr
In reply to this post by Stefan Mahr

Stefan Mahr wrote:

> Jordi Gutiérrez Hermoso wrote:
>>> Some years ago I already posted my toolbox for serial, tcp, gpib
>>> (and visa) to this list. Meanwhile I have added VXI11 and USBTMC.
>>> National Instruments GPIBENET-100 support is started, but even more
>>> incomplete than the rest of the toolbox. However, basic I/O is
>>> working and I'm able to talk with all of my instruments.
>>
>> 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?
>
> c. wrote:
>> If you see room for improving either of the two packages maybe you'd
>> like to work on merging the two?
>
> Merging to OC would probably mean a complete rewrite. At the moment I
> don't have enough time for this effort.
>

Well, I take a short look to i2c package. At least for USBTMC you don't
even have to change code. :-)

_______________________________________________
Help-octave mailing list
[hidden email]
https://mailman.cae.wisc.edu/listinfo/help-octave
Reply | Threaded
Open this post in threaded view
|

Re: low level I/O (GPIB, USBTMC, VXI11)

Julien Salort
In reply to this post by Stefan Mahr
Le 23 nov. 2012 à 23:18, Stefan Mahr <[hidden email]> a écrit :

> Julien Salort wrote:
>> That makes 3 packages for the same purpose. However, I don't know about
>> yours, but mine uses National Instruments libraries for VISA and DAQmx,
>> and free libraries for FireWire cameras and Modbus.
> >
> > I guess the NI part is not compatible with octave-forge policy of not
> > encouraging using proprietary software.
>
> I wrote the toolbox for my work, where I use Windows and Linux. Since NI VISA is very complicated to install on Ubuntu - if even possible on actual 64bit installation - I had to find other ways. Besides that, I think linking to NI VISA would violate the GPL.

It is my understanding you can link with whatever you want for your personal usage.
However, DISTRIBUTING a binary that links with NI VISA definitely violates the GPL.
That is why I don't distribute binaries, only source code.

Besides, my code should compile with libgpib and openvisa, even though I haven't tested. The source code in itself does not forbid anything.

Personnally, I haven't been able to install NI VISA on Ubuntu reliably. That is why I use Scientific Linux, which is an officially supported distribution. It is much easier to install National Instruments drivers of Scientific Linux (it installs right out of the box). Of course, it would be easier if their drivers were free. I filed a complaint already. You may complain too. Maybe if many people complain, they might change their way ?

> For linux you can talk to all instruments without using any proprietary software. For windows you still have a problem if you don't have serial or LAN based instruments or at least a VXI11-GPIB gateway.

I have a very heterogeneous environment for my experimental setups (Windows XP, Macintosh and Linux). The nice thing with NI drivers is that the same code works on those three platforms out of the box, and it allows to communicate with a very wide range of devices. Considering how expensive a PXI is (for example), I definitely need a driver that allows me to use all its functions... My colleagues wouldn't understand if I use a driver that wouldn't allow me to use all its capabilities.

> Of course, the best way to communicate with instruments would be using the VISA interface, but you need a (working) free VISA library first.

I agree a free VISA (and DAQmx) would be much nicer. I personally don't have the time nor the knowledge to work on that.

In a mean time, I need to work, and the NI VISA (and DAQmx) library does work on many platforms, and can be freely downloaded. I regret that it is not free and that you have to agree to their restrictive license terms.
_______________________________________________
Help-octave mailing list
[hidden email]
https://mailman.cae.wisc.edu/listinfo/help-octave
Reply | Threaded
Open this post in threaded view
|

Re: low level I/O (GPIB, USBTMC, VXI11)

Jordi Gutiérrez Hermoso-2
On 24 November 2012 03:33, Julien Salort <[hidden email]> wrote:
> It is my understanding you can link with whatever you want for your personal usage.
> However, DISTRIBUTING a binary that links with NI VISA definitely violates the GPL.
> That is why I don't distribute binaries, only source code.

I've never been clear if this is really ok, but it seems to be a
common interpretation. It seems to be, for example, how nvidia gets
around Linux's copyleft and the nvidia blob.

Richard, can you comment on this? A number of Octave users create oct
files to talk to non-free libraries for external hardware. An oct file
is basically a C++ program that uses Octave's headers and links to
Octave. It is my understanding that these oct files are also linking
to non-free libraries. I am uncomfortable that people do this and
distribute the results. What do you think?

- Jordi G. H.
_______________________________________________
Help-octave mailing list
[hidden email]
https://mailman.cae.wisc.edu/listinfo/help-octave
Reply | Threaded
Open this post in threaded view
|

Re: low level I/O (GPIB, USBTMC, VXI11)

Richard Stallman
    > It is my understanding you can link with whatever you want for your personal usage.
    > However, DISTRIBUTING a binary that links with NI VISA definitely violates the GPL.
    > That is why I don't distribute binaries, only source code.

The user, on his own initiative, is free to link GPL-covered code with
nonfree code and use that privately.  However, to modify a GPL-covered
program so that it is meant to link to some non-free code, and
distribute that, is not a private action.  It is a way of combining
the program with nonfree code.  That violates the GPL.

    I've never been clear if this is really ok, but it seems to be a
    common interpretation. It seems to be, for example, how nvidia gets
    around Linux's copyleft and the nvidia blob.

nVidia's nonfree driver violates the GPL, but the Linux developers
choose not to object.  We can't force them to enforce their license.

As for the firmware blobs, there is an argument that firmware programs
are separate programs merely packaged together with Linux, and thus
not violations of the GPL.  However, the issue is moot since the
copyright holders of Linux choose not to enforce the GPL anyway.

    Richard, can you comment on this? A number of Octave users create oct
    files to talk to non-free libraries for external hardware. An oct file
    is basically a C++ program that uses Octave's headers and links to
    Octave. It is my understanding that these oct files are also linking
    to non-free libraries. I am uncomfortable that people do this and
    distribute the results. What do you think?

That could be a GPL violation.  We need to look at the specific
details.

--
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call

_______________________________________________
Help-octave mailing list
[hidden email]
https://mailman.cae.wisc.edu/listinfo/help-octave
Reply | Threaded
Open this post in threaded view
|

Re: low level I/O (GPIB, USBTMC, VXI11)

Sergei Steshenko




----- Original Message -----
> From: Richard Stallman <[hidden email]>
> To: Jordi Gutiérrez Hermoso <[hidden email]>
> Cc: [hidden email]; [hidden email]; [hidden email]
> Sent: Sunday, November 25, 2012 6:46 AM
> Subject: Re: low level I/O (GPIB, USBTMC, VXI11)
[snip]
> The user, on his own initiative, is free to link GPL-covered code with
> nonfree code and use that privately.  However, to modify a GPL-covered
> program so that it is meant to link to some non-free code, and
> distribute that, is not a private action.  It is a way of combining
> the program with nonfree code.  That violates the GPL.
[snip]

>
> --
> Dr Richard Stallman
> President, Free Software Foundation
> 51 Franklin St
> Boston MA 02110
> USA
> www.fsf.org  www.gnu.org
> Skype: No way! That's nonfree (freedom-denying) software.
>   Use Ekiga or an ordinary phone call
>
> _______________________________________________
> Help-octave mailing list
> [hidden email]
> https://mailman.cae.wisc.edu/listinfo/help-octave
>

No, "It is a way of combining the program with nonfree code.  That violates the GPL", it does _not_violate GPL.

One of the greatest GPL features is that it does _not_ require the distributed code to work.

So, the modified GPL code is to be distributed with free in FOSS sense _non_-working code which quite incidentally happens to have the same interface as the non-free code the GPL program is supposed to work with.

And then on site the GPL program is easily (re)linked with proprietary code using all kinds of tools/approaches, the easiest of the being LD_PRELOAD trick (e.g. http://stackoverflow.com/questions/426230/what-is-the-ld-preload-trick ).

Regards,
  Sergei.
_______________________________________________
Help-octave mailing list
[hidden email]
https://mailman.cae.wisc.edu/listinfo/help-octave
Reply | Threaded
Open this post in threaded view
|

Re: low level I/O (GPIB, USBTMC, VXI11)

Stefan Mahr
In reply to this post by Stefan Mahr
The instrument control package at octave forge creates a class as kind
of file descriptor. While there are methods to access read, write, etc.
from C++ / oct-File, there are no methods when using from octave.

I know that classdef for .m file is not ready yet. Is it the same for
.oct files?


Stefan
_______________________________________________
Help-octave mailing list
[hidden email]
https://mailman.cae.wisc.edu/listinfo/help-octave
Reply | Threaded
Open this post in threaded view
|

Re: low level I/O (GPIB, USBTMC, VXI11)

Julien Salort
In reply to this post by Richard Stallman
Le 25 nov. 2012 à 05:46, Richard Stallman <[hidden email]> a écrit :

>> It is my understanding you can link with whatever you want for your personal usage.
>> However, DISTRIBUTING a binary that links with NI VISA definitely violates the GPL.
>> That is why I don't distribute binaries, only source code.
>
> The user, on his own initiative, is free to link GPL-covered code with
> nonfree code and use that privately.  However, to modify a GPL-covered
> program so that it is meant to link to some non-free code, and
> distribute that, is not a private action.  It is a way of combining
> the program with nonfree code.  That violates the GPL.

I didn't modify any existing GPL sources, specifically I didn't modify Octave sources. Octave already had the ability to run compiled functions linked to whatever library you wish. Those compiled functions behave a bit like plug-ins, by the way.

What I did, is create wrappers that allows calling some of the 488.2, VISA and DAQmx functions.

Those are very simple: the oct file just #include <visa.h> and calls one VISA function, eg. viOpen for example.
There is nothing that prevents someone from linking this wrapper to OpenVISA instead of NI VISA.
The same is true for 488.2. The oct files are wrapper that #include <ni488.h> and call, eg. ibdev. The free libgpib library defines the same function. So someone can link the wrappers against libgpib or NI 488.2.

It happens that I personally only tested with NI VISA, NI 488-2 and NI DAQmx because this allows me to get support from NI if there is a problem, and their libraries are compatible with all the acquisition cards they sell. Those libraries are free like in free beer but closed source and they require to agree to a restrictive license. I don't particularly like this but I don't really have a choice (my first requirement is to be able to acquire data). I filed a complaint requesting that they open their source already.

The files I distribute are:
- CPP source files of the wrappers;
- Octave script files that implement high-level functions that rely on these wrappers.

All the files that I distribute are distributed under the GPL license.

If someone wishes to test them with alternative free library and modify the configure.ac to ease the linking with those, I will be very happy. If someone has the knowledge to implement a free alternative to NI-DAQmx does so, I will be very happy. Installing these NI libraries under linux is a pain because they cannot be packaged easily, they have their own installers that don't work with all linux distributions, they don't support the way the latest Linux kernels handle USB, etc.
Whenever a full-featured alternative free library is available, I'll switch to it enthusiastically. My code is written in such a way that I think it should be easy to link against some other library: only the wrappers might have to be modified (presumably) and their number is limited.

Now. I'm free to do what I want for my personal usage. I feel it is nice to distribute these files, in case someone else is interested. But it wouldn't make much difference to me if I don't distribute them. So, if distributing source files (without even the implied warranty that it fits a particular purpose) violates the GPL, I will just stop distributing them.

Please tell me if you feel this is the case.

Julien
_______________________________________________
Help-octave mailing list
[hidden email]
https://mailman.cae.wisc.edu/listinfo/help-octave
Reply | Threaded
Open this post in threaded view
|

Re: low level I/O (GPIB, USBTMC, VXI11)

c.-2
In reply to this post by Stefan Mahr

On 25 Nov 2012, at 10:21, Stefan Mahr wrote:

> The instrument control package at octave forge creates a class as kind of file descriptor. While there are methods to access read, write, etc. from C++ / oct-File, there are no methods when using from octave.
>
> I know that classdef for .m file is not ready yet. Is it the same for .oct files?

I am not completely sure what you mean, is it something related to these threads?

    https://mailman.cae.wisc.edu/pipermail/help-octave/2012-November/054970.html
    https://mailman.cae.wisc.edu/pipermail/octave-maintainers/2012-November/030767.html
    https://mailman.cae.wisc.edu/pipermail/octave-maintainers/2012-November/030775.html
    https://mailman.cae.wisc.edu/pipermail/octave-maintainers/2008-November/013305.html
   
could you please explain a bit better?

> Stefan
c.
_______________________________________________
Help-octave mailing list
[hidden email]
https://mailman.cae.wisc.edu/listinfo/help-octave
Reply | Threaded
Open this post in threaded view
|

Re: low level I/O (GPIB, USBTMC, VXI11)

Richard Crozier
On 25/11/2012 11:25, c. wrote:

> On 25 Nov 2012, at 10:21, Stefan Mahr wrote:
>
>> The instrument control package at octave forge creates a class as kind of file descriptor. While there are methods to access read, write, etc. from C++ / oct-File, there are no methods when using from octave.
>>
>> I know that classdef for .m file is not ready yet. Is it the same for .oct files?
> I am not completely sure what you mean, is it something related to these threads?
>
>      https://mailman.cae.wisc.edu/pipermail/help-octave/2012-November/054970.html
>      https://mailman.cae.wisc.edu/pipermail/octave-maintainers/2012-November/030767.html
>      https://mailman.cae.wisc.edu/pipermail/octave-maintainers/2012-November/030775.html
>      https://mailman.cae.wisc.edu/pipermail/octave-maintainers/2008-November/013305.html
>      
> could you please explain a bit better?
>
>> Stefan
> c.

I suspect he wants to do something like this:

http://www.mathworks.co.uk/matlabcentral/fileexchange/38964-example-matlab-class-wrapper-for-a-c++-class
http://www.mathworks.com/matlabcentral/newsreader/view_thread/278243

Richard

--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

_______________________________________________
Help-octave mailing list
[hidden email]
https://mailman.cae.wisc.edu/listinfo/help-octave
Reply | Threaded
Open this post in threaded view
|

Re: low level I/O (GPIB, USBTMC, VXI11)

Juan Pablo Carbajal-2
In reply to this post by Richard Stallman
>     Richard, can you comment on this? A number of Octave users create oct
>     files to talk to non-free libraries for external hardware. An oct file
>     is basically a C++ program that uses Octave's headers and links to
>     Octave. It is my understanding that these oct files are also linking
>     to non-free libraries. I am uncomfortable that people do this and
>     distribute the results. What do you think?
>
> That could be a GPL violation.  We need to look at the specific
> details.
>
> --
> Dr Richard Stallman
> President, Free Software Foundation
> 51 Franklin St
> Boston MA 02110
> USA
> www.fsf.org  www.gnu.org
> Skype: No way! That's nonfree (freedom-denying) software.
>   Use Ekiga or an ordinary phone call
>
> _______________________________________________
> Help-octave mailing list
> [hidden email]
> https://mailman.cae.wisc.edu/listinfo/help-octave

Richard,

This is an example of the code in the package in question.
https://github.com/jsalort/OctMI/blob/master/Low-level/GPIB/src/ibdev.cpp
(Julien correct me if I am wrong)

It includes octave/oct.h and ni488.h.
It uses a macro defined in octave/oct.h, some functions and several
datatypes. finally it uses a function from the ni488.h

to me it looks like a wrapper to a library function. Is this a GPL violation?

What about if one would add compiler directives in the header

#ifndef FREE_BEER
#include <free_gpib.h>
#else
#include <ni488.h>
#endif

and in the body of the function

#ifndef FREE_BEER
ud = free_ibdev(BdIndx,pad,sad,tmp,eot,eos);
#else
ud = ibdev(BdIndx,pad,sad,tmp,eot,eos);
#endif

Would this be a violation? clearly the user is not being forced to
link to the non-free library, just he "can".

Thanks
_______________________________________________
Help-octave mailing list
[hidden email]
https://mailman.cae.wisc.edu/listinfo/help-octave
Reply | Threaded
Open this post in threaded view
|

Re: low level I/O (GPIB, USBTMC, VXI11)

Stefan Mahr
In reply to this post by Richard Crozier


Richard wrote:

> On 25/11/2012 11:25, c. wrote:
>> On 25 Nov 2012, at 10:21, Stefan Mahr wrote:
>>
>>> The instrument control package at octave forge creates a class as
>>> kind of file descriptor. While there are methods to access read,
>>> write, etc. from C++ / oct-File, there are no methods when using from
>>> octave.
>>>
>>> I know that classdef for .m file is not ready yet. Is it the same for
>>> .oct files?
>> I am not completely sure what you mean, is it something related to
>> these threads?
>>
>>
>> https://mailman.cae.wisc.edu/pipermail/help-octave/2012-November/054970.html
>>
>>
>> https://mailman.cae.wisc.edu/pipermail/octave-maintainers/2012-November/030767.html
>>
>>
>> https://mailman.cae.wisc.edu/pipermail/octave-maintainers/2012-November/030775.html
>>
>>
>> https://mailman.cae.wisc.edu/pipermail/octave-maintainers/2008-November/013305.html
>>
>> could you please explain a bit better?
>>
>>> Stefan
>> c.
>
> I suspect he wants to do something like this:
>
> http://www.mathworks.co.uk/matlabcentral/fileexchange/38964-example-matlab-class-wrapper-for-a-c++-class
>
> http://www.mathworks.com/matlabcentral/newsreader/view_thread/278243
>
> Richard
>

Example based an instrument control / serial:

   a=serial("/dev/ttyS0");
   srl_close(a);

Matlab has a second way to call a method:

   a.close;  or   a.srl_close;

I don't know the actual state of octaves OOP, so my question is: Is the
second way already supported by octave? If yes, what's wrong with the
.oct file? Also, I would expect the list of the methods by calling

   methods("octave_serial")


Stefan
_______________________________________________
Help-octave mailing list
[hidden email]
https://mailman.cae.wisc.edu/listinfo/help-octave
Reply | Threaded
Open this post in threaded view
|

Re: low level I/O (GPIB, USBTMC, VXI11)

Juan Pablo Carbajal-2
On Sun, Nov 25, 2012 at 2:08 PM, Stefan Mahr <[hidden email]> wrote:

>
>
> Richard wrote:
>>
>> On 25/11/2012 11:25, c. wrote:
>>>
>>> On 25 Nov 2012, at 10:21, Stefan Mahr wrote:
>>>
>>>> The instrument control package at octave forge creates a class as
>>>> kind of file descriptor. While there are methods to access read,
>>>> write, etc. from C++ / oct-File, there are no methods when using from
>>>> octave.
>>>>
>>>> I know that classdef for .m file is not ready yet. Is it the same for
>>>> .oct files?
>>>
>>> I am not completely sure what you mean, is it something related to
>>> these threads?
>>>
>>>
>>>
>>> https://mailman.cae.wisc.edu/pipermail/help-octave/2012-November/054970.html
>>>
>>>
>>>
>>> https://mailman.cae.wisc.edu/pipermail/octave-maintainers/2012-November/030767.html
>>>
>>>
>>>
>>> https://mailman.cae.wisc.edu/pipermail/octave-maintainers/2012-November/030775.html
>>>
>>>
>>>
>>> https://mailman.cae.wisc.edu/pipermail/octave-maintainers/2008-November/013305.html
>>>
>>> could you please explain a bit better?
>>>
>>>> Stefan
>>>
>>> c.
>>
>>
>> I suspect he wants to do something like this:
>>
>>
>> http://www.mathworks.co.uk/matlabcentral/fileexchange/38964-example-matlab-class-wrapper-for-a-c++-class
>>
>> http://www.mathworks.com/matlabcentral/newsreader/view_thread/278243
>>
>> Richard
>>
>
> Example based an instrument control / serial:
>
>   a=serial("/dev/ttyS0");
>   srl_close(a);
>
> Matlab has a second way to call a method:
>
>   a.close;  or   a.srl_close;
>
> I don't know the actual state of octaves OOP, so my question is: Is the
> second way already supported by octave? If yes, what's wrong with the .oct
> file? Also, I would expect the list of the methods by calling
>
>   methods("octave_serial")
>
>
> Stefan

I moved this thread to "IC Serial"
_______________________________________________
Help-octave mailing list
[hidden email]
https://mailman.cae.wisc.edu/listinfo/help-octave
Reply | Threaded
Open this post in threaded view
|

Re: low level I/O (GPIB, USBTMC, VXI11)

c.-2
In reply to this post by Richard Crozier

On 25 Nov 2012, at 12:49, Richard wrote:

> I suspect he wants to do something like this:
>
> http://www.mathworks.co.uk/matlabcentral/fileexchange/38964-example-matlab-class-wrapper-for-a-c++-class
> http://www.mathworks.com/matlabcentral/newsreader/view_thread/278243
>
> Richard

There is nothing special to be done to link C++ with Octave,
Octave itself is written in C++ so classes have no need to be "encapsulated"
in an oct file you can just use them as in any other C++ program.

c.

_______________________________________________
Help-octave mailing list
[hidden email]
https://mailman.cae.wisc.edu/listinfo/help-octave
Reply | Threaded
Open this post in threaded view
|

Re: low level I/O (GPIB, USBTMC, VXI11)

c.-2
In reply to this post by Stefan Mahr

On 25 Nov 2012, at 14:08, Stefan Mahr wrote:

> Example based aninstrument control / serial:
>
>  a=serial("/dev/ttyS0");
>  srl_close(a);
>
> Matlab has a second way to call a method:
>
>  a.close;  or   a.srl_close;
>
> I don't know the actual state of octaves OOP, so my question is: Is the second way already supported by octave?

Octave interpreter supports old style Matlab classes but not new style "classdef" classes

> If yes, what's wrong with the .oct file?

why do you think there is something wrong?

> Also, I would expect the list of the methods by calling
>
>  methods("octave_serial")

to have that work all methods operating on the class "serial"
should be inside a directory named @serial.
I think it would not be a bad idea to make such change in
the "instrument control" package.

you should propose that change on the Octave Forge feature request traker,
even better if you can already prepare a patch.

> Stefan
c.
_______________________________________________
Help-octave mailing list
[hidden email]
https://mailman.cae.wisc.edu/listinfo/help-octave
Reply | Threaded
Open this post in threaded view
|

Re: low level I/O (GPIB, USBTMC, VXI11)

Richard Crozier
In reply to this post by c.-2
On 25/11/2012 15:29, c. wrote:

> On 25 Nov 2012, at 12:49, Richard wrote:
>
>> I suspect he wants to do something like this:
>>
>> http://www.mathworks.co.uk/matlabcentral/fileexchange/38964-example-matlab-class-wrapper-for-a-c++-class
>> http://www.mathworks.com/matlabcentral/newsreader/view_thread/278243
>>
>> Richard
> There is nothing special to be done to link C++ with Octave,
> Octave itself is written in C++ so classes have no need to be "encapsulated"
> in an oct file you can just use them as in any other C++ program.
>
> c.
>
>

Really? so i can have a C++ class, and call it and its methods from an
m-file in Octave, and have it persist like a real C++ object from one
call of its methods to the next?

This is not possible with plain mex files in Matlab because you must
create an instance of a C++ class which will be destroyed once the mex
file completes (which is the problem that using handle classes in the
linked example solves). As I understood it Octave has the same
limitation, but since it does not yet have classdef, there is no way to
do the same thing. I'd be very interested hear if there was though, or
that I have misunderstood something about oct files.

Richard



--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

_______________________________________________
Help-octave mailing list
[hidden email]
https://mailman.cae.wisc.edu/listinfo/help-octave
12