John Lokanis

I saw a very cool program on the LHC last month on the Science Channel. IT is being replayed on the 31st if you want to catch it. http://science.discovery.com/tv-schedules/....125296.36136.0 -John

QUOTE (jgcode @ Aug 13 2008, 05:18 PM) Yes I realize that, but I am talking about the server side. Can we deploy a web service server on a machine that does not have the full DEV suite installed? In otherwords, can we deploy Web Services the same way we deploy EXEs?

I have been reading all the info on the new web service feature in 8.6 but have not figured out a few things. I was hoping someone at NI or a beta tester here could answer these questions or point me to the right docs. 1. Can a LV web service be deployed on a machine that does not have the full dev package installed? If so, how does this get done? What RTE components are required? 2. Does the web service run as a system task (in the background and running always if the machine is booted) or does it run under a specific user who must be logged in? How does it get launched? 3. Can a web service VI access information associated with the current user of a machine? (let's say I want to grab a screen shot of the current users session and return it as a MIME stream) 4. What kinds of security setting need to be setup on a machine so the web server will be accessible from another machine on the network? (firewalls, permissions, etc). 5. Do you know of any decent WYSIWYG web page dev tools that would work well with the output from a LV web service and don't require a lot of text code work? (Free would be best). 6. How does a web service deal with multiple simultaneous requests? (with each caller passing different parameters) Can it run reentrantly? Do we have to code it that way? thanks, -John

I

I

We are planning our move to 8.6 and were wondering if there were any OpenG packages that are known to not work in 8.6 yet. We use a lot of OpenG functions and the OpenG builder in our DEV work, so we need this to be stable before we upgrade. If no one knows, then I guess I will just have to try it and report back. thanks for any info you can share. -John

QUOTE (LV_FPGA_SE @ Aug 12 2008, 07:42 PM) That is a great idea! They could have a realtime display on the floor showing just how cold it is in each room so you know what to expect at your upcoming sessions... Maybe the promo item next year should be a fleese instead of a backback...

I have been using Perforce for several years now with LabVIEW. I think it is the best SCC out there. I have tried VSS, CVS, PVCS and SVN. The thing I like best about Perforce is the ability to have a UI to manage my files. I do not like the 'itegration' of SVN into the windows explorer. Perforce does this too, but I almost never use it. I do like the integration of an SCC into the LV Project. Mainly because when I create a new VI, it prompts me to add it to Perforce. I use the Perforce GUI to do my checkins, however. There are some things about Perforce that I do not like, but overall IMHO it is the best in breed. As for using SCC with LabVIEW, I do find that I keep all the fiels in the project checked out to me when doing major work. This way, I can freely edit and recomiple VIs as needed. When I am ready to checkin the changes, Perforce will do a DIFF and give me a list of all changed files so I can add my comments to each and submit them. In our group, we usually only have one DEV working on a Project or sub-project at a time, so this method works well. YMMV. -John

QUOTE (Darren @ Aug 8 2008, 12:50 PM) Whoa, you have *NEVER* programmed in a text based language? So, that must mean the quick drop function was written in pure G? Cool...

What they really need to do is have everyone sign up for the session they are interested in and rank them in order of preference before they choose times or rooms. Then they can at least *try* to choose times that cause the least amount of people to have a conflict AND they can assign the bigger rooms to the sessions with the most interest. This being my first NI Week, I may be off the mark here, but it seems like the bigger rooms were given to the more 'marketing' related sessions while the truely useful sessions to hard core LV DEVs were just wedged in where they could fit! Tell me where to comaplin and I will send my thougths to NI. I plan to at least start with my local reps.

Frozen blue, that is... I know I was warned by some posts before NI Week, but I was not prepared for how friggin cold it was in the convention center. Since NI was promoting green engineering, you would think they would try to walk the walk and ask the facility people to set the temp a bit higher! What a waste of power to keep us at 65deg while it was over 100 outside! I thought it was extra poignant that the USA Today outside my hotel room door on Thursday had this article in it: http://www.usatoday.com/money/workplace/20...nce-rooms_N.htm Made for an interesting read on the flight home. Anyhow, maybe we can start a petition to NI to have a reasonable temp setting next year. That would be a good first step toward real green engineering. (it was also funny that one of the keynotes included an HVAC expert who used LV to improve AC systems! Let's get this guy a contract to fix the Austin convention center's system.) Otherwise, it was a good first NI Week for me! Hope to see many of you there next year. -John

My only potential problem with Quick Drop is my left hand is busy changing tools with the tab key! (I just can't use the auto tool selection. old dog. no new tricks..) Plus, it is getting dangerously close to having to type again to write software! Seriously though, it looks like a cool feature. Now if we could just eliminate the keyboard and use one of these to call up the function we want: http://www.msnbc.msn.com/id/23261794/ -John

I would be interested in seeing how this is done. I would like to learn more about publishing data from LabVIEW to a web page that can be viewed from any browser. This sounds like a good example to learn from. -John

QUOTE (PeterB @ Jul 24 2008, 04:39 PM) I would agree with you in most cases, but the tree control is an exception. It is notoriously slow to update but a very powerful GUI display for hierarchical data.

This will be my first NI Week. I am staying at the Hilton. Still need to sign up for the LAVA party... I just did my schedule on the NI web site. I am really bummed that Michael and Stephen's presentations overlap. Who are the schedule wizards that messed that up! I really want to learn some new UI tricks but also want to hear from the GURU of LVOOP! I will only be able to attend Tues-Thurs. That is all the time my boss would agree to. At least the company is picking up the tab...

QUOTE (Gary Rubin @ Jul 24 2008, 10:09 AM) FWIW, you could use the report generation toolkit functions along with the example I created to automatically create a word doc and insert the image into it. You could then build all this into a small app and distrubute it to whomever needed this functionality. All you need is the LV8.5 Full Dev Suite on your machine to do this. Don;t we all have that?

QUOTE (PeterB @ Jul 24 2008, 12:28 AM) If you are writing to the FP control, I suppose this always causes a UI thread hit since it is 'updating' the UI. The thing that is particularly bad is to write to the value property of a FP control using VI Server. I have a general rule of thumb: Only write to FP controls when you *really* need to. For example, I have some UIs that use a tree control to display data. The temptation is to write to the tree all the time and let it 'store' the data. Unfortunately this is very slow. So, instead I have created a set of VIs that implement a 'shadow' data structure that stores all writes to the tree (including state changes, like cell colors). IF the FP is currently displayed, then the writes are also passed to the tree itself. If not, then they are only written to the shadow structure and when the FP is opened, I grey the tree, defer updates, update all the data from the shadow and then un-grey, un-defer and let the display refresh. When you have over 50 instances of a VI each with two trees on their FPs, this helps a lot. Sorry for the long winded description. I'm glad you like the WORM. It is particularly useful in multi-dev situations to ensure 'static' variables are not messed with by someone in some sub-vi. -John

QUOTE (TobyD @ Jul 11 2008, 03:23 PM) That is nice, but it requires access to scripting and uses the clipboard, clearing anything that might be in there already. Unfortunately, I don't have 'scripting' capability in LV8.5. I like how you added the feature to grab either the whole screen or active window. If it is a LV window, there is already a function in LV to grab the FP as an image, bit if the window is some other app, then that could be useful. My code could be modified to grab the active window, but that would mean detecting the active window and then getting it's coordinates. My goal is to create a web page that will serve the most recent image and will allow me to 'take a snap' of the screen on demand. I think there is a way to do this in ASP.NET using shared variables but I have a lot to learn in this area... -John

Here is a quick VI using .NET that will take a screenshot of the primary workspace and save it to a file. This is setup to save the file as a png, but you can easily change it to whatever you want. The VI will hide itself if it is open so it does not appear in the screenshot. Let me know if you find this useful or if I have any bugs. My purpose for this VI was to be able to prgrammatically grab a screenshot of apps I distrubute so I can see what is going on if a user has a question or there is an error. I'm sure there are many other uses. -John (written in LV8.5)

Yes, this a confirmed bug with NI. I ran into this in 8.2. Not sure if and when they plan to fix it. I told them that the parent should 'inherit' the defer updates setting from the child. For now, my solution is to defer both when I want to draw something time consuming, like a tree control update. This does lead to some complex logic... -John

QUOTE (rolfk @ Mar 20 2008, 12:38 PM) Don't tell that to Jim Kring! Actually, I am looking at taking the same path. As you mention above, this wheel is been reinvented many times... -John

QUOTE (Daklu @ Mar 20 2008, 02:35 PM) The variant tree structure is fast for reading but slow for writting. So, if you build the data tree once and then read from it often, this is a good approach. If you do a lot of reading and writing, then I would look at the Map Class mentioned above. I have not tested it against my variant tree but I plan to someday if I ever get some spare time. Let us know how you end up solving the problem! -John

QUOTE (i2dx @ Mar 15 2008, 01:26 PM) What interface does your toolkit use? ADO (ActiveX) or ADO.NET or some other external method to reach ADO databases? -John QUOTE (jdunham @ Mar 14 2008, 09:59 PM) John, We log tons of data to SQL server, sometimes a few dozen statements per second. The main optimization we use is that all statements which don't require a reply are sent in to a LabVIEW queue. Then a separate process flushes the queue once per second, concatentates all of the query statements, and inserts them a single ADO call. This process is not using a significant percentage of the CPU, so we could probably be logging a lot more. If you need to return results, then it seems like you are doing more than just logging. Our system also needs results sometimes, and while those calls can't be batched together, we can still call several queries per second. Good luck I am doing something similar. Each of my test engines (one for each DUT) has a thread that offloads all DB interactions and uses a queue. Calls that need return data pass a single element queue reference along with their SQL call to place the results in. Also, calls that require an answer enqueued at the opposite end so they get processed first. "Insert only" calls just queue up and get processed when there is time. I have not tried merging calls together. All my calls are to stored procedures so they all return something (custom error message). I don't think I can merge them. I do detect errors and retry the call 5 times before giving up. I get a lot of timeouts due to the DB being overloaded. We can have several testers all logging at once and up to 200 transactions per second hitting the database. I also did a little experiment recently to test methods of moving data between .NET and LabVIEW. I was building an ArrayList in .NET from the record set. The potential issue was that adding to an ArrayList allocates new space on each call. This reoccurring malloc could slow down the process. So, I changed it to a fixed 2D array in .NET. The problem here is the DataReader that gets the record set from the server is a forward only reader that cannot know how many rows are being returned. So, there is no way to know how big of an array to create before reading. So, I used a call that I knew would return 200 rows only. I then hardcoded the size of the 2D array to 200 rows. The funny thing was, when testing this the static array method was no faster than the ArrayList method. So, my new guess is the forward only data reader is the bottleneck in the process. FWIW, I was getting back a 200 row, 15 field record set in ~200ms. Still, the processing time on the DB to do the fetch and build the record set was < 1 ms. So, there is some significant overhead somewhere in there. -John

Thanks for the replys. It looks like both of the VIs mentioned above use COM to access the ADO interface instead of ADO.NET. Do you feel COM (ActiveX) is faster than .NET in LabVIEW? One difficulty I see in .NET vs COM is the lack of a native means of moving the recordset from .NET into LabVIEW. The ADO.NET assembly wants to use a Reader to iterate through the results one by one and fetch them. While this is a more portable interface (especially for script based languages that run in a VM, like VBScript or JavaScript), it is very slow in LabVIEW. As a result, I had to implement some tricks learned from Brian Tyler's old LV Blog and some C# code to work around this. Also, since both of your implementations use ADO, they must go through an additional layer (OLE DB) to reach the database. This is good if you want code that can use a variety of databases, but if your target is only SQL Server, then the ADO.NET System.Data.SqlClient provider (see http://msdn2.microsoft.com/en-us/library/k...ks0(VS.80).aspx) should be faster. Also See http://sqlbible.tar.hu/sqlbible0123.html And http://docs.msdnaa.net/ark_new3.0/cd3/cont...rgas%5CCh12.pdf And http://msdn2.microsoft.com/en-us/library/ms675532.aspx So, I guess ADO via ActiveX and ADO.NET are the leading methods. I have looked at directly calling the DBLIB DLL but that looks a bit more formidable to program. I wonder if passing the SQL call outside of LabVIEW to another environment would make more sense? -John

I have written a large test application that logs all data live to an SQL server. I am using the System.Data.SQLClient .NET assembly to interact with the database. This is working, but it seems to be a bit slow and I am wondering what the best method is out there. There are lower level drivers between this assembly and the transport layer. Has anyone written VIs to directly access those? One thing I did was write a little C#.NET code to move the record set data from .NET to LabVIEW in a single block move instead of an iterative process. This was a huge time saver, but I am wondering if there are more ways to speed things up. I realize that LabVIEW is not very speedy when calling .NET code. Would it be worthwhile to try an implementation using COM (ActiveX) instead? What about directly calling the lower level DLLs that the .NET code calls? Is there another solution entirely that I could try? All I need to be able to do is pass a SQL query to the DB and get back a record set. thanks for any help or insights. -John