Jeff Plotzke

Thanks. Talked with NI and it turns out that this issue (CAR 447058) is fixed in the 2013 SP1 f1 patch. I've installed the f1 patch and my assembly works fine now.

Daklu, Were you ever able to get to the bottom of this error? I'm having the same issue. I've simplified my code down to a very basic lvclass and still get an exception thrown anytime there's both an input and output of a class as you've shown. Using LV2013, VS2013, .NET 4.0. I've created the lvclass Vehicle, which has 3 methods: initializeVehicle -- Returns a LV class object. setMakeModel -- Inputs strings for make and model and stores in class private data. getVehicleFullName -- Concatenates the make and model strings from the object and outputs the concatenated string. I call this from a simple C# console application: VIE.LVClassTest.Vehicle testVehicle;VIE.LVClassTest.Vehicle.initializeVehicle(out testVehicle);VIE.LVClassTest.Vehicle.setMakeModel(testVehicle, "VW", "Golf", out testVehicle); string vehicleName = "";VIE.LVClassTest.Vehicle.getVehicleFullName(testVehicle, out vehicleName, out testVehicle);Console.WriteLine(vehicleName); I get a VIAssemblyException at the setMakeModel function saying: "Failed to convert the LV Class to the .NET class because LV cannot get the LV Class Instance." The function initializeVehicle works fine. As a test, I also tried calling the .NET assembly in LabVIEW: I also get the same exception thrown at the setMakeModel invoke node. Probing the outputs for the functions, initializeVehicle returns a valid refnum, however setMakeModel returns a null refnum. Any thoughts? Thanks! (Also cross-posted as a reply on NI forums here: http://forums.ni.com/t5/LabVIEW/Problems-exporting-a-LVOOP-class-to-a-NET-interop-assembly/m-p/2801694#M821666 )

Another note is that you can take most PCI DAQ cards and use a RTSI cable between them to add the synchronization layer that PXI provides. It's the poor man's PXI and doesn't give you the convenient form factor PXI provides, but allows you to do synchronization between your DAQ cards on a desktop. What is RTSI: http://digital.ni.com/public.nsf/allkb/A120195AAAA9222A86256C69007C8B27

Thanks for noticing this -- We're currently re-organizing the Code Repository guidelines for LAVA 2.0 and don't have them up yet. We'll have that posted this afternoon and then those links will work.

A PXI backplane is essentially a PCI bus with added signals for dedicated timing and synchronization. I'd use PXI if you're specifically looking for synchronization between cards. Other than that, and being different form factors, there's nothing else largely different between the two. PXI systems run either with an embedded controller (which typically run Windows, but could also run an Real-Time OS) or can be linked to a PC using an MXI cable. You'd program in LabVIEW the same you would on a desktop. Here's a page that describes PXI: http://zone.ni.com/d...a/tut/p/id/4811

At the bottom of every page, there's a "Mark Board as Read" link that will wipe the "View New Content" content. Is this what you're looking for?

We've disabled the option to select your own skin for the site -- I've set your profile back to the normal skin.

Google's cache has been keeping up and started caching the LAVA 1.0 'Offline' page about a week after it went offline. But, we should have all of the missing pieces back up on LAVA 2.0 now -- Let us know if you see something missing. Thanks!

Because the second item in a list is always the coolest! I just turned off the B) shortcut for it. Lettered lists should work normal now

QUOTE (Yair @ Jun 3 2009, 02:34 PM) We'll definitely post our presentation along with notes and suggestions gathered during discussion at NI-Week for those who aren't able to attend. Is there anything in particular you'd be looking for in this presentation?

QUOTE (Thang Nguyen @ Jun 2 2009, 05:23 PM) If you're trying to do automated testing or control of your application, I've used AutoIt3 before (jlokanis also brought this software up in his post). AutoIt is a sort of scripting language where you can define mouse/keyboard events, looping, file manipulation, display interaction -- you name it. This software can do a lot. In my application, I needed to test running my application with about 50 different configuration files. I pre-made the configuration files and then had AutoIt automatically copy a new configuration into the application directory, run my application, wait for it to start, click the Run Test button, wait for a pass/fail indicator to turn red or green, then click the exit button, and then start again with a new configuration file. After about 10 hours (and several beers since I didn't have to sit next to the tester ), I came back and only had to look at log files generated from my application. That said, the button clicks were done solely based on a command in the script that said "do a single-click at coordinates 123, 345 on the display") -- I couldn't actually pass in the button name or the like. I had to do several test runs to smooth everything out. Perhaps this is up your alley. Best of all, AutoIt is open-source (read: free).

Christopher Relf and I will also be co-presenting another topic at NI-Week: "Software Engineering with LabVIEW from Requirements to Deployment". Focused on V-Model development from requirements to traceability through the product development cycle, we'll be discussing how to incorporate National Instruments tools (Requirements Gateway, Unit Test Framework, etc) to ensure quality in your projects. I'm also planning on walking through regulated industry case studies and how this process easily maps into these regulations. Note that this is meant to be an advanced session and I don't want to turn this into a sales presentation. What would you value most in a process-oriented presentation? How many of you have used NI tools in order to more closely tether your requirements and design to your development? Do you currently struggle to maintain a V-model development process? Thanks for any of your feedback!

I can't believe this... this is from a REAL TV show in Japan meant to teach "useful" English... http://en.wikipedia.org/wiki/Zuiikin'_English

QUOTE(crelf @ Jul 11 2007, 11:12 AM) I would say using a tab is much better, especially for numerical data. Throughout Europe (and other countries) where a comma is the decimal separator, a comma delimeted spreadsheet could turn into a nightmare! I typically only use tabs for delimited files.

QUOTE(Kalitexnis @ Jul 6 2007, 06:46 PM) tune2fs should be located in the /sbin folder -- Which you may not have located in your PATH variable. Try executing "/sbin/tune2fs" instead. (and as osvaldo mentioned, you'll need to be root)

QUOTE(DDAdevil @ Jun 20 2007, 11:48 AM) What about LabVIEW Remote Front Panels?

Oh my! Where is that from? That almost reminds me of the traffic in Italy... but this looks worse!

Just passed 2000 posts... Soon, he'll be 500 posts past Michael, the 2nd top poster... Anyways, congratulations Chris! Now, why don't you slow down and give the rest of us a chance to catch up!

QUOTE(rolfk @ Jun 10 2007, 06:07 PM) I assumed that "SOFTWARE" meant LabVIEW (and other included NI software)... not executables created with LabVIEW, but I'll have to read the license to find out for sure... QUOTE(rolfk @ Jun 10 2007, 06:07 PM) Your test shows most probably nothing. The only code your dissassembler can see is the startup stub that loads the LabVIEW runtime system and then passes the reference to the internal LLB to that. The machine code located in the VIs inside that LLB, can only be located and invoked by LabVIEW. There is no disassembler that could possibly know how to find the LLB, not to speak about the VIs inside it nor the LabVIEW generated machine code in each VI. Basically every LabVIEW executable of a given LabVIEW version will give you exactly the same assembly code. You're absolutely right -- I just created a considerably different VI from what I tested with originally... and *cough* *cough* *cough* -- The exact same disassembled code was created. That's interesting... So, does this mean that a built EXE actually contains some intermediate language (in the LLB) that's interpreted by the runtime engine or does LV actually generate the machine code while it builds?

QUOTE(dbyers3 @ Jun 8 2007, 10:23 AM) Perhaps there's an easier way... but running 'ping localhost' gives the local computer name: "Pinging <computername> [127.0.0.1] with 32 bytes of data:"

QUOTE(crelf @ Jun 7 2007, 04:30 PM) This looks like it's false and it doesn't make any difference... I just created a quick VI that contains a subVI. I originally set the connector on the subVI as optional... then built the application as an EXE. I then used a Win32 dissasmbler to convert the EXE into an ASM file. Then, I took the subVI, marked the connector as required, built, and disassembled again. I did a compare between the two disassembled files. No difference. The files were identical. I did this several times and tried also with dropping down the subVI several times on the BD of the top level VI. Still in all instances, changing the connector pane between optional or required made no difference in the EXE produced.

QUOTE(crelf @ Jun 6 2007, 12:10 PM) That would in interesting... a LabVIEW fiction book... "It was a dark and stormy night. Sounds of PXI fans whirled in the darkness. Jeff could feel someone watching him as he watched his comma delimited text file convert into binary..." Hmmm... on second thought... maybe not.

...and if you're looking to make a profit... you'll probably make more with Google ads on a blog than you would with publishing a book...