JoeQ

Move the mouse too fast and Labview will not show the outlined cells correctly. This version will at least correct the SelStart and SelSize when the mouse is released so the boxes will be drawn in the correct locations. Table9.vi

I looked at adding some sort of arrow and home key support. There are no bounds checks etc. but should give an idea what it would take to make it work. If anyone is using a beta copy of 2014 or the latest version, let me know if the there is some basic Windows like editing support for tables, arrays or list boxes. cells_color.vi Table8.vi

Using a disable panel does not help much (see attached). You mentioned the tab. It appears that key works as expected with no additional coding. The arrow keys do not. Table7.vi

If you run my example, pressing setup will set the table to roughly the size I am needing. I would like to be able to see all of the cells on one screen as well as be able to work with multiple cells at one time. You will see me +/- shift+/- for inc/dec on multiple selected adjacent cells. Once the table is full size, just dragging the mouse across cells and selecting gets very slow. At that time, the program is not doing anything until it sees the mouse button release. I suspect that Labview has some amount of editing functions built-in. For example, when editing a constant array, normal Windows functions like insert/overwrite do not work. The editing features are not standard across all controls. I believe this is where the poor performance comes from. I don't want to require a third party tool unless that tool is Visual Studio. I was hoping the newer versions of Labview would have better editing support for all of their controls. It appears at least with 2011, little has been improved. I noticed NI has some sort of engine controls prototype support now (http://www.ni.com/powertrain-controls/). I have to believe they are working with tables as well but I have not checked into it. The table I am showing shows engine RPM versus throttle position. It's very common to work with tables like this. I wonder if they have some sort of add-on control that could be used.

I am looking for a way to make a table in Labview similar to MS Excel. I want to be able to edit cells in the table using the standard Windows key strokes and mouse selections. I have tried all of the native controls with little success. The problem when using the table control is that it has very poor performance as the window size is increased. It also seems that every feature would need to be coded rather than having the editing support native in the widget. I am very interested in seeing a way to make something work using the standard Labview controls. cells_selected.vi Table6.vi

It looks like it may be possible to use the VISA driver wizard to create a driver that supports interrupts by selecting the PXI option. They seem to show PXI and PCI working the same. They have a way to control the hardware using a series of programmable sequences. The commands are very limited and it completely would remove the need for an additional language. I have used the driver wizard in the past to support some custom hardware but only for memory access. I have not tried it yet with my custom hardware but will give you an update once I do.

I eventually upgraded to 2011 from 6.1i after the USB visa serial port snafu and am trying to see if there is a way to trigger Labview from an external source now. Over the years, I have used Windows to run various control systems in real time using hardware interrupts to synchronize the model. It works very well and requires no special software or hardware to implement. I have used this method with Labview in the past by coding all the interrupt handlers and the model in C/assembler. I would have a shared area that Labview can read data from asynchronous to display it with it's fancy GUI. Matlab Simulink with the RT would generate the C code for the model. With the PCs we have today, and all the math power now built into Labview, I would like to attempt to run the model in Labview. I currently have the hardware interrupts working and I have my handler (written in C) pulling the data off my board (custom hardware). Interrupt rates are fairly slow (1KHz max) but do not occur at a fixed rate in time. The model should be fairly simple so I don't see a problem there. The model will need to run synchronous with the interrupt and can't miss. In C, this is no problem. I can do it the old way and code the model in C and just use Labview for the GUI but it seems like by now NI would support some type of external event. After searching, I saw a few old posts where people have asked but have not found a working solution. I suspect they have the hooks built-in for some of their own hardware.

The Tripp-Lite adapter appears to use it's own chipset. It has a VID 2478, PID 2008, REV 0300. This adapter appears to work with all flavors of Labview and Windows. Strange enough, using C# with nothing more than com1.Open(); com1.Close(); prior to running Labview fixes the problem with all the OS and adapter combos. Labview can be closed and reopened and will continue to work correctly until the adapter is pulled and pulled back in or the PC is power cycled. NI has ".... exhausted all of our options. " I now doubt very much that they will fix it and I have asked that they go ahead and close out the case. Where I work, we have purchase several known working adapters to get around the problem for now. Had I known the PCI bus and serial ports were going to be problems, I think we would have stayed on 2009. The only push to "upgrade" to 2011 was NI dropping support for 2009. For my home projects, I have gone back to LV6. The speed of the UI is just too fast for me to ignore and it does everything I need it to. Till the next great bug hunt.....

I would guess that deal created over a half million in sales for NI. It was more a trial than anything but for that amount, I don't expect to have to beg for real support. We had an FAE at the time and he was given every opportunity to help us locate someone. If this would have been the case of a one off prototype, my expectations would have been different. All water under the bridge now, we learned our lesson the hard way.

For starts, I would have expected that they would have had us in contact with a person/s knowledgable about the design of the board. Knowing there was a deisgn problem and we needed a fix, I would have expected them to work with us under an NDA and provide us full details about their design so we could address it on our end. I would have expected them to offer to return all existing stock. While I am sure they believe the customer needs to verify each of their designs. The way I see it, fool me once shame on you. Fool me twice.... In the end, it would be VERY hard to sell us on Labview hardware and support.

I must have higher expectations. My favorite support call was back when Labview 5 came out. There was a new bug with their Ethernet GPIB controller. After many emails, they decided to setup a test inhouse to replicate the problem. It was the normal case where they could not reproduce it. We ended up talking on the phone and I asked about how the system was configured. As we talked I discovered they had a GPIB controller in the PC. They had connected the GPIB cable to that card, then to the Ethernet GPIB controller. They thought the GPIB Ethernet controller took GPIB and turned it into an Ethernet port. I gave up at that point and had them close the case. The bug remained there for several years but I am happy to say it has been fixed. We used one of their boards for a project once. Early on, we started having trouble with the board. I ran many tests on it and discovered the board did not meet their own specification. I sent them a detailed report outlining the tests I performed along with the results. After many attempts over several months to talk with someone inside NI, we gave up and designed a new front end for their board. Keep in mind this was not a single board purchase. Later I received an email from them. "I am the Product Support Engineer ...." "Thank you for the information that you provided." "In addition, I would like to thank you for pointing out that our CMRR specification is incorrect for this board at the +/-10V range. I have re-tested the board's CMRR specifications, and my numbers are in agreement with yours." "Finally, while I understand your desire to speak with a person knowledgable about the design of the board, at National Instruments we prefer that our design engineers work on designing new products with the least amount of interruption possible." In the end, the correction was to change the specification for the board.

I had suggested they make a drive to Staples. They of course are always welcome to send one here as well, but with them not being able to replicate the problem in-house there would seem to be little value in doing so. Again, all of the listed adapters work flawless with the older versions of Labview. This is something they have changed after 2009. I have tested the adapters on five different PC/OS combinations. It appears related to the new Labview as all of my other programs continue to work correctly. I would like to know more about how they couple into Windows. I can't imagine they are do any direct calls to the hardware. I have a hard time understanding why they would even be making changes to their serial interface. I am not aware of any major breakthrus in serial port technology in recent years.

It's been about a month now and I am sorry to say we have made no progress. I am now on my third support person. With each new person, I am asked the same questions over and over. I have been told that NI only supports the NI USB adapter. I understand they have tested one in-house and it worked correctly so this may be an option. I have been unable to get NI to purchase any of the listed adapters to replicate the problem in-house. I have been using an RS422/USB adapter with Labview over the last week that uses a FTDI chipset. Even running with BAUD rates of 921.6K, it has worked flawless. They offer RS-232 and RS-485 adapters as well using this chipset. Not mentioned above, another way to mark the end of data is using a break, or lack of data. Say for example, there is no data for 1.5 bit times, that would mark the end of a packet. This is/was a fairly common technique. With the PC not having a real time OS, timing something like this can be difficult without using additional hardware. As the PC talks to various peripherals, it can cause false timeouts. In my example, you notice that the timeout is set to 600ms. It is set this long for this reason.

I was unable to replicate the problem with saving for a previous version after testing on five other installs. The PC that had the problem is the one I used to help NI debug their PCI problems in VISA 5.1.1/2 Labview had several "patch" files installed. Even though I had used the windows uninstaller I wondered if something was not cleared out. I fully uninstalled ALL the Labview code (had to go into safe mode for some of it) then installed only LV 2011, SP1 clean using VISA 5.2. The save for previous now works for this PC. I have sent NI several reports and traces from various PCs which shows the problems with the serial port. I noticed while running the MAX techincal report, two of the 4 PCs I tested would crash. On one PC, I had the option to ignore the error and it would eventually create the report. The other PC did not have this option and MAX would just exit. This PC was the one that would not save for a previous version. After doing the complete uninstall and reinstall, the first time I ran the report generator without the drivers installed it worked. After installing the Aug release of drivers (VISA 5.2) using the default settings, MAX again crashes as before. The following is from the Windows log file: Faulting application name: NIMax.exe, version: 5.3.0.49152, time stamp: 0x4fbc1658 Faulting module name: MSVCR90.dll, version: 9.0.30729.6161, time stamp: 0x4dace5b9 Exception code: 0xc0000417 Fault offset: 0x0003523b Faulting process id: 0xa00 Faulting application start time: 0x01cd9028c95bd9ae Faulting application path: D:\Program Files (x86)\National Instruments\MAX\NIMax.exe Faulting module path: C:\Windows\WinSxS\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.6161_none_50934f2ebcb7eb57\MSVCR90.dll Report Id: 348e6ea6-fc1c-11e1-b449-005056c00008 Of course, Labview 6.1i ran flawless during all of this! The above information was also provided to NI.

I made up in the order of 15 different test cases, trying various things. Sync/async and polling had no effect. NI has contacted me and I am in the process of running some tests for them. I'll post any findings. Well, I thought I would retry this. For some reason with my one desktop, I it will not save as anything lower then 2010 no matter what is selected. This was then repeated on three other PCs and it worked fine. At first I though maybe it was because I had installed 2012 on this PC, but one other PC tested also had 2012 installed and it worked fine. Strange.

My first post had a test program which shows how the port is configured. Feel free to change the settings as you wish. Enabling hardware handshake (with hardware handshake) has no effect on the problem. The uploaded program I believe uses 0, but feel free to change it to a constant and select one of the options. None seem to have any effect. Again, I am just testing with a loopback connector now. It acts like someone decided the timeout was to not only be used for a timeout, but to also make it the time between transmits. No errors are reported from VISA. In LV 6 - 9, the serial communications with all of these adapters has been rock solid. I setup a test recently that LV 9 recorded data from a pressure gauge using on of them and ran for several months continious. Not a big deal. What ever the problem is, it came as a result of 2010 or 11. Rob, I was all with you until "But, one cannot use LabView 6 forever." ha ha... The only reason I attempted to upgrade at home was because I couldn't find our set of LV7 disks to install so I could port some code. I installed 2010 and it was so bad, I just pulled it back off. I never broke the seal on the 2011 disks until recent because I just assumed it would be no better than 10 was. Funny thing (that I'm sure everyone is aware of) is when you tell 2011 to save for a previous version older than 10, you get 10. Select 9, you get 10 code. I have had very good success with 2009 SP1

Running these same tests using LV 2012 with 5.2 VISA on Windows 7 64-bit and the Targus PA088 with latest drivers also fails. I have opened another service request with NI. Maybe they will actually fix this bug. If you need an adapter, we suspect the following one will work: http://www.newegg.com/Product/Product.aspx?Item=N82E16812156039

The problem does not change if running under 7 76-bit, while running 6.1 or 2011, SP2 with VISA 5.2(when tested with the Staples 18762 adapeter). Testing with 2009 on 7 64-bit works correctly (when tested with the Staples 18762 adapeter). While I have 2010 available, I have no desire to reinstall it to test it. Looking at the VID and PID for all five USB serial adapters they are as follows: MFG MFG PN VID PID REV DYNE X DXUBDBP 067B 2303 0300 Prolific Technology, Inc., PL2303 Serial Port TARGUS PA088 0711 0230 0103 Magic Control Technology Corp. STAPLES 18762 050D 0109 0102 Belkin Components, F5U109/F5U409 PDA Adapter GOLDX GXUSB-1200 0711 0230 0102 Magic Control Technology Corp. FT232RL, FUTURE TECHNOLOGY DEVICES INTERNATIONAL LTD I would assume that Windows would take care of all the low level communications with the drivers so I am not sure what they are doing with Labview 2011 that broke it. All of my other software that talks to these adapters work as they should. It's unique to 2011 and unfortunantly it appears to break all the older installs.

Things were working fairly smooth after my recent upgrade from 2009 SP1 to 2011 SP1. Beside the two bugs I already posted about, I didn't find any other major problems so I upgraded my home PC. At home I was still running 6. My home PCs are running XP 32-bit SP3. I wrote some new software under 2011 and installed it on my laptop. I use the laptop to collect data when I go to the race track using a Labview program I wrote that interfaces with the logger using RS-232. This software has not changed in a few years and is very solid. It is also a built application, no a VI. The last time I visted the race track, I go to plug the laptop into the logger and the serial interface no longer works. I spent a few hours trying to get things working had to throw in the towel. The $180 in gas and entry fees is nothing compared to the frustration (which is why I still run version 6). The basic symptom is the serial communication comes to a crawl. The data is sent fast, the logger responds fast, then the system hangs for about a second. It appears to be related to the timeout. The VISA call does throw a timeout error, but adjusting the timeout effects the delay. Setting the timeout to a very small number does not allow for the same bandwidth as just running a virgin copy of LV 6. Running the program as a VI had no effect. Running the VI under 2011 had no effect. Uninstalling 2011 did not cause the program to start working. Reloading an image of the hard drive prior to installing 2011 caused the program to start working. I attempted the running the software on a different laptop prior to installing 2011. It worked. Installed 2011, same bug. Installing VISA 5.2 had no effect. I ran several tests with two different desktop PCs and they all worked. Note that these PCs both have true serial ports on the bus. A friend brought in a small evalulation board that had an USB to serial TTL converter. We tried some test with this board and it worked. I then used my USB to RS-232 adapter with nothing more than a loopback cable. It failed. I then tried the following USB RS-232 adapters: Goldx GXUSB-1200, failed Staples 18762, failed Targus PA088, failed Dyne X DXUBDB9, worked!!! I am not sure why my friends USB adapter or the Dyne X work. Not that its of any help, I have attached a simple test program that shows the problem. If anyone else has ran into this and bought a different USB RS-232 adapter, please add it to the list. test12.vi

That case was closed out but I have entered a new case with them. Using a seperate checkbox to enable the graph will work. You can just lay it over the top as long as things don't move in your panel.

I had opened a case with NI about this problem and they said they would not fix it. No big deal as there are a few work a few work arounds. I just downloaded 2012 to try out and now the first check box of a graph no longer is selectable! Really! So I guess the next work around is to not use the very first graph and hide the first checkbox or something similar.

Thanks

They just used a node to force a redraw when the graph is touched. Their other option was to just keep refreshing the graph as part of a main loop. IMO, it would be best if they would make all the properties work the same.

Because you can change the colors to transparent and overlay graphs with images, you can get any sort of look you want.

I did open a case with NI about this new feature. They were able to replicate it easy enough but I am sorry to say they will not fix it. They did offer other work arounds.