Tim_S

I agree with drjdpowell. I was worried about (potential) overhead with the VIs that were not displayed when I implemented something similar, so I assigned an index number to each of the VIs, and provided the index and an "Active Index" event that could be registered. The event sends the index number of the VI that is displayed in the subpanel, so it allows VIs to throttle back when they are not visible.

I've had two event structures on the same diagram, though I can't say this is common for me. It's a nice way to create a producer-consumer where the consumer needs to accept different data messages; I'm not a fan of using a cluster of enum and variant as I've been burned by all of the enum constants resetting to the default value one too many times. The other situation I've used it is when the second loop can be stopped by a button press on the front panel.

Have you looked at: https://decibel.ni.com/content/groups/large-labview-application-development/blog/2011/05/08/an-approach-to-managing-plugins-in-a-labview-application

Building the parent class into a packed library, and using the packed library parent in the child class and application should resolve many of your issues. I've not had issue passing references, though I've not tried a file reference. Based on the error, I'd guess there are other issues that are breaking the compiled child class. One downside to classes is a broken VI/control in the class will break the class and all VIs/controls in the class.

It doesn't help trying to tune when the implementation does not match the learned theory. Take, for example, tuning drives. The few times that I've been involved with the tuning, the proportional and derivative have been unit-less values and the integral in milliseconds (specifically, the rate at which the PID was calculated). As an aside, I just got out of a sales pitch during which the hardware expert described the controls drawing of their PID controller as "something the Austrians came up with while drinking one night".

Are you using source code of the parent in both the child and the application? I'm not clear on the internal workings, but this is what I've found experimentally (so take it with a grain of salt). Building the packed library creates a new identifying information when you build the packed library, so, even though you have the same parent object, the identifying information for the parent object is different, so LabVIEW treats them as different objects, hence giving you a broken wire.

The only data type that I've found that cannot be used is an xcontrol, but that's true of objects in general (http://zone.ni.com/reference/en-XX/help/371361J-01/lvhowto/defin_priv_data_class/). I did have some issues with typedefs, unfortunately, I'm scratching my head as to how or why. What I had to do with creating an executable as the main application is to build the parent class and associated typedefs as a packed library. The parent object in the library is used by the child object and the executable. The reason I had to build the parent packed library was: 1) I wanted non-core code developers to be able to add functionality, and 2) I was having errors loading the child object once I built the application as an executable. The errors seemed to be related to the build creating a new unique identifier for the parent object than the source code. (This was LV2011.)

If you're trying to communicate to an OPC server, then you should be using Datasocket, not VISA (http://zone.ni.com/reference/en-XX/help/371361K-01/lvhowto/openclose_ds_conct_prog/).

Use an XY Graph.

As a note for making inline VIs... I've been building plugins using objects in packed libraries. Object properties that are set to inline have thrown packed-library build errors. I don't believe I have any other VIs that have been set to inline when performing the builds.

This looks suspiciously like a homework assignment. I would recommend trying to solve the problem yourself and post with specific problems you are encountering.

I'm not too familiar with the Actor Framework yet, but are your actors/tasks in memory or do they need to be loaded when the user clicks the button?

FYI... There is an open source community for LeapMotion: http://openleap.org/

Alone? No, this looks like a support group forming. I resisted the urge to go realign every VI in a project after moving from a XP to Win7 machine (yea, I use the default fonts).

Have you tried restarting LabVIEW or restarting the computer? I've had that solve a similar error.

I still find FGV to be a useful tool even in current code. I also am not always working with recent versions of LabVIEW; I'm currently working with a customer with equipment we built in LabVIEW 7 and had one customer several years ago that wanted an update to their LabVIEW 4 code. (The days before undo... )

Unfortunately my current experiment, a grow your own minion home kit, seems to be sucking all my resources for the foreseeable future.

I'm not sure how prevalent my use case is, but all that copy, paste, wire, etc., took a couple hours that a for-like structure would have made much faster. The code takes multiple screen-heights, so anything that could reduce the code sprawl and make it more readable would be a big plus.

I can only relate my own experience as well; Advantech is huge and different groups within Advantech may give you different results. We switched to Advantech for industrial computers for price and issues we were having with the previous supplier we used (~15+ years ago). We had the same sales person for quite a few years and service was good. After that person left, we had calls to the sales person (who never seemed to last more than 6 months) that would be weeks later or go unanswered (including calls requesting quotes). There was a rash of bad PCI bridges (this affected everyone) some years ago. Those were resolved quickly by technical support, but getting the computer back from the repair center was supposed to be 2 weeks; we had to make multiple phone calls over several days at 3 weeks to find out what was going on. We had a rash of bad hard drives and worked out an additional build and burn in procedure that we paid extra for, but was never followed. That was pretty typical of our experience. We've had our current supplier, who is twice the price, for about 4 years now, but the salesman calls me back, everything shows up fully tested as standard procedure for them and typical turnaround on anything I've had to send back is about a week to week-and-a-half.

I've been keeping an eye on this as it looks like an interface with lots of potential. (Unfortunately, I don't have one to play with. ) I've seen two reviews that may be helpful: http://www.theguardian.com/technology/blog/2013/jul/29/leap-motion-review-i-want-my-hoverboard http://arstechnica.com/gadgets/2013/07/hands-on-with-the-leap-motion-controller-cool-but-frustrating-as-hell/ There seems to be difficulty with extraneous light and arm fatigue.

As much of a pain as it was to copy/paste, the code operates in a single clock cycle. Would the alternative methods be able to do the same?

I have FPGA code where I take 54 quadrature inputs (A and B phase) and determine linear encoder position. This has a very long I/O Node, followed by 54 instances of debouncing subVI and quadrature-decoding subVI, followed by all 54 encoder positions put into an array (Replace Array Subset). Each of the linear encoders also has an error line, which has 54 inputs geting packed into three U32s. (The encoder positions and status values are DMA-ed off to the PC at internal or external clock intervals, but that's not important here.)

Since you're posting to a LabVIEW-centric forum, I expect people are going to recommend NI hardware such as their cDAQ. I've used plenty of Advantech PCs and wasn't even aware they sold data acquisition hardware. Based on their support with their industrial PCs (poor knowledge of technical person, very long time to return calls, changing sales reps every 3-6 months, and very long repair times), I'm not inclined to use their DAQNAvi hardware.

Hrm... My initial thought is that the resource may not be available at the moment that the read occurs. The zero timeout wouldn't permit the read to retry when the resource becomes available.

I ran across a bug in LabVIEW 2012 the other day. This does not exist in LV 2011 or prior. The CAR is 416470 if you want to track it. The bug occurs when a subVI has a Get Waveform Attribute with the default value terminal wired to a control. What appears to happen is the Get reads the value which can be seen on an indicator connected to the value connection of the Get Waveform Attribute primitive, however the calling VI gets a default value (in my case an empty string) instead of the value at the subVI's indicator. The workaround is the either use a constant for the default value, or put a Always Copy primitive between the Get Waveform Attribute and the indicator. What I believe technical support was trying to explain to me (as he wasn't quite sure what was explained to him, so take this game of telephone for what you will) is the memory location of the control is reused for the indicator rather than creating a new memory location. This prevents the calling VI from reading the memory location of the indicator as one was never created.