Community Documents

cancel
Showing results for 
Search instead for 
Did you mean: 

GOLPI - Gnu Octave to Labview Pipes Interface

Try GNU Octave with a new shiny interface!

 

Labview can do some very limited mathematics. Therefore one has to use an external software as Matlab. However Matlab is not free, so if you want to make a measurement program and use it on many computers, you need multiple licences or expensive server licence. And Labview to Matlab interface is not the best one. Or you can use GNU Octave - open source and free software with almost the same syntax as Matlab, and similar capabilities and speed. Unfortunately Octave is not directly supported by NI. In Linux, you can use comfortable pipes to interface GNU Octave. Unfortunately Windows pipes are still missing in Labview. Some old pipes implementation exist but not really working in new Labview versions. So GOLPI (Gnu Octave to Labview Pipes Interace) was created.


GOLPI works as a device. You initialize it, sends values or commands into, reads variables or outputs, repeat as you like, if you are finished you quit it.

  • Features:
  • Pipes (stdin and stdout) are used for communication to and from GNU Octave.
  • Polymorphic VI for reading a value of a variable (by means of stdout or temporary file for large amount of data).
  • Polymorphic VI for seting a value to a variable (by means of stdout or temporary file for large amount of data).
  • Can check if GNU Octave is still running.
  • Debug mode can store all communication going through pipes.
  • Debug console can be shown to view ongoing communication.
  • 3 examples included.
  • Tested on several versions of GNU Octave in Windows.

 

Block diagram of the VI Tree:

 

Block diagram of very simple demonstration:

 

Project is open source code. You can get latest verion and source code at my homepage: https://github.com/KaeroDot/GOLPI

Authors: myself and my collegue Stanislav Mašláň

 

Latest version: 0.5.0.1

Comments
bde1982
Member
Member
on

Hello Kaero,

thanks a lot for the plugin you programmed to access octave. It works really well!

It leaks a little bit when transferring data via pipes (variables take several hundred milliseconds to be transferred to and from octave), but it is on the whole working fine.

However, another problem occurs, when opening an TCP network connection and afterwards opening the octave gateway. If the gateway is not closed, GOLPI blocks the used TCP port. The only possibility to re-open it, is to kill the octave process in Windows task manager. The funny thing is: If first the gateway is opened and afterwards the TCP listener, then there is no problem and you can let it run several times.

This is somehow not so nice, if your server application keeps the octave gateway open, but your client (if on the same maschine) cannot open the TCP connection because the port is blocked.

There's a VI Sec attached with which you can try. Just let run the VI twice, the first time it runs, the second time not. If you turn around GOLPI::Open and Open TCP Listener there are no problems.

Best regards

bde

Octave.png

kaero
Member
Member
on

Hi,

I am very happy you found this library usefull. I know the transfer through pipes is crude and not very fast, there could be probably better solution.

To your problem: I do not see how it can be related to TCP connection. I do not understand why your vi was running first time and not second time, because when I recreated your vi it was not behaving this way.

Anyway I have found one bug in 'Create Process.vi', which is called by 'Start GNU Octave.vi'. Please do not connect anything to the terminal 'path to lv_process.dll' in 'Start GNU Octave.vi', your vi should work. In this case you have to place the lv_process.dll in the same directory as your vi/exe. I will prepare a fix. Let me know, if the temporary solution helped.

Another thing: you should always close Octave by 'Quit GNU Octave.vi', otherwise running instances of Octave will accumulate in memory.

bde1982
Member
Member
on

Hello,

sadly, the fix did not solve the problem.

It is strange you cannot reproduce the error, because I have it on two

systems, Windows 7 and Windows 8, both Labview 2014.

Maybe I send you hereby the VI that on my system produces the errors.

Of course you are right by closing the gateway. In my special case it is

just necessary to reopen TCP (or respectively UDP) connections without

closing the Octave gateway. And then it comes to the error...

Thanks anyway for the effort.

Best regards

bde

Am 27.02.2015 um 08:29 schrieb kaero:

>

National InstrumentsCommunity

<https://decibel.ni.com/content/index.jspa>

>

GOLPI - Gnu Octave to Labview Pipes Interface

new comment by kaero <https://decibel.ni.com/content/people/kaero>

View all comments on this document

<https://decibel.ni.com/content/docs/DOC-35221#comment-41485>

kaero
Member
Member
on

Please send me the VI (please save it for Labview 2013, I do not have 2014 installed), I will test it. You can also try to show debug console, just to know Octave is starting properly ('Start GNU Octave.vi', set false to 'Hide debug console' terminal).

bde1982
Member
Member
on

Hello,

thanks for the help.

The attached version is saved under LV 2013. I tested it (just in case)

and there's the same problematic, also under Labview 2013

Octave is starting properly, I can work on it.

Best regards

bde

Am 04.03.2015 um 09:50 schrieb kaero:

>

National InstrumentsCommunity

<https://decibel.ni.com/content/index.jspa>

>

GOLPI - Gnu Octave to Labview Pipes Interface

new comment by kaero <https://decibel.ni.com/content/people/kaero>

View all comments on this document

<https://decibel.ni.com/content/docs/DOC-35221#comment-41585>

kaero
Member
Member
on

unfortunately I cannot see any link to attachement. Where it should be? On what should I click?

bde1982
Member
Member
on

Oh, I am so sorry. The messages I answered using Thunderbird and simply attached the VIs. Seems like that does not work like this.

https://decibel.ni.com/content/servlet/JiveServlet/downloadBody/41665-102-1-81758/OctaveLV2013.vi

kaero
Member
Member
on

I am sorry, after clicking on the link I just get empty document. I tried several internet browsers with the same results, I tried to be or not to be logged in NI website, same result, no vi to download. Could you please upload the vi to some publicly accessible file server?

bde1982
Member
Member
on

One should think, in modern times it should be easy to simply share a file in a discussion forum. But it seems like, it really generates problems. Because I am not really keen on reading pages of "howto handle NI forum, because we forgot to implement an upload button in the message RTF field", I'll take your advice and upload it on our server.

I am really sorry for the difficulties and the waste of time on your side:

http://barolo.ipc.uni-tuebingen.de/download/OctaveLV2013.vi

kaero
Member
Member
on

Got it and reproduced error. Really strange, as you said it is impossible to reopen TCP connection, if the lv_process.dll (gnu octave) was called after firt TCP opening. It seems the error is most probably inside lv_proc.dll or maybe in incorrect calculation of handle size. We will take a look at it. Anyway the solution is first start the process (GNU Octave), then TCP gan be opened and reopened. And always close GNU Octave at the end.

Léo01630
Member
Member
on

Hello Kaero,

Thanks for your contribution. However, I would like to know if your packages have been tested with LV 2015 and octave 4.0.1.

I get the following error when trying to run the Simple Use demo vi:

Call Library Function Node in LV Process library.lvlib:Clean Up.vi->GOLPI library.lvlib:Quit GNU Octave.vi->GOLPI library.lvlib:Demo - Simple Use.vi

Is it due to wrong installation of the packages or to the fact that it has been designed for previous versions of labview and octave?

Thanks in advance,

Best regards,

Léo

Samuelw
Member
Member
on

Hi,

is there a similar one available for MacOS?

Thanks

Sam

kaero
Member
Member
on

Hello,

no, packages have not been tested with LV 2015 and octave 4.0.1. I will have to check where the problem is, unfortunately it will take a long time till I will have time to do it.

kaero
Member
Member
on

And, I do not know about any available for MacOS. I do not use MacOS. If you will create one for MacOS, we could join the packages into one bundle.

Larry.C
Active Participant
Active Participant
on

Hi Kaero,

 

Really impressed with this library. Had never heard of GNU Octave before but investigating it has got me excited. Being able to process m-files and not need a Mathworks license is really cool!!!

 

Just want to confirm that I got this library working in LabVIEW 2016 and GNU Octave 4.2.0 (latest). Simply need to make sure the pathing to Octave is correct.

 

Kind Regards,

 

Larry


Larry Colvin
Associate Principal Engineer
Dyson Technology Ltd.

kaero
Member
Member
on

 Released a new version, has better handling with GNU Octave versions 4.X and lot of fixes and small improvements. Project is moved to GitHub.

Spawacz2
Member
Member
on

Hi Kaero,

It seems GOLPI is what I need, but I use LV2011SP1. Is it possible to release GOLPI and LV process libraries for LV2011? Thanks a lot!

kaero
Member
Member
on

 Spawacz2: You can install 30 day preview for any higher version of labview, and save whole project or only libraries or vis as older version. Than you can open it in your version of labview. From time to time some people as me (in other projects) they need older version, but unfortunately I do not have enough free time to maintain it in more than one version.

TeraTech
Member
Member
on

I have some scripts that run fine in Octave but "crash" when run from the LabVIEW toolkit using the "Demo - Simple Use.vi". Can GOLPI handle complex numbers?

 

Also, is there a way to use the OctaveGUI to debug the scripts and find out where it is "crashing"?

^TeraTech.

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Check out this lengthy post of mostly complaints)
TeraTech
Member
Member
on
When I run "Demo - Simple Use.vi" with the path to my M script, I am getting error 6005: GOLPI library.lvlib:Read Output Till Keyword.vi Timeout reached while reading GNU Octave output. Complete call chain: GOLPI library.lvlib:Generate Custom Error.vi GOLPI library.lvlib:Read Output Till Keyword.vi GOLPI library.lvlib:Quit GNU Octave.vi OctaveCall_WIP.vi
^TeraTech.

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Check out this lengthy post of mostly complaints)
kaero
Member
Member
on

TeraTech: GOLPI can handle complex numbers. See polymorphic vis Get variable.vi and Set variable.vi to find out all types of variable which can be transfered. The type of GNU Octave variable is always checked before transfering to LabVIEW (i.e. it is impossible to transfer GNU Octave complex variable into LabVIEW double or string variable, you have to use LabVIEW complex variable) . If the variable type is not correct, it is written in the error message in LabVIEW. Check the type of variable in GNU Octave using command "class(variable_name)". E.g. "a=5; class(a)" gives output "double".

 

Read Output Till Keyword is used when LabVIEW shall wait till something specific happens on GNU Octave output. I use it in for long calculations. E.g. like this: "run_some_very_long_calculations; disp("Finished")." Than I set Read Output Till Keyword.vi to wait for keywords "Finished" and "error". If "Finished" appears on GNU Octave output, I know the calculation is finished and I can read variables. It is good practice to add keyword "error" so LabVIEW is not stucked waiting for "Finished" when some error appeared in GNU Octave.

 

You can always take a look at the console window of GNU Octave to see what happened with your script and why timeout error appeard. If you still cannot resolve the problem, please be more specific in your questions.

TeraTech
Member
Member
on

Thanks for the reply. Yes, I added a keyword to the end of the M-script to avoid the timeout as you mentioned. This allowed me to move further but still had another problem.  I am not using the GOLPI tookit to variable for calculations. I am simply passing an M-script file name to be executed. The M-script expects a command line parameter of a folder path. I believe the trouble I had was due to the "\"s in the command input of the GOLPI Write Command.vi.  I solved the problem by putting the path in quotes and using double-\ as follows: 

RunMeFirst "C:\\LV-Test\\Octave_Test_Proj\\SampleInputFiles\\Data"

 

Thanks for a great toolkit!

^TeraTech.

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Check out this lengthy post of mostly complaints)
kaero
Member
Member
on

TeraTech: It seems like not problem of GOLPI but a feature of GNU Octave. In Matlab you set multiline string e.g. as:

s=['first line' sprintf('\n') 'second line'];

In GNU Octave you can use the same or you can use quotation mark, which does translation:

s = "first line\nsecond line";

 

So I suppose you put path into quotation marks but character after \ were translated into special meanings like new line, tabulation character etc. Quotation marks translate double \\ into single \. You can try to use simple apostrophes, and it should work as you expected:

RunMeFirst 'C:\LV-Test\Octave_Test_Proj\SampleInputFiles\Data'

Contributors