John Lokanis

Are you using web services with LV2009SP1? Have you deployed the web service to a target machine that only has the runtime system on it? When you start your LV app (causing the web server to start on the target machine), how long does it take before you can successfully make web service calls to that machine? I am porting my 8.6.1 code to LV2009SP1 and have found that the web server appears to be unresponsive for approximately 2 minutes after I start it by launching the app that has the server enabled in its ini file: WebServer.Enabled=True Under 8.6.1, the web server would be working immediately after the app was started. thanks for any ideas or workarounds -John

Thanks for the tip. I guess I was hoping there was a way to do this natively within the project, but I guess writing automation code is the only way. I will give your project a try.

Ok, so now I can turn on a feature in LV 2009 that outputs a log file when I build an exe. And that log file contains a line that tells me the version number. Now, what I really want is the installer that installs this EXE to display the version number when the installer runs, so the use can see what version they are about to install. Anyone know a way to make this happen?

Well, you certainly cannot 'turn a knob' with the web service solution. You can do some things with an automation interface. Like sending a command with parameters to cause the remote app to do something. But graphical interaction is not possible. There is a new web tool coming from NI where you can write a client side UI using LabVIEW like code and compile it into Silverlight code that the client can run. Limits you to web browsers that support Silverlight, however. And it means you need to write two apps instead of one. Why port 80 is blocked for you, I have no idea. But, I can assure you all of Europe is not blocked from port 80.

Well, just finished replacing all calls to the two button dialog with the three button dialog that can disable the close button and/or differentiate between button presses and the close window button. I think NI needs to update the primitive with something better. One other 'note' about these one and two button primitives: they are not root-loop safe. In other words, if one pops up and there is no one around to click on it, all your parallel code in the background will freeze as soon at it hits a function that requires root loop access, like VI server calls to open a dynamic VI. Fun! (FWIW, dropping down a menu and leaving it unselected will do the same thing) Final note: the three button dialog is not reentrant, in case you ever needed it to be...

Just thought I would pass this simple observation when using the 2 button dialog. I created a dialog where I wanted to warn the user to be careful when selecting a certain operation. In order to make sure they did not accidentally select OK, I reversed the messages so the cancel would be the one that defaulted to having it's key focus set to true. Then, I used the 'T button?' output to select the case and put the code to do the action in the false case. I then patted myself on the back for making a safer UI. Along comes the "user" and they select this operation from the menu then panic thinking the computer will explode if the do the operation. But, instead of pressing the 'abort' button, they CLOSE THE DIALOG BOX! Which, of course returns a FALSE for the 'T button?' and the code is executed... Now, I know I am a fool for not seeing this possibility, but I just thought I would share so perhaps someone else doe not make the same mistake I did... -John

In response to #1, with my web service tool, that is not correct. The 'looking' PC only needs a web browser. ANY web browser. I can 'look' with my iPhone. I am certain that the run time engine is not installed on my iPhone. As for #2, if that were true, then nobody in Europe would ever be able to surf the web, as all web traffic (HTTP) uses port 80.

The web service feature can supply a standard web form for the client to fill out. I doubt you can achieve what you are trying to do using the remote panel feature.

No problem here. Must be your machine.

If anyone wants to read up on how to move large data sets between .NET and LV, here are some links: http://detritus.blogs.com/lycangeek/2005/09/array_vs_arrayl.html http://detritus.blogs.com/lycangeek/2005/09/getting_the_arr.html -John

I don't use the NI-CT toolkit because it is way too slow for large record sets. I 'rolled my own' database toolkit by calling ADO.NET directly from LabVIEW. To get large record sets, I use the tricks from Brian Tyler's old blog on how to move large data between .NET and LabVIEW using arraylist data types. I did need to write a very small c# function to do this but it was not too hard. If you are not up for that yourself, I think the NI-CT does have a way to establish a connection using a connection string. As I said above, I saved the variables in an INI file and then read them in and use a format into string to construct the connection string on the fly and open my connection. I believe you will still need the MySQL driver installed on your system, but should be able to avoid the process of setting up an ODBC link with the data sources manager tool. I used to do that back in the Win3.11 days and it was a PITA. good luck! -John

I have avoided Data Source Names in ODBC all together by connecting directly to the database server using a connection string like this: Server=yourdatabaseserver.domain.network.com;Database=yourdatabase;User ID=youruser;Connection Timeout=60;Trusted_Connection=FALSE;Net=dbmssocn; I use and ini file to specify the components of that connection string so the customer can edit them as needed. you could have your app pop up a dialog on first run to query the customer for those values and write them to the ini file. I am using the ADO.NET interface to talk to SQL server, by MySQL should also be supported.

You should be able to do this by saving the callback with a breakpoint on one of the wires or nodes. A callback is simply a dynamically called reentrant VI. When it is invoked, it should stop at the breakpoint and allow you to probe, step, etc... I would suggest enabling retain wires values. Also, I would suggest using shared clones instead of preallocate for all your reentrant VIs.

Yes, I can confirm that appears to demonstrate the bug. My first CAR of 2010! And it applies to a LV version I have not even ported to yet! Any idea when this CAR will be fixed and released? LV2010? BTW: I thought the new version of LV was 2009, not 9.0!

Looks like they might have simply moved the bug instead of fixing it. As I said, I cannot reproduce it in a simple VI under the 8.6.1 dev environment, but I can reproduce it in my exe running under the 8.6.1 RTE. Not sure if the issue is in the RTE, or the fact that the code is inside a large massively parallel application where just about everything is a reentrant shared clone.

thanks guys. I got this to work and was able to find a brand new bug (at least to me) in 8.6.1. See my other post on the Get Variant Attribute function.

I have been unable to build a simple example of this bug so I have not reported it to NI yet, but I figured this was annoying enough to warn people about. Not sure if all the steps are needed to repro this, but I included them all anyways. I have discovered in some complex code in my application that the 'Get Variant Attribute' function can sometimes behave abnormally. Here is what I am seeing: I start with an empty variant (Top Variant). I call 'Get Variant Attribute' to get a specific attribute (Parent Attribute 1) (if it does not exist, I should get an empty default variant). I then add a sub attribute (Child Attribute 1) to the 'found' (or empty if not found) Parent attribute. I then replace the Parent attribute in the Top Variant with this new variant (with the sub attribute attached). This is basically a tree structure. So far, I have this: -Top Variant --Parent Attribute 1 ----Child Attribute 1 I continue this until my Parent has several children: -Top Variant --Parent Attribute 1 ----Child Attribute 1 ----Child Attribute 2 ----Child Attribute 3 ----Child Attribute 4 ----Child Attribute 5 I then remove these one by one by getting the Parent variant, calling 'Delete Variant Attribute' with a child as the attribute to remove and then replacing the Parent into the Top Variant. I leave child 3, however. Now I have this: -Top Variant --Parent Attribute 1 ----Child Attribute 3 Now, I replace the Parent with an empty variant to 'Flush' the tree. Now I have this: -Top Variant --Parent Attribute 1 Here is where the bug comes in. Now I repeat the whole process, but for Parent Attribute 2. When I call Get Variant Attribute on the Top Variant and give it the name 'Parent Attribute 2', it should give me a default empty variant because that attribute does not exist in the Top Variant. Instead this is what I get: -Top Variant --Parent Attribute 1 --Parent Attribute 2 ----Child Attribute 1 ----Child Attribute 2 ----Child Attribute 3 ----Child Attribute 4 ----Child Attribute 5 WTF? The new attribute seems to inherit all the child attributes that ever existed in the new Parent's sibling (which still exists, but is empty) The fix is easy, however. Just wire an empty variant to the default value terminal of the 'Get Variant Attribute' function when you try to get an attribute and the problem goes away. Just don't trust that the unwired default will really be an empty variant. Now, as I said, I cannot seem to reproduce this with an example VI, but I can instrument my code and see this happening. I dump the whole Top Variant tree to a file before the call to 'Get Variant Attribute' and then right after. I also confirmed that the 'Found' output is false and the value output contains the 5 child attributes, even though nothing is wired to the 'default value' input.

Anyone have a good way of converting a variant tree into something displayable/log-able without writing some massive recursive function? (using 8.6.1, so no native recursion for me unless I use VI Server tricks) I need to dump the status of my tree to a log file for debug purposes. The tree is just an empty variant with attributes that have attributes that have attributes... thanks, -John

I have had very good luck with DIGI port servers. We have many of these at facilities all over the world and they have worked flawlessly for us. The nice thing is, you can configure them so your LabVIEW code just connects over TCP/IP to their IP and the specific port that corresponds to the physical serial port on the unit. No need for any drivers on your machine. Of course, they also have a driver for virtual serial port support so existing apps can use them seamlessly. I know they come in 2,4 8 and 16 port versions. I have used the 4 and 16 port versions my self. They even have a wireless version if you don't have network cabling to where your serial device is located. You can remotely manage these via a web browser. here are some links: http://www.digi.com/products/serialservers/portserverts816.jsp#overview http://www.digi.com/products/serialservers/portserverts.jsp#overview good luck!

I think Brian's point was that the pinvoke method wraps up all the error handling, mem alloc and threading issues into a nice .net interface. Not sure as I have not used it yet and I am sure I will learn more as I do. I have called some Win32 stuff in the past and it can be non-trivial if you don't know what you are doing.

Already tried that...

I think what it mainly give you are c# wrappers for Win32 calls that you can use to build a simple .NET assembly that you can then call from LV easily.

Here is a site that Brian Tyler (formerly of NI, now at MS) recommended for all LV Dev who need to call Win32 functions: http://www.pinvoke.net/ This site is a Wiki for how to use pinvoke from .NET to call the Win32 APIs. This is also a good ref for those of you who dapple in C#. hope this helps someone... -John

Too bad NI is not making a LV web front end that uses HTML5.

Also, to do this programmatically, you need to deal with many issues. 1. you cannot disable the control, because then the scroll bars will not work and the mouse scroll wheel will not work. 2. It does not matter if it is a control or indicator, because you will trap all the mouse down events and discard them anyways. 3. You must make sure the mouse down events you trap and process are 'in bounds' so you don't mess up clicks on the scroll bars. 4. You must process both shift and ctrl separately and mimic their normal behaviors. 5. Due to #4 you must save the last clicked row in the shift, ctrl and no modifier cases for use in the shift case. This is because the selection for the shift case is always between the clicked row and the last clicked row. 6. For the ctrl case, you must deal with both the add row and delete row if the row is already selected. 7. If your MCLB is set to 1 or more items, you must not allow all rows to be deselected in the ctrl case. 8. For the shift case, you must build an array of indexes for all value between the selected row and the last clicked row. So, this is not trivial. And a real PITA to have to do just because you don't have access to the 'last clicked row' value of the native control.