File with .so extension built with C++ initially for older version causing problems.

[rolfk]

---

@Mordred wrote:
Hi people, just a couple of questions regarding LabVIEW Run Time Engine this time.

Current situation: VI files were built using LabVIEW 6.0 on Linux. Shared libraries (.so files) were created and compiled with gcc and previously linked to VIs built under LabVIEW 6.0.

Questions:
1.  Is it possible to have only LabVIEW Run Time Engine 7.1 installed in order to edit the VIs(not execute them) and be able to update the VIs and save them as under LabVIEW 7.1? After that, are they able to be executed under 7.1 and how do I go about updating the VIs (as in are there any special instructions)?

2.  If I want everything to be under 7.1 now, does it mean I need to recompile all shared libraries (.so) involved?

3.  Is it possible to just link the shared libraries without recompiling them with only LabVIEW Run Time Engine 7.1 installed and without Run Time Engine 6.0?

4.  Since shared libraries were compiled using gcc and g++, does using the correct Run Time Engine version has any effect on whether they can be linked or not (using 'Call Library Function')? Are there any connections?

Would appreciate it if anyone can enlighten me on these issues. Thanks a bunch.

---

1. No! In order to see the diagram at all or make any changes to a VI you need the Development system.

For the next 3 answers I assume your shared libraries are actually created from C code here. If by any change
you created the shared libraries from within LabVIEW this would be a completely different issue.

2. This shouldn't be necessary at all. LabVIEW has no different requirements for shared libraries between 6.0 and 7.1.
    As you have found out this may be different for the shared library in relation to the underlying OS.
3. The runtime system is used to run the LabVIEW VIs and has nothing to do with the shared library itself. As such
    you need the runtime system installed on your target system that corresponds in version to the development
    system that was used to create your VIs or executable.
    If the shared library was created using LabVIEW this would be quite different and if that is the case you should
    say so and I can try to explain a little more how that would work.
4. Again if the shared library was NOT created by LabVIEW there is no influence between the runtime engine and
    the shared library. So you should not see any difference from using such a shared library in a VI or applciation
    that has been compiled using LabVIEW 6.0 or 7.1 (aside from possible bugs in the Call Library Node that might
    have been fixed or improved between 6.0 and 7.1).

Rolf Kalbermatter

[Mordred]

Tell me more about this Call Library Node bug. Is there a link I can go which provides this information or any bug fixes?

[rolfk]

---

@Mordred wrote:
Tell me more about this Call Library Node bug. Is there a link I can go which provides this information or any bug fixes?

---

This is just about a hypothetical bug. Nothing specific I would know! But there might be a chance that something got fixed in a newer release that might have caused problems in the past. The (limited) work with the Call Library Node I did in LabVIEW 6.0 and later for Linux did not show any bug.

Rolf Kalbermatter

Message Edited by rolfk on 04-29-2006 11:42 AM

[Mordred]

Hi there.

I currently have a problem with serial port reading in Linux Mandriva 2006.  I wrote a C++ file utilising 'getline' functions to read serial port file "/dev/ttyS0" and called the C++ file from  a LabVIEW subVI. It gives valid ASCII code readings, but after a few minutes it just shuts down and closes i.e. crashes(without any message).

What seems to be the problem? Is it because of a wild pointer, and the use of referencing and dereferencing that caused the shutdown? Or any memory allocation size which is not appropriate, buffer overflow, etc?

I also tried variations of the C++ code and sometimes either it shuts down immediately after I press the 'Run' button or it occurs just like mentioned above. Is it also possible to have LabVIEW loop in a particular C++ file after calling it and keep returning the value without the 'Run Continuously' button clicked?

Secondly, I have also played around the VISA function for serial ports. It seems to me that it only has a drop down menu for us to choose COM1 or COM2 or some other names when I ran it in Linux. Is this VISA function compatible for a Linux machine which uses the serial port directories "/dev/ttyS0", "/dev/ttyS1" etc? If so, how can it be done?

Replies appreciated,
Mordred

[Shawn B.]

Mordred,

It sounds like you are making this too complicated.  If you want to read and write from serial ports just use LabVIEW and NI-VISA.  With VISA you simply need to open the port, then specify the number of bytes to read.  If you don't know how many bytes you can use the "bytes at port" property.

If you want to read continuously then you can place the read inside of a while loop.  Do not use the "Run Continuously" button, because there is no safe way to stop it.

NI-VISA opens ports using a VISA resource name.  Normally for a serial port this is something like ASRL1::INSTR.  You can assign an alias to that resource, on Windows people often call this COM1.  On Linux ASRL1::INSTR points to /dev/ttyS0, but if you want to change the mappings or give it a differnent alias you can use the visaconf utility.  Also make sure that your user has permission to read/write from the serial port you intend to use.  If they do not have permission NI-VISA won't be able to see the port.

I attached a screen shot of a basic serial app using VISA.  You should probably add a small delay to the while loop so that it isn't constantly polling the serial port.

Shawn B.
National Instruments

[Mordred]

Thanks a lot. By the way, another query.

Between reading serial port using C++(called by LabVIEW) and LabVIEW alone using NI-VISA, which one gives a better performance and stability?

Are there any advantages and disadvantages or any compromises between performance and stability with respect to both methods?

Mordred

[Shawn B.]

Actually NI-VISA is written in C++, and provides a LabVIEW interface (So it is essentially the same).  So since they are basically the same method the question of performance and stability depends on who wrote the code.

I can't comment on your C++ code, but I can tell you that NI-VISA has gone through many releases, and lots of testing.  I'm sure there are bugs in all code, and performance can always be improved a little more, but NI-VISA should be about as good as it gets.

There are other advantages to using VISA instead of writing your own code.  NI-VISA implements all of the serial features you would probably need to use, and it is cross platform (you can run your same LabVIEW code on Windows if you ever need to).

Shawn B.
National Instruments

[Mordred]

Hi,

I created a vi file which calls another shared library(compiled with C++) to read from the serial port using Call Library Function node.

It starts to read ASCII data from the Linux ttyS0 port but after a maximum of 3-5 minutes, it just shuts down/program closes by itself without any warning message.

In the vi, I passed two long variables (I specified int 32 in LabVIEW 7.0) to the C++ shared library which it calls. Then I specified a string return, which gives me the read ASCII data.

Are there any discrepancies between LabVIEW's length of a long variable and the C++ file?

What seems to be the cause of the crash?

Very much in need of help, would really appreciate anyone's take on this.

Thanking you in advance,
Mordred

[rolfk]

---

@Mordred wrote:
Hi,

I created a vi file which calls another shared library(compiled with C++) to read from the serial port using Call Library Function node.

It starts to read ASCII data from the Linux ttyS0 port but after a maximum of 3-5 minutes, it just shuts down/program closes by itself without any warning message.

In the vi, I passed two long variables (I specified int 32 in LabVIEW 7.0) to the C++ shared library which it calls. Then I specified a string return, which gives me the read ASCII data.

Are there any discrepancies between LabVIEW's length of a long variable and the C++ file?

What seems to be the cause of the crash?

Very much in need of help, would really appreciate anyone's take on this.

Thanking you in advance,
Mordred

---

LabVIEW int32 is equivalent to standard C long. As to telling about the reason for the crash this is not possible without seeing the code and possible debugging it in realtime. It definitely has to do with something like overwriting past the end of the string buffer (eg not allocating a long enough buffer in LabVIEW to pass to the shared library). Unfortunately a crash does not always happen exactly at the moment your shared library overwrites illegal memory but it can take a while before LabVIEW does access the corrupted memory. So there can be many points where your shared library just messes up.

Rolf Kalbermatter