crelf

I hope this doesn't end up like Fracking.

More like fraking.

Not a joke, we're trying to drill to the center of the earth: http://edition.cnn.c...sion/index.html

"It will be the equivalent of dangling a steel string the width of a human hair in the deep end of a swimming pool and inserting it into a thimble 1/10 mm wide" --Damon Teagle, University of Southampton, UK

That's what she...

(crelf: no TWSS jokes out of this quote are allowed)

oh... nevermind.

Seems like Mike's active in the VIPM Idea Exchange - things are changing their statuses - might be an indication as to what to expect from near-future versions of VIPM...

Oh, and while you're there, please vote for this and this

Cameras showed up in MAX no problem, but both MAX names would, if selected, lead to images from only one of the cameras. It’s was driver issue, at a lower level than MAX.

Ugh - that's ugly.

I think I’ve seen it with NI-IMAQdx. It’s only with some USB cameras, such as webcams. And it is only when using identical models; one can use multiple cameras of different models, because they go into the Registry under their model names.

If you're using IMAQdx, it uses the names listed in MAX, not the registry, so this shouldn't be an issue.

Had that problem. I believe it is because the Windows software was never made to work with multiple cameras at once. Each identical camera is listed in the Windows Registry under identical names. I believe you can modify the registry, but that is not a satisfactory solution.

Really? I've got it working just fine on my PC.

I wonder: are you using NI-IMAQdx? Or something different?

You can change their names in MAX (Measurement & Automation Explorer). Go to "Devices and Interfaces", then "IMAQdx" (this might take a few seconds to show up as it scans for cameras), then your cameras should be listed - you can right click on them to rename them there.

I can post my code (somehow ugly...

All* of our code is ugly at times

*Well, expect for mine, of course.

...several years ago I went spelunking...

That's a great term for some of the code I have to deal with occasionally.

So as per my post, I modified the code so that LabVIEW now handles closing the step VI references itself. Hey presto, the resetting message has not been seen since. Previously the error occurred every 4-6 hours. Now after 30 hours, no problem.

I'm not surprised. I mean, LabVIEW shouldn't get into the tub-of-war that AQ descriobes above, but I'm not surprised that not closing refenences put you there.

Glad to hear you've got a work around!

The LabVIEWWiki tells us that the defaultConPane key should work for new VIs. Are you saying the LabVIEW.ini file reverts after you make changes and save it?

...we occasionally see a message 'Resetting VI: <step name>'. Debugging is very difficult.

And what's the real impact? Does it show up for a second and then close itself? Does it show up for 5 minutes? Forever?

I'm implmeneted the user manager a few times and haven't had any issues - maybe you're not closing a reference somewhere? Can you post your code? Or, at least, trim it down to as little as possible where the issue still occurs (make a little example) so we can fault find.

lots of other arguments to make here but hand is tired...

You know, if you programmed graphically it wouldn't hurt so much.

More people would use them if they were more usable.

I guess everything makes sense if you don't think about it.

Yes, I know I'm probably the only person in the world that enables the warnings view in the Error List, but I'd like to be able to selectively ignore certain warnings. Read more here.

If you just want a custom extension there is no issue, just no other application other than yours will know it is a TDMS file so you will limit what will open it directly.

Right - we have a couple of projects that just use *.bin (or something more appropriate to show it's related to a project) so ppl are less inclined to accidentally find out that it's TDMS.

I think you've been hanging around hardware guys too much...or management...or sales.

...or marketing...

Any ideas what makes up the performance gap between Debug and Debug + PWD?

I second this question. I know it's not the original intent of the thread, but I think it might make for interesting reading...

How about a hook into LabVIEW to allow developers to add their own right-click menu items similar to the "JKI Right Click Framework"?

Mwwwuuuuhahahaha!

Christina, asking us to vote on menu items probably won't work. None of the menu items will garner enough votes to get on NI's radar.

How about this: select two items that are the same (eg: 2 strings), look at the list - implement those. Repeat for all node types

Unfortunately, that is what I'm saying. There is, as it turns out, a reason why we went without multi-select right-click menus for so long.

OK - I'd figured as much.

I don't think of it as "done"...

Well, you might not think of it as "done", but your new feature list suggests otherwise

Your example was with two string constants, so that's what I tested, which only had the two items you showed "Visible Items" (not labels), and "Properties". 2011 has "Properties" but not "Visible Items", so I was confused.

Yeah, sorry - I should have made that it was just one example. There's several difference between many items, and even shared stuff between less-like items. But there's still not as much as I'd expected for like (and, well, same) items...

Unfortunately, the reason that this doesn't work the way you expect is that it was a lot more expensive to implement multi-select right-click menus than you would think.

We don't have plans to put every right-click menu option into the multi-select menu framework, but if there are specific ones that you think have high value (e.g. common operations, operations not in Properties) then please let me know or propose it on Idea Exchange and I'll see what we can do.

That makes is sound like you're implementing each and every item one by one? Wouldn't it make sense to just compare the items, and, if they're the same, allowed everything *but* restricted items? I guess it could be a similar impact, but my gut is telling me that the latter would be more efficient.

Or are you saying the current architecture of the LabVIEW source code won't lend itself to that without a major re-write?

I also wanted to mention that I didn't think this was a "new" feature.

Actually, it was new in 2012 - see Productivity Improvements > Right-click menu option for multiple selected items. I was really excited about it when I heard this was coming (and it is neat on some things - try selecting multiple FP controls, right click and create references - BAM!

I think the only new thing NI added in 2012 was the visible labels.

I'm not sure what you mean by "visible labels", but there was a bunch of improvements in 2012, with some of them being in the IDE: http://www.ni.com/labview/whatsnew/

Ugh - I just realised that link would be overwritten with other stuff when 2013 comes out For perpetuity, here's a copied list from that link:

Productivity Enhancements

Stability Improvements

Support for Single-Precision Floating-Point Data Type on FPGA Targets

Templates and Sample Projects

Right-click menu option for multiple selected items

Specify default label position for controls

Specify default label position for constants

Specify default label position for indicators

Automatic concatenating arrays leaving loops

Conditionally process loop output

Quick drop shortcuts for label positioning

Remove broken wires from selected area

Edit string constant dialog box

Subdiagram label for block diagram structures

Support for Arrays in High Throughput Math Functions (LabVIEW FPGA Module)

Support for Arrays and Clusters in Single-Cycle Timed Loops (LabVIEW FPGA Module)

New SoftMotion Express Vis (LabVIEW NI SoftMotion Module)

Contour Express VI (LabVIEW NI SoftMotion Module)

Improvements to the IMAQ Learn Camera Model VI (NI Vision Development Module)

Improvements to IMAQ Learn Distortion Model VI (NI Vision Development Module)

The Data Matrix, PDF417, and QR barcode reading steps are now combined into one Read 2D Barcode step (NI Vision Development Module)

Configure Steering Frame Express VI (LabVIEW Robotics Module)

Take Simulation Steps VI (LabVIEW Robotics Module)

Initialize Serial Arm VI (LabVIEW Robotics Module)

Acquire Kinematic Parameters VI (LabVIEW Robotics Module)

New Functionality in Get Simulator Reference Polymorphic VI (LabVIEW Robotics Module)

Additional modes for Start Simulator Service VI (LabVIEW Robotics Module)

Wait Until Done VI for Synchronous operations (LabVIEW NI SoftMotion Module)

Generate motion profiles with new Solve Profile method (LabVIEW NI SoftMotion Module)

Motor Control VIs for brushed servo and stepper motor controllers (LabVIEW NI SoftMotion Module)

Programmatic table creation for contour moves (LabVIEW NI SoftMotion Module)

Programmatically set axis properties (LabVIEW NI SoftMotion Module)

Analysis

Convex Polygon Intersection VI

Polygon Centroid VI

LabVIEW GPU Toolkit

LabVIEW Sparse Matrix and Advanced Analysis Toolkit

LabVIEW Biomedical Toolkit

Support for Cell Arrays (MathScript RT Module)

Organize multiple data-types with a single variable (MathScript RT Module)

New properties for cells class (MathScript RT Module)

New properties for structs class (MathScript RT Module)

Access Model Hierarchy function (Control Design and Simulation Module)

Output Node of the Control & Simulation Loop (Control Design and Simulation Module)

Support for stiff ordinary differential equations (Control Design and Simulation Module)

Support for differential algebraic equation solvers (Control Design and Simulation Module)

New Model Hierarchy palette for configuring model parameters (Control Design and Simulation Module

New Controllers palette for linear models (Control Design and Simulation Module)

Delay input by discreet time steps (Control Design and Simulation Module)

Specify type of algorithm to use for solving the Riccati equation (Control Design and Simulation Module)

Nyquist VI can separate contours for positive and negative frequencies (Control Design and Simulation Module)

Margins function returns gain, phase and delay (Control Design and Simulation Module)

Support for binocular stereo vision (NI Vision Development Module)

Support for advanced Data Matrix parameters (NI Vision Development Module)

Multitone API (LabVIEW Sound and Vibration Measurement Suite)

Signal Generator API (LabVIEW Sound and Vibration Measurement Suite)

Single-Plane Balancing Application Example (LabVIEW Sound and Vibration Measurement Suite)

Data Communication

Web Services Management page

Shared variables accessible via web services

HTTP / HTTPS Client VIs Included

FTP VIs Included

Interoperability Improvements

TDMS Advanced Data Reference I/O palette

TDMS Streaming VIs and Functions supported on Mac and Linux

Import Industry-Standard CAD Robot Models (LabVIEW Robotics Module)

Improved Support for Common Types of Robotic Arms (LabVIEW Robotics Module)

Generated .NET Interop Assembly Improvements (Application Builder)

Generated Shared Library Improvements (Application Builder)

Create installers that define an executable to run during uninstallation (Application Builder)

Performance Improvements in Building Applications (Application Builder)

Build API supports Project Reference (Application Builder)

Support for the ISO 15415-2004 and AIM DPM-1-2006 Data Matrix grading standards (NI Vision Development Module)

Support for the ISO 15415-2004 and AIM DPM-1-2006 Data Matrix grading standards (NI Vision Development Module)

New shortcut for starting and stopping SolidWorks simulations (LabVIEW NI SoftMotion Module)

Advanced Environment Improvements

Support for the FPGA Interface from LabVIEW 64-bit Host VIs

Probes for additional data types

Configurable path truncation display

Additional data type details in Contextual Help Window

User configurable compiler settings

Separate compiled code for Express VIs

Separate compiled code for custom controls

Separate compiled code for LabVIEW classes

Separate compiled code for project libraries

Separate compiled code for statechart libraries

Separate compiled code for XControls

Dialog box enhancements

Redesigned properties dialog for front panel Panes

Error ring constant

Event driven programming in Base Package

Polymorphic inputs to Mean VI

Specify initial element value for 'Complex Queue PtByPt' VI

Specify initial element value for 'Data Queue PtByPt' VI

New and changed VI Server classes, properties, methods and events

JKI VI Package Manager Installer Included

Compile Worker Support for Linux (LabVIEW FPGA Module)

New Rangefinder Indicator (LabVIEW Robotics Module)

Object-Oriented Improvements

Actor Framework 4.0 included in vi.lib

Actor Framework Message Maker

Pseudopath input for 'Get LV Class Default Value VI'

Improved Support for LabVIEW Classes on FPGA targets

Performance Improvements and Optimizations

Performance Improvements for Unused Inline SubVIs (LabVIEW Real-Time)

IP Builder for LabVIEW FPGA

Additional Control over Memory Implementation for Array Constants (LabVIEW FPGA Module)

Improvements to DMA and Peer-to-Peer FIFOs (LabVIEW FPGA Module)

Improvements to Storing Data across multiple clock domains (LabVIEW FPGA Module)

Improved performance of FIFOs in a single clock domain (LabVIEW FPGA Module)

Optimizations for parallel execution of vision analysis (NI Vision Development Module)

Not always written. A lot of the time it is just meetings and I have to write the requirements then get them to agree to them. Amazing some of the u-turns people make when they see what they've asked for in black and white.

Right - we rarely use a customer's requirements document - they usually give us a "specfication" that we write traceable requirements to, which we then have them argee to (so we're all on the same page) - and it's that requirements document that we test to.

PS: I'm still convinced we're talking about different things, but that horse is already dead and starting to smell.

Nope. It's software. It's comparing apples to apples.

Nope, we're comparing products to services - apples and oranges

Indeed. However, that can be in parallel with the development cycle where the customers frame of reference is a solid, stable release (rather than a half-arsed attempt at one). If you operate an iterative life-cycle (or Agile as the youngsters call it ) then that feedback is factored in at the appropriate stages. The "Alpha" and "Beta" are not cycles in this case, but stages within the iteration that are prerequisites for release gates. (RFQ, RFP et. al.)

I like to think that the Agile process (not that I've ever seen anyone implement a true Agile process FWIW, but there are plenty of people who will tell you that they do ) and a vee model with added alpha/beta stages tracks relatively closely.

Well. If it takes three years to fix something like that, then it's time for a career change! If you know there is a problem, then you can fix it. The problem is that it takes time/money to fix things and the culture that has grown up around software is that if they think they can get away with selling it (and it being accepted); then they will.

Agreed - I can't argue with that Unfrotunately (and I"m not talking from any direct experience here) market forces can make or break companies in this situation, so there can be a business gamble here. I work in regulated industries with well structured processes, and customers who respect that, so there's not a lot of room for such shennanigans, but that doesn't mean it doesn't fit other fast turn around markets (like iPhone app stores, or, since you're an Android guy (as am I), Goolge Play.

If the apps are written by any script kiddy with a compiler and given away free, then, basically, you you get what you pay for.

Sure - and I'd prefer an app that was written by a script kiddy who went through a formal alpha and beta over one who didn't. But again, that's a different market than I'm used to professionally - we have customers who pay for custom solutions, which means we sell services, not products. That said, some of those services come with products inside them. If we're only talking about services, then I'm more inclined (but not totally) to agree with you. If we're talking about products, then I'm all for alphas and betas. That's what I meant about models fitting inside each other (as a side note, sorry to harp on this, but if someone says they use the Agile model, they might use portions of it at some level in their process, but probably use a vee above it, and maybe an iterative below it - see what I'm getting at?)

The phrase "Good enough" is exactly what I'm talking about. Good enough to get away with? Sky scrapers aren't perfect, but they are "fit for purpose", "obtain an level of quality", "comply with relevant standards", "fulfill the requirements" and don't fall down when you slam a door . The same cannot be said for a lot of software once released, let alone during alpha or beta testing.

Rather than comparing a software app to a skyscraper, let's try something a little more apt: a software app to, say, a power supply. If I'm designing a power supply, I'd like to think I'd make a prototype before final release that I might get some of my key customers (whether they be internal and/or external) to play with and give me feedback on. I think that probably makes sense. And I think "alpha" and "beta" can be analogous to "prototype" in the product world.

I'm not commenting on your products. Just the general software mentality that, at times, makes me despair.

I should hope not - I don't think you've ever seen any of them - in alpha, beta or otherwise I agree that there's a trending mentality toward treating beta testers as free bug finders, and that, with the availablity of easier release platforms (think AppStore and Play), the temptation to release software that clearly isn't ready but not marked as such for the purposes of getting free bug testing, is becoming rife. In that, I agree with you wholeheartedly. BUT I won't accept that that means all alpha and beta testing stages of products is immoral. Both sides need to be fully aware of the consequences, and choose to opt in to such programmes. I'm warning that (again, we're talking about products here, not services) ignoring early drop techniques can lead to software that meets the requirements, but leads to unhappy customers. We have several customers who jump at the chance to pay for an ECO to change requirements while we're developming (that's a whole other discussion), but it's only during prototype demos/betas that they have the opportunity to think those changes up. And then it's on them if they want to pay for said changes.

It's not a "goal".It is a "procedure" and the general plan works in all industries from food production to fighter jets.

Sorry, I should have been more clear: I was referring to services vs products.

The "goal" is, in fact, that the first time they see it IS the last time they see me.

Then I guess we philosophically disagree. I prefer to work closely with the customer during the project to make sure everything aligns to thier expectations (if possible, of course ) though all stages of a project's execution. As I alluded above, I prefer not to drop something in their lap that meets all of their initially defined requirements, but doesn't fit thier needs.

Public Alpha and Beta testing programmes (I'll make that discrimination for clarity in comparison with the aforementioned development cycles) are not a "tool" and are peculiar to software and software alone. They exist only to mitigate cost by exploiting free resource.

And we circle around to the start: as long as both parties understand and agree to the terms of a alpha or beta testing programme, I see them as very powerful tools.

God help us the day we see the "Beta" kettle.

I see no problem with a "prototype" kettle

Happy clients? I have some unobtainium for sale...

I'm not saying it's easy, but I know it's not unobtainable. Well, maybe it is for some customers