LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

write to binary file different from 8.0 to 8.2?

I am communicating with a device via USB and am using a method setup by the USB driver programmer. To communicate, I write to a binary file with a filename of \\?\COMx. This has been working fine for about a  year in mfg with Labview 8.0. I recently "upgraded" to 8.2 and now it does not work. If I save for a previous version and run 8.0 it works fine. How can I make this work with 8.2?
0 Kudos
Message 1 of 12
(3,550 Views)
Hi dgtest1,
Which USB device you are using, and which driver are you using? I'm trying to figure out specifically how you are communicating with the USB device by writing a binary file and how was the binary file written.  Could you please post more information to describe in more details about what your set up is doing?
Thanks!

Yi Y.
Applications Engineer
National Instruments
http://www.ni.com/support
0 Kudos
Message 2 of 12
(3,522 Views)

Yi Y,

The USB device is one of the instruments we manufacture. The USB driver is written so writing to the USB port is just like writing to a file. I use the binary read/write VI's to send and receive commands to this USB device. The filename I use is \\?\COM#. I am told by the USB driver creator that this is common for low level C. I have been using this VI for that last year and recently upgraged from 8.0 to 8.2 and it does not work. I run the same vi under 8.0 and it works fine. This is not a common way to communicate, so will probably not get an answer.

My next question is, is there any way to run an 8.0 dll or vi from an 8.2 executable?

Thanks

 

 

Hi dgtest1,
Which USB device you are using, and which driver are you using? I'm trying to figure out specifically how you are communicating with the USB device by writing a binary file and how was the binary file written.  Could you please post more information to describe in more details about what your set up is doing?
Thanks!

Yi Y.
Applications Engineer
National Instruments
http://www.ni.com/support

0 Kudos
Message 3 of 12
(3,515 Views)
Hi dgtest1,
You can call LabVIEW 8.0 DLL in LabVIEW 8.2.x like how you would call regular dll.  The only complication is that you'll need the run-time engine in order to run a LabVIEW DLL.  By default, the 8.0 dll will call the LabVIEW 8.2 RTE, which probably means you'll end up having the same problem with the write to binary file.
I'm not sure what's the behavior if you have both version of the RTE installed.  In order for that you happen, you need to install the RTE for 8.0 first and then RTE for 8.2.
I would suggest trying to make a DLL in 8.0 and try to call it from 8.2 and see if the same issue persist.
Please also double check some of the default settings for write to binary files in 8.2.x.  Sometimes if the default settings changes and you have unwired terminals that uses default settings, you could encounter problems.
I would appreciate it if you post here with your results working with DLL, or if you have mnre questions, please don't hesitate to post here.

Yi Y.
Applications Engineer
National Instruments
http://www.ni.com/support
0 Kudos
Message 4 of 12
(3,500 Views)

I don't recall whether the change was made with LabView 8.0 or 8.2, but the file APIs have changed significantly with recent versions. Things to check:

  • Are you using the binary (vs text) api? There used to be only one Write File primative. Now there is Write to Text File and Write to Binary File. Write to Text can change various aspects of your data (line endings, adding line feeds, etc) so you probably want Write to Binary File.
  • If you are writing binary files, check endian-ness. LabView has always written binary files in network (big endian) order but there is now an option to change that.
  • Oddly and inconveniently, the new file APIs no longer append to the end of an existing file by default. You have to set the file pointer manually to end of file now if you write to the file in multiple steps.

To tell what is going on, write the same data to a file (not your usb device) with both LV 8.0 and 8.2. Use a compare tool like diff to find how the two files differ. Debug from there. (If files are the same, the problem is elsewhere.) 

-Rob Calhoun

0 Kudos
Message 5 of 12
(3,488 Views)
Rob has some really great points, and those listed above are definitely good things to check.  Please post the results here.

Thanks!

Yi Y.
Applications Engineer
National Instruments
http://www.ni.com/support
0 Kudos
Message 6 of 12
(3,465 Views)
Thanks for the suggestions. I have written to a file and the data is the same. 8.0 did have endian-ness, and it is set to little-endian. I am using the binary write to write the data and then binary read to read data. I have tried variations of all settings with no luck. I am guessing the problem is either:
1. The ? in the filename is considered an error in 8.2
2. Some type of memory violation
 
I have it working by saving 8.2 project as 8.0. The only way I can think of fixing this is to write a dll in C that writes the string to the file and returns the string read.
 
Thanks again
0 Kudos
Message 7 of 12
(3,457 Views)
> 1. The ? in the filename is considered an error in 8.2

"?" is definitely not a legal file/directory character in NTFS (Windows)!!! ("/\*?<>|: are all illegals.) You should get error 1 ("bad arg") on Windows if that path has an "?" in it. (If LabView 8.0 allowed that, it was a bug that was fixed in later releases.)

I realize that you are writing to a virtual file system (the COM port); does the virtual file system require a "?" in the path?

-Rob
0 Kudos
Message 8 of 12
(3,451 Views)
Just re-read your first message; you are writing to \\?\COM1, so it is the "computer" part of the UNC path that is "?".

According to this page:

http://msdn2.microsoft.com/en-us/library/aa365247.aspx

the \\?\ syntax is used to invoke the Unicode version of the Windows file functions, so \\?\c:\foo.txt is a legal UNC path in Windows (who knew!) and, indeed, LabView (8.5) can write to such a file successfully. So I do not know what the problem is.

-Rob
0 Kudos
Message 9 of 12
(3,449 Views)

Rob,

The guy that wrote the USB driver was one of the original Microsoft USB programmers, so he knows all those hidden details. I have also been talking with another NI person that was going to ask the design group about this, so I'll post if I hear anything.

Thanks,

Don

0 Kudos
Message 10 of 12
(3,428 Views)