LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

set serial lines status in linux

I'm developing a LabVIEW project in linux where I need to send/receive data on the serial port, but also set/read the serial lines status (i.e. RTS, DTR, CTS, DSR pins).
I know there are the VISA functions, and I've successfully used them in other projects: but for this project this is impossible. There are too less space and memory on my target to load the VISA Run Time Engine.

So I've done a lot of searches on the KB, the Forum, the Web... and now I'm able to use the old serial functions (with the serpdrv file) successfully. Smiley Happy
I know they're deprecated and so on, but this is my only choice.

The problem is that I haven't found a way to read and/or set the serial lines status: I looked into the serial vis and the provided examples, and I found the old "Device Control/Status.vi" without documentation. I found out that I have to set the input code (-) to 8 to initialize the port, to 9 to set the buffer size, to 12 to send a break.
But I haven't found the value to read and write RTS, DTR, CTS, DSR.

The Microsoft Windows version of serial line ctrl.vi (provided in _sersup.llb) uses the values 17, 18, 117 and 118 and It works perfectly.
The same values don't work on linux, and I tried all the values to 255 unsuccessfully Smiley Sad

Could someone help me, please?????
Vix
-------------------------------------------
In claris non fit interpretatio

-------------------------------------------
Using LV from 7
Using LW/CVI from 6.0
0 Kudos
Message 1 of 7
(3,431 Views)
I hate to say this, but I think the usual way to solve this under embedded
Linux is to make a device driver in C.

The device driver will be small (compared to a LV exe), in the order of
kb's. The module will create a file in /proc that LabVIEW can read form and
write to. It will releave your LV program of a lot of kludgy code. Also,
there will be a lot more information on the web about doing this in C.

Hope it helps,

Wiebe.


0 Kudos
Message 2 of 7
(3,416 Views)
I don't have any knowledge about doing this with LabView, but if you're going to have to go on the road Wiebe pointed,
making a device driver in C, here's a couple of links that will help you on the way.

Linux Device Drivers, 2nd Edition

Linux Device Drivers, Third Edition

The 2nd edition is for kernel 2.4 and the 3rd edition is for kernel 2.6. Also note that after the 3rd edition was published, the kernel code has
changes, so all the function are not the same as described in the book.

This is all I know about Linux device driver development, hopefully it helps you on you way Smiley Happy
0 Kudos
Message 3 of 7
(3,414 Views)
Well, in my opinion there should be no reason to write a serial device driver in C.  A device driver provides the information needed to communicate with the hardware, but in your case Linux already has a device driver for your serial port so why would you write a new one?

However, the other posters did provide a valid point, if you don't have enough memory/disk space to load the VISA Run-time Engine, are you going to have enough memory/disk space to load the LabVIEW Run-time Engine?  I would guess not.  So you may want to simply write your application in C instead.  If you do have enough memory/disk space for the LabVIEW Run-time Engine, but not C you could always use Call Library Nodes in LabVIEW to interface directly with the C library.  For more information on how you should interact with the serial port on any POSIX OS you can check out:

http://www.easysw.com/~mike/serial/serial.html

Using the legacy serial API in LabVIEW may work as well, but I haven't looked/used that API in a long time.

Shawn Bohrer
National Instruments
Use NI products on Linux? Come join the NI Linux Users Community
0 Kudos
Message 4 of 7
(3,404 Views)


@Shawn B. wrote:
if you don't have enough memory/disk space to load the VISA Run-time Engine, are you going to have enough memory/disk space to load the LabVIEW Run-time Engine?  I would guess not.

I must load the entire LabVIEW Run-time Engine on my system: it's the only way to have my application working; but this requires some MB of disk and of RAM.
And so I can't waste other memory and disk to send and receive some bytes over the serial port.



you could always use Call Library Nodes in LabVIEW to interface directly with the C library

do you mean is there a *.so library containing the functions I need? or should I write a library by myself?

Thanks


Vix
-------------------------------------------
In claris non fit interpretatio

-------------------------------------------
Using LV from 7
Using LW/CVI from 6.0
0 Kudos
Message 5 of 7
(3,383 Views)


@vix wrote:
do you mean is there a *.so library containing the functions I need? or should I write a library by myself?

Well, that depends on exactly what you want to do.  If you only need to call a couple of C functions you can probably use libc.so directly.  If you want to do something more complex you may want to write your own library in C and then simple call your library to minimize the number of Call Library Nodes you have to use.  Check out the link from my previous post, and/or take a look at "man termios"

Shawn Bohrer
National Instruments
Use NI products on Linux? Come join the NI Linux Users Community
0 Kudos
Message 6 of 7
(3,377 Views)
If you have a large budget, you could use LabVIEW Embedded. Compiling LVEmb
to Linux comes almost out of the box. This way, you can even use another
target (not x86), but LV Embedded is expensive. If you have a bulk product,
it might be worth the investment. This will only work if your software
doesn't have a user interface though. LV Embedded doesn't support user
interfaces, and implementing a UI would require interfacing with gtk, qt or
a framebuffer or something.

Reason I suggested to write a device driver is that I have no idea what
standard Linux commands can do with the serial port, and I just read a book
where they create device driver to communicate with I2C and SPI ports. One
benifit would be that you can put some of the compexities in the device
driver, but I have no idea if this is worth the effort. A C wrapper could be
used, but from LabVIEW, you need to work with api calls, while with a device
driver, you work with files (if I understand correctly).

Guess there are a lot of options to consider.

Regards,

Wiebe.


0 Kudos
Message 7 of 7
(3,350 Views)