06-11-2015 09:34 AM
This company uses LabVIEW 2012 and LabWindows 2010 in an Aerospace environment. The use of older versions is done to have commonality with their facilities across the globe. Thus, I cannot get them to upgrade.
On their new test station, they have 14 serial ports to communicate with the unit under test. I have developed a LabVIEW serial port interface program that will allow them to communicate with those serial ports. I have the ini file configured to allow the user to run multiple instances of the executable, for as many ports as they desire, during their testing. One option that they requested is the ability to right click the mouse, have a menu display to select copy or copy all of the data to the clipboard so that they can paste the received data into a test report. I used the LabVIEW App Invoke Node function Write to Clipboard and Read From Clipboard to perform the task. However, I have the issue that this works on some instances and does not work on other instances of the executables. Since the code is the same, the user enters which port to connect to, I do not understand why I have this issue. It works fine on my PC which only has a single COM port.
I decided to write two LabWindows functions to read and write to the clipboard using ClipboardGetText and ClipboardPutText. I call those dll functions from LabVIEW. The first call to the function ClipboardPutText works in the sense that the data is placed into the clipboard. However, I immediately get a fatal error and the process stops. (I did not save a screen image and the test stations are in use at this time). After that, none of the other instances will copy the data and they all result in a fatal error and stop. This is repeatable as I restarted the software numerous times as I tried to determine the cause.
Since I do not have access to the code for the clipboard functions, I cannot determine if I need to configure something else related to the clipboard or the process attempting to read/write from/to the clipboard. I will continue to search but wanted to ask the experts in control of the clipboard software to determine if they have any recommendations on what may need to be added.
For LabWindows, the only other call that I performed was a free command after I executed the ClipboardGetText, if the pointer to the text was not NULL.
I will post this in both the LabVIEW and LabWindows discussion boards in case one or the other has a solution.
Thank you for your help.
I can provide a zip file, containing the source code, to NI personnel if you provide an email address. Since I am a contractor, I am not sure if the company’s policy allows global posting of their code, although I may be able to reduce the code to a minimum example, if necessary.
06-11-2015 10:10 AM
Crash Reports
06-11-2015 10:43 AM
I would have expected that the function of the LabWindows methods would be the same as the LabVIEW built in methods to read/write from the clipboard? (So I would have expected the behaviour to be the same in both).
Perhaps you can use a Call Library Function to WINAPI or a .NET class (System.Windows) to read/write to the clipboard instead?
06-11-2015 03:26 PM - edited 06-11-2015 03:28 PM
I'd like to delve a little more deeply into the experience you have with the LabVIEW App.WriteClipboard (and ReadClipboard?) methods, since they would be the obvious way to make this work (and I've used them without problem in the past).
When you say they "don't work", are you evaluating the error output of the invoke node?
Are you wiring *in* an error wire, and if so, are you 100% certain there's never an incoming error that would cause the invoke to be skipped?
If you can categorically rule out error in/error out issues, next I'd look at what application you're trying to do the paste operation into. Is it Word? Excel? Notepad? There may be some clues in your answer.
Finally, have you tried doing a ReadClipboard immediately after the WriteClipboard and compared/displayed the two strings as a debug attempt?
Hope this gives you some fresh thoughts...
Dave
06-11-2015 04:25 PM
Other than Dave's suggestions (which I agree with. My experience with the method was also that it works quite well across process boundaries), you can also do a search here. There have been VIs posted in the past which make direct call to the Win32 functions for writing text to the clipboard. You can try rolfk's posts here and on LAVA.
06-12-2015 06:33 AM
There was a bug fixed in LabVIEW 2013 for problems relating to copying large amounts of data to/from the clipboard.
CAR 39604
06-12-2015 08:52 AM
06-17-2015 01:45 PM
I have done more testing in an attempt to clarify the error condition. I upgraded to LabVIEW 2014 on a Windows 7 SP1 system. I have enclosed some screen shots to show what I am doing.
My software allows multiple copies, 14 in this case, versions of the executable to run at one time. The software controls serial ports. The enclosed image of the front panel, LabVIEW window.png, indicates the COM port, baud rate, and version at the top of the window. This first small control allows the user to enter a command to send to the port. The large bottom indicator displays the data received on the port. I have menu items, pressing the right mouse button, that allows the user to clear all of the data, copy selected data, or copy all data. I have enclosed images of the copy, copy all, write to clipboard, and read serial port parts of the code. I was only copying small amounts of data, perhaps less than 256 bytes.
Here’s what I have noticed:
I seldom use these forums as I can get most of the code that I write to work as expected. Thank you for all of your help and suggestions.
06-17-2015 01:46 PM
Additional Images:
06-18-2015 01:49 PM
Thanks for your help.
The NI (National Instruments) software works correctly. The problem revolved around the developers of the software, for the unit under test, not initializing all of the ports exactly the same. They gave me some excuse for doing that which I just ignored. Anyway, the ports with the problem would transmit one or two NULL bytes when the unit had power applied because they were not initialized the same as the ports that worked, if at all. I ended up putting a filter in my code to analyzed the string replacing any NULLs with an asterisk. That resolved the issue.