64 bit serial driver with 32 bit VISA causing problems?

[JDorsey]

I'm running LabView 2012 on Linux (kernel 3.10) on an x86_64 machine. I think that VISA is not playing nicely with my 64-bit serial driver. I have a few instuments connected through an NPort serial to ethernet converter. Instruments which output data constantly (unpolled) are working fine. I'm reading ASCII data from those using both minicom and LabView / VISA with no problem. Instruments which need to be polled for data are not working.

The same software and drivers are working fine on a 32-bit machine in the same lab (although I compiled the NPort serial driver for 32-bit on that machine). All I can think is that 32-bit VISA doesn't like the "bitness" of the 64 bit serial driver, and it's mashing anything I try to write to a serial port. This being the case:

1) Can I install 64-bit VISA for Linux in conjunction with 32-bit Labview? Would that work?

2) If I have to go for a 64-bit LabView, do I really need to downgrade my kernel to 2.x as suggested in a hidden NI compatibility document that I now can't find?

3) Why is Linux such an after-thought with NI?

[JDorsey]

OK. Panic over. Could be down to differences in control codes that the newer version of the driver is acting on.

[james@IceMan ~]$ stty -a -F /dev/ttyr00
speed 9600 baud; rows 0; columns 0; line = 0;
intr = <undef>; quit = <undef>; erase = <undef>; kill = <undef>; eof = <undef>; eol = <undef>; eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S;
susp = <undef>; rprnt = <undef>; werase = <undef>; lnext = <undef>; flush = <undef>; min = 0; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts -cdtrdsr
-ignbrk -brkint -ignpar parmrk inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke

[james@IceMan ~]$ stty -g -F /dev/ttyr00
18:0:8bd:4000:0:0:0:0:0:0:0:0:11:13:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0

[james@IceMan2 ~]$ stty -a -F /dev/ttyr00
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd -cmspar cs8 hupcl -cstopb cread clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff -iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke

[james@IceMan2 ~]$ stty -g -F /dev/ttyr00
500:5:cbd:8a3b:3:1c:7f:15:4:0:1:0:11:13:1a:0:12:f:17:16:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0

[JDorsey]

In fact, not solved. It's dropping 4 or 5 bytes from the front of serial messages. If I use the terminal I can get:

$ echo -en '\xFA\x30\x4\x43' > /dev/ttyr02

$ od -x < /dev/ttyr02
0000000 30fa 4304 30fa 4304 30fa 050a 2e06 010a
0000020 9478

This is the correct response. Echo the command and then return further data. In Labview, the response starts with

FA 30 0A 05

which is actually the data part of the message. It's therefore failing the checksum test. The first four bytes have been lost. Can anyone help with this? It's 64-bit Linux with 64-bit serial kernel module, running 32-bit labview. Kernel is 3.10.

[crossrulz]

Discussion continued here:http://forums.ni.com/t5/LabVIEW/Labview-is-randomly-dropping-4-or-5-bytes-from-the-front-of/m-p/3077...