John Lokanis

emphasis on the 'relatively'... Some of us come from much cooler climates...

I want to allow the user to rearrange the columns in a multi-column listbox by dragging and dropping the column headers. Anyone already done this? If so, can you share the code? thanks, -John

Or, you could do something like this (if you are using Windows OS): If you need the IP address, get the AddressList from the IPHostEntry, index the first element and use ToString to convert it to an IP string.

Finally got around to signing up... Now if the NIWeek PO would just clear...

You must install your web services on the target. So, once you build your exe and your web service (lvws), you must build an installer and have it install the exe and the web service. Then, after you run this installer on the target PC, the web service will always be up and running. the default port for the Application Web Server (the one that hosts user generated web services) is 8080. So, all your calls must point to this port. You cannot assume the default port 80 will work. You can change this in the settings for the application web server on the target after you install, if you want. You could even make a batch file that the installer runs at the end to do this change automatically. I just decided to leave it on port 8080. good luck! -John

The first example I posted that uses the C# DLL is way faster than the NI toolkit (at least the version I tested it against. They might have improved it since then). You could easily adapt the ADO version to use the techniques in the SQL Server one. You would just need to modify the C# code to use the right assemblies. The key thing to the speed improvement is the way the recordset is returned to LabVIEW from the .NET memory space. One limitation of my version is all fields are treated as strings. I have not seen a speed change in .net calls from LV2010. They did fix some stuff between 8.2 and 8.6 I think. Not sure where the change was done but it was really messed up before. We have many 1000's of hours on this code with no problems. Just keep in mind the workaround in my code for the .net bug. If the SQL query length causes the string in .net to cross a memory boundary, .net will throw an error because it loses the null at the end of the null terminated string. New release of .net fixes this but LV2010 uses the old version. LV2011 *should* fix this. good luck!

If you need ODBC based access, try this code. It does not solve the record-set transfer issues, however, but you could adapt it using the techniques in my SQL server code. ADO.NET.zip Don't give up on .NET. it does offer a lot of advantages over COM.

Here are a few VIs and some C# code that might help you out. I do not recommend using LabVIEW to retrieve a record-set directly. There is a large penalty for using an enumerator across the LabVIEW<->.NET boundary. That is what the DLL fixes for you. There is also a fix in the VI for a bug in .NET 3.0 and earlier (it was fixed in 4.0 but we have to wait for LV2011 to use it). This involves strings that cross a memory boundary. Open: SQL.NET Open SQL Server Connection.vi Execute SQL: SQL.NET Execute Database Call.vi Close: SQL.NET Close Connection.vi C# DLL and source: C# SQL DLL.zip The source of the C# solution to moving data from .NET to LabVIEW came from Brian Tyler (the former .NET guru at NI, now at MS). Take a look at his blog posts: http://detritus.blog..._vs_arrayl.html http://detritus.blog...ng_the_arr.html Hope that helps! -John

Bummer dude. I guess it comes down to knowing what they want you to say and not what is the correct answer. I know on my CLD and CLA tests I used the most simplistic 'old school' way to solve the problem instead of how I would build it in 'real life'. NI's training and certification testing is at least 10 years behind the rest of us who build real LV solutions everyday. So, CLD/CLA top tip: Be smart, do not be clever. Oh, and demand a do-over. I think Steve will be happy to help you out there if you ask. -John

ni.var.io allows forcing outputs via property nodes but does not allow them to be read back. The shared variable VI reject a URL that uses ni.var.io. They accept ni.var.psp. Also, you cannot browse for anything under ni.var.io. Looks like it is time to call in the big guns at NI. BTW: I was able to get it to work somewhat by adding a 300ms delay after the write and adding a delay before the close. But, the value does not 'stick' in the DO. Once the close is called, the value reverts to false (off). If I remove the close, the value reverts when the VI stops. No idea why it wold 'latch' the value.

I am trying to read and write the digital output on an NI9476 cRIO device in an NI9148 cRIO chassis using the shared variable VIs. I want to create a generic driver that can access any cRIO hardware on the network provided I know the IP, module slot and port on the device I am interested in. I created a simple VI to do this. When I run it, I don't get any errors, but it does not appear to control the output I am targeting. Has anyone else done something simular? Is there something simple I am missing? This is the first time I have messed with cRIO. All our current setups use cFP but we are interested in changing to cRIO hardware in the future. Here is my code: thanks for any ideas! -John

If you are still waiting, I would be concerned they lost your test. I already got the shirt and framed the diploma!

I wonder how this works with FPGAs? Since these are hardware and more like a real circuit, I would suspect that some mechanism has to be put int place to create the effect of the sub-vi serialization.

How about just adding the 'Make This Case Default' option to the event case. If it is set, then that case fires when the registered event received does not have a case defined for it. This seems like the most consistent way to handle this and match existing paradigms. You could allow existing event cases to not have the default case for backwards compatibility, but all new event cases dropped will have the default case included and the dev will need to remove it to get back to the current behavior. That way, you are making a conscious decision to not handle all registered events with some case. Also, you could prompt the dev with a warning that unhandled events will reset the timer when they remove the default case. Finally, you could leave off the default case until they 'Show Dynamic Event Terminals', then add it at that time. To make it clear that it was added, force the event structure to display that case. Just my $0.02... [edit] Didn't notice a page 2 before posting. So, just add my suggestion to all the others for a default case.

I got these too! After about an hour, LAVA was working again. Mentioned it on twitter but @lavag could not reproduce.

In my opinion, the only thing wring with the Web UI Builder is the use of proprietary Microsoft Silverlight. If you were to output a site that would run using only HTML5, then it would work across all devices. The cost is also a bit of a barrier, but if I needed this for my project, I think I could get the company to pay. Not sure I like the expiring licence model, however. I think you should treat this more like the app builder and charge for the tool, but allow all output to be free to use and distribute.

I didn't even get a shirt! Is there someone I am supposed to call to get it?

There is a rumor that there might be other options in the future to 'stay current' with your CLA, besides taking a test...

Ok, I have spent some time reviewing your code. From what I can tell, you have taken the functionality of the channel class and moved some of it into the message parent class or modifed it to be specific to a particular message class. The channel class now has nothing to do. We could simply eliminate it at this point. The only thing it does do in your version is carry the state data for the process. This could easily be replaced with a SR carrying a variant. I see how splitting the messageQ class off on it's own simplifies the class hierarchy a bit, but as you acknowledged, it eliminates the automatic channel selection of the original architecture. But as you point out, the dev should know what channel they want to place a message one. With that change, why should the MessageQ be a class at all? Why not just have it be a DVR. That is all it is now. Having data accessors is not reason enough to use OOP in my opinion. One other problem I see is your design allows the dev to put a message on a channel that is not designed to accept that message. So, if you are worried about runtime errors, that is a big one. The original architecture would not allow this. In fact, as pointed out, it automatically chose the proper channel for you. If you were to eliminated the channel class and simply have a custom message class for each parallel process, you could enforce the rule of sending a message only to a receiver that can execute it. Also noticed that the release channel will not work because you based the queue type on the message class, not the channel class. Why not move the Create and Release into the message class since that is where you get the type to set the queue from? Seems like if you are going to move the Send there, you should move all of it. Wyt have them in the channel class at all if you just need to override them or rewrite them for each channel you create. That was one of the benefits of the original design: you could simply copy and rename the channel class and you were done. No need to touch any the the VIs. Overall, I understand you want to disconnect the classes from each other for 'good OOP design' reasons, but doing so in this case eliminates the functionality of the original design. I just don't see how it is better this way. My original intention was to encapsulate a parallel process and all it functionality into a single entity and then allow other similar processes to communicate with it without the need to modify the architecture when extending it. That is why in my view a channel and its messages are already linked together and there is no need to separate them. Perhaps it would be better to create explicit processes, like 'Database' and 'Display Driver' then attach child functions/messages to them, then have each create a queue and place it in a DVR that is passed around. That way, there is no master parent class and each process is not tied to the others, except when they want to pass a message in one of their functions using the queues in the DVR. I guess is all comes down to what should dynamic dispatch be used for? Should it be a way of enforcing a message passing system or is it only ok to use it for customizing functionality of a less specific class? I guess since I am new to this, I see this new tool and want to try using it for some purposes it might not have been intended for. Oh, one more thing, with the changes you made, the Tube no longer 'knows'. Perhaps we should change the thread's subject? Does anyone get my reference in the first place? Simpsons, Episode 407 at ~10:50. http://www.watchcartoononline.com/the-simpsons-episode-407-marge-gets-a-job

I'm not sure I understand how I can change this and maintain the functionality. By having channel inherit from messageQ and message inherit from channel, I can drop the 'send message' method from messageQ on the diagram, wire any message object into it, and the 'send message' will automatically change to the proper channel 'send message' method based on the hierarchy. This seems to make it easier for the dev since they don.t need to know what channel to choose. Also, the generic channel code only uses methods from messageQ that will be overriden by channel methods based on what type of channel is wired into the subvi. That makes the code to support a channel loop reusable. I can make as many channels as I want by simply copying this sub-vi and wiring in different channel objects. Also, channel needs access to messageQ data to find the proper queue. By having this data common to all channels, any channel can put an object in the queue of any other channel. I would like to simplify this but being new to LVOOP, I am not sure I see how to. Can you make a simple example of what you think can be done?

Made a few more improvements: 1. Eliminated the need for a stop message. I changed the channel execute method to set stop to true. Now, if you send the channel object as the message, it will stop the channel's loop. good idea or bad? seems cleaner to me. 2. Added an example of a message that accesses a channel's state data. Just implements a simple counter. 3. cleaned up the example diagram. Also, to implement a complex set of message types on a specific channel, I am thinking of using delegation so the implementation is decoupled from the MessageQ architecture. In this case the channel would have only one message type who's data type was the parent class of the implementation. Is that a good solution? I will have to add that to the example at a later date. MessageQ.zip

I hope this is a hint that FP improvements are coming soon. I know 2011 is a 'stability' release, but I really look forward to new UI components and a more powerful and easier set of tools to customize the FP. I know we can do anything we want if we write enough code but I don't want to have to write all the code to do some UI trickery. Oh, and I have not had any major issues with 2010. Actually, the Web Service improvements have been a big help vs all the problems I had in 2009. -John

+1 for the top down approach. I started in the middle, coding the larger modules first and leaving the details for the 'developer' later. But, I ran out of time to do the top level 'controller' code. Only got about 30 mins of work on it before time ran out. Luckily I got enough done to pass. The hardest part is reading through the requirements and getting an idea of what is required before starting to code. This exam is not designed to be doable in 4 hours. If I had 6 hours, I could have aced it. So, try to use your 4 hours wisely to get the most points. Don't bother worrying about finishing. Has anyone actually finished in 4 hours? (or at least thought you had finished) -John

Thanks guys! It's been on my to-do list for years (even been on my performance review at work to get this done!). Finally got around to it. I must say it was harder than I expected. Mainly in the time constraints. The works is straightforward, but I seem to be getting slower in my old age... Looking forward to the new options for maintaining my CLA. May have to do an NI Week presentation every other year...