wesramm

Thanks for the response. I'll have a look.

I started down the road of using this as it allows me to make a much more modern looking configuration engine for a large project. And, I'll be honest when I say that I LOVE reusable code. Makes my life easy!! However, have you anticipated the need to populate the front panel controls when you load the pages? I didn't see this implemented, and am wondering if I am just missing something. If you had this capability, where the page FP controls could be populated with the last values in the cfg file, it would make this the way to go. Thanks, Wes

I have had some old C code ported to C#, and am expecting to call that c# via a .NET assembly that we have built. The methods and classes visible in the Constructor node are VERY different from the methods classes that we have made public. For instance, in the .NET constructor (or in an Invoke node for a static class), I have visibility in LV to an internal class that isn't even public. AND, MOST of my public classes aren't visible from the .NET constructor node. In order to verify this, I have used a 3rd party .NET assembly viewer called Reflector. I have included a screenshot of the .NET assembly we have created when viewed both by Reflector and the .NET constructor on the LV BD. Pic 1: Screen shot from Reflector (3rd party tool for viewing .NET assemblies) showing a PUBLIC method called R3HistoryReader. I'd expect to see this when I look at the .NET constructor in LabVIEW Pic 2: Screen shot from LV .NET constructor when I reference the assembly showing both that my public method is not there, and an internal method is....?? Pic 3: Screen shot from Reflector again showing that the R3BinaryReader class is INTERNAL. I have built the .NET assembly to .NET Framework 3.5. When I open it in LV (constructor node), I get a message that it has been "Automaticall Promoted" by the .NET runtime engine.. I am assuming that it updates it to F the 4.0 Framework, which is not supposed to be compatible with LV. However, why are some Public Classes not visible in LV, and why are some Internal methods visible? I know that the assembly is structured correctly, as another .NET assembly shows the Public classes where they are supposed to be and doesn't see the internal ones. A 3rd party tool (Reflector) also shows the correct structure of the assembly with regards to the public and internal classes. What am I doing wrong here...??

LabJack is the way to go for this price point. Check out the U3 or U12. http://www.labjack.com Wes

QUOTE (Eugen Graf @ Jun 24 2008, 12:57 PM) I have the need for this functionality and am playing around with the alignment of the combo box on the table. Did you have to customize the combo box itself to achieve good registration with the table cells below? At best, my first cut looks poor. Your's looks nice.. Any tips? Wes

Roger that. I can live with this, as it is hardly a problem, just unexpected. Thanks for your reply. Wes QUOTE(Aristos Queue @ Mar 1 2007, 12:24 AM) Roger that. I can live with this, as it is hardly a problem, just unexpected. Thanks for your reply. Wes QUOTE(Aristos Queue @ Mar 1 2007, 12:24 AM) A) There's a known issue with building LVClasses into EXE/DLLs when choosing the various "remove" options. Classes were really intended to be coherent wholes and no provision was made for breaking them into pieces when building apps. It's being addressed, but for the time being, you have to include the typedefs (so that the private data control doesn't disappear) and not remove unneeded VIs (since the dynamic dispatch VIs aren't directly called by the caller VIs, the build system thinks they're not needed). B) Yes, the dynamic dispatch VIs save outside of the EXE/DLL. And, yes, it is cumbersome. The problem is that the DLL/EXE is effectively a single directory internally and so no two VIs of the same name can be saved inside the EXE/DLL. Of course, LVClasses almost always have two VIs of the same name -- that's how overrides work. So as a workaround, we made the dynamics save outside of the EXE/DLL. The diagrams and panels are stripped, as you noted. A future version of LV should address the file name limitations of EXE/DLLs.

Hello everyone, I have a client who wants to use the Windows Presentation Foundation (WPF) to provide a front end for a scientific instrument that we are creating. Below that, he wants to create an XML-configurable sequence engine written in c# and .NET to operate the instrument, calling LV vi's as packaged libraries to serve as instrument and analysis drivers. So, I have to find a way to interface my LV vi's with his C#. Our concept is to use Object Remoting, and setting up my LV VI's in such a way that they are callable and compatible with his architecture. Of course, the way that LV is set up is to CALL .NET assemblies, not to PROVIDE .NET assemblies, so this is a tricky one. Any ideas? Wes

Hello, I have an application which on the top level must 'talk' to several different instruments; a LabJack UE9 (USB) , a Newport Motion Controller (USB-Serial), etc. When I wrote the drivers for these instruments in LV, I used the LVOOP functionality and created individual Classes with public methods for each of the different devices I need to communicate with. Sounds logical to me, anyway. In my top-level application, I call the public methods (and must include local instances of the LVOOP classes) for those independant instrument-specific classes. In the development mode, everything works peachy. However, when I go to build the application executable (build), I get some weird behavior; Firstly, with the default setting in 'Additional Exclusions' in the Build Properties of 'Remove as much as possible', I get errors when the builder gets to my independent classes. I get the message: "An error occurred while building the following file: C:\Documents and Settings\Wes Ramm\My Documents\Projects\RDT\LabJack\Class\Common Methods\Get DO Line State.vi The VI became broken after disconnecting type definitions. Open the Build Specification and choose a different option on the Additional Exclusions page." Ok, it seems that the class object is not linking, but I can get around that by selecting the second option in 'Additional Exclusions' ; 'Remove unreferenced project library members'. BUT, when the build is done, I get a couple of subdirectories with vi's named for all the different class methods for each independent that I am calling. There is no front panel or block diagram for the vis, so it looks like they are correctly 'included' in the build, but it seems cumbersome to include these subdirectories. I even tried to 'add' the independant classes to the project by 'Add Folder', but got the same behavior. The classes that I made are not a part of the top level VI, and the top Leve VI is not a member of any of the classes, so this I think is the crux of the matter. However, I am instantiating only the public methods, and the problems only pop up when I try to build the executable. Am I missing something? Is there a more elegant way to do this? Any advise / tutorials / knowledgebase articles you can point me to? The tree for the directory structure for my build looks like this (for reference) \\Application Directory\ Executable \Config \ Class One.lvclass (first external class that I am calling in my top-level vi) \ Method 1 \ Method 2 \ Method 3 \ etc \ Class Two.lvclass \Method 1 \Method 2 \Method 3 \ etc

TEST ENGINEER Location: Waterford, CT Education: BS Engineering (Mechanical, Electrical, Ocean or equal) Experience: 3+ years Description: Support the Principal Test Engineer with the development of automated test systems by performing the following specific tasks: • Design/ develop LabVIEW or LabWindows/CVI software • Integrate commercial test equipment • Design custom electro-mechanical assemblies Qualifications: Demonstrated experience with the design of complex LabVIEW or LabWindows/CVI based interactive supervisory control and data acquisition (SCADA) systems. Experience with the following desirable: • Automated Test Systems • Motion Control Systems • Data Acquisition Systems • Vision Inspection Systems • PLC Programming • Process Automation • Experiment Automation • Data Analysis and Reconstruction • National Instruments Test Stand software • Design of electro-mechanical components/ systems • Experience with 3D modeling tools such as SolidWorks • LabVIEW Developer certification a definite plus. Must be a U.S. citizen eligible for a government security clearance. Send resume to Sonalysts, Inc., 215 Parkway North, Waterford, CT 06385; recruiting@sonalysts.com. Reply to Ad 1007. EOE/M/F/D/V Drug Testing Employer www.sonalysts.com