Grampa_of_Oliva_n_Eden

Thanks everyone.

Live in Raleigh, work in Durham, NC

...

Any chance of a Raleigh branch opening?

With the right person leading it, yes.

Please note: I am not management and I do not speak for them.

Take care,

Ben

I hve to update my previous staements about LV 2010 seems OK.

Friday, I was on-site edittting someone elses code. While dropping ms tick counts in the 30 or so frames of a flat sequence I was experiencing crashes regularly. It took about 7 crashes to get teh changes made.

After seeing it for myself, I called the inside sales rep and got the process rolling so the customer can use LV 2009 since he does not need anything new from LV 2010 and he has to get his code finsihed.

So with large diagrams, LV 2010 is a real pain.

Ben

I've found the best mentors as those you work beside - there's something to be said for working with people that are better than you: you're always challenged, and it's the best way to improve. So, looking for a mentor is a good idea, but looking for a company that is full of mentors is even better!

Thanks for the segway Chris!

Data Science Automation is hiring now. We were started by the first person outside NI certified as a CPI, are lead by the 5Th CLA in the world, have two resident LabVIEW Champions and have one of the highest concenttations of of CLA's you can find anywhere.

Interested parties should check out

DSAutomation.com

for more information.

But on second thought, maybe that is not what Chris was hinting at.

Ben

Thanks for the kind words Felix.

I showed your post to my wife and she said, "I like this Felix guy." I thought maybe it was because of the nice compliment. Silly me. It's because you have Johnny Depp as an avatar.

Thanks for your KillerKiloposts !

Any time I have spare grey matter to toss around I will try to catch-up on your thoughts.

Take care,

Ben

Excellent points Ben. I freely admit optimizing for performance is not something I have much experience with. In fact, I tend to follow the rule, "first make it work, then make it fast," even though that isn't always the fastest way to the solution.

Many of my apps require high speed as req #1. My slaes team seem to be able to find those projects that "almost work" but perfomance is lacking. There are at least three dedicated developers in my office that are working projects that started out as "fix the preformance" to start out projects. years ago (whwn I was just a wee-G-babe) the big boss lamented durring a meeting "why do so many of our apps suffer from performance?". So now we design for speed and we seldom here about perfomance thses days.

The actual work process flow differe little from not keeping an eye on performance. VI development starts out with simple questions; 1) How large are the data sets for this VI going to to be? 2) How often is this going to have to run?

If the datasets are small and the code runs infrequently, just code away. If the code could affect performance, approach it delicately.

Take care,

Ben

Thanks Ben

I am not that expert. Could you give me more explanation or an exapmle file? Thanks

Same here when it comes to ActiveX.

I would start dropping and wiring invoke nodes and property nodes and wiring them to the ActiveX wire and look for something that looks good or you could try the help for those properties to get a clue.

A very long time ago it was possible to get the VBA version of the help for MS stuff by doing an advanced install of the MS stuff and make sure that "Help for VBA" is checked. It will not give you LV code but it will give you VBA examples that can be used as inspiration in LV.

Ben

Hi

I want to open a video and after finishing that video which is 10 second, a dialog box (another sub vi) comes up and asks for other steps.I used sequence frame (both timed and flat) but the two events still execute simultaneously. I don't know how to use sequence frames in a way that the subvi runs just after the video playing time is done. Can anybody help?

Here is my video opening codes

Thanks

ActiveX stuff runs in its own world so you will have to poll to see if it still running of generate an event when the vieo comletes.

Ben

QFT.

Maintaining data between loop iterations and carrying it through the case structure doesn't make the loop a state machine. It just makes it a loop with data you want to persist between iterations. It *has* state, but it's not necessarily a state machine.

The OP mentioned a "simple state machine," which I interpret as the enum-into-a-case-structure kind. For that the shift register is the best way to go.

In theory yes, but in practice we should keep in mind the nautre of LV and not "drink the kool-aid" and expect LV to do our thinking for us.

Performance!

There are code construct that will absolutely freak out LV's inplaceness algoithm in which case it exercises the default rule "if not sure copy the buffer". Complex clusters seem to encounter these issues more often than the simple data structures and as LV evolves, where the in-placeness freaks, can change from version to version. So putt large data structures in a cluster in a SR and passing it in and out of sub-VI's can bite us.

Two branches off that idea:

"The key the key and nothing but the key so help me Codd."

LVOOP

LVOOP first. It seems that Aristos and his team but some excellent thought into the LVOOP data strutures. Mainitaining a class instance in a SR and invoking methods on the wire really "feel" like they are pointers.

Confesion time!

I screwed up in one of my apps and cast (using type cast) a LVOOP class as an array of the class by mistake. I was baffled by LV crashing and passed it to NI as a bug in the TDMS functions. After Aristos traced down MY ERROR, I fixed the code and all ws fine but what really clicked on the light bulb for me was that improperly cast wire ran through a mile of code with out causing a sinlge issue and it was only when it came time to actually acces the data inside the class wire (down in the TDMS functions) did the actual data make a difference.

This bug experience should me just how little the LVOOP stuff is touched.

Now back to Codd.

I have never officially studied Normalization rules, but I have learned some from my wife. I have tried to keep some of those idea in mind when I design my clusters thinking about the clusters as if they were tables. Applying normaliztion rules help me sperate data that has nothing to do with each other while grouping those that do. (part of this can overlap with OOP ideas I suspect). now returning to a point I made early in this thread, if a data structure is only used in a small fraction of the states, move that data to an AE so that it is not being carried around with other data that it has nothing to do with.

So yes, SR are the standard approach and seem perfect for LVOOP, but if you have a performance challenge staring you in the face, special attention should be given to who where and when they are touched.

Just trying to firm up my ideas,

Ben

My little time with LV 10 under XP did NOT show any delays. I don't have auto-save turned on. Mybe I just didn't notice the delay or maybe the VI wasn't large enough.

Ben

Linked tunnels mean you don't have to keep wiring them through. But even without them, I would never have more than 10 cases (yes. I'm looking at you JGCode...lol) so it wouldn't be a big deal. I also don't generally hop over code. I wire through sub-vis as I like to only have only sub-vis in each case frame rather than raw code - much cleaner and gives you the opportunity to make them subroutines. Locals (and globals for that matter) I try to avoid since you cannot sequence them with error wires. If it doesn't matter about UI updating affecting performance, I prefer to use a property node (because of the error terminal). But that's nothing to do with state-machines

But then, I'm me. And that's a bad thing

I agree with most of what you posted and tend toward keeping the number of cases low (in state machines) but the number is not the critical factor but rather the State Transition Diagram (STD) that is realized by the code. I suspect someone out there knows the theory behind it but the point at which STD get confusing is when it can no longer be drawn in a single plane, i.e. the transition lines have to cross over others. That is what I concider my "stop and re-write" point durring the design process. But before I let the diagrams get to that point I will start creating sub-STDs with a cohesive function and replacing the calling STD's code with the new "state". These are generally characterized by "single line in... single line out" structure in my STDs.

But that is off-topic now so I should stop.

Cat,

Yup. That is what the double smiley-back at you was all about.

Ben

Not sure how I stumbled on to this, but thought LAVA folks might find it interesting...

http://www.slideshar...ormal&rel=15910

I've had that tee-shirt for years and little did I supect that with it I could have built the tower of Bable, get Steve Jobs and Bill Gates on the same page, and adjusted my own eye glass perscription. Maybe it would have been obvious to me if I had an Add tatooed on my hand and could fly.

Was that LV 7?

Ben

Is it okay if I disagree with you?

... For pure mess-reduction, local variables are the best way to go.

But obviously it's not all just about mess-reduction, which is why local variables are generally used sparingly if at all.

Sure, as long as I don't have to support the code.

Does your definition of "Pure mess-reduction" completely ignore performance and ease of support?

If so I agree whole-heartedly.

:P

Ben

... So, if I had to put a dollar value on it, I'd make it the same as the cost to attend NI-Week.

Thank you.

Ben

So I finally isgned up for a DropBox account - I don't know how I ever survived without it!

And for every customer you trick talk into signing up, you get another increment of free storage.

Ben

Shift registers in most cases. If only very few states access the data, AEs/FGVs.

Felix

Similar to what I teach my people. If the SR's are well designed clusters (only related data is grouped) then you can quickly spot which SR to move into the AE's by clicking through the states looking for a SR that only gets touched in a handful of places.

Ben

Method 1. Make it snow.

The attached picture is actually from last year when it snowed in Austin.

It snowed last night (a whopping 3/4"). I'd put up a new picture, but there's nothing to take a picture of since the office is pretty much empty!

Do you have any other strange ways a competitor might try to take out NI?

A couple of ideas come to mind.

1)

Judging by how often the titles people have change the competion could sneak in and lift the needle off the record* and let everyone scramble for a new chair.

2)

Put an offical looking sign out front that reads "Nobody that appears to be older than 30 permitted beyond this point."

Ben

*Well that is how we played musical chairs when I was a kid.

Why not just pass the VISA com reference to a normal VI and just track the com reference instead of the vi reference.

if there are different widgets hanging off that visa ref that talk different languages then differnt sub-VI are used. If we don't know the nature of the widget....

Ben

Hi Ben,

Thanks for the reply, can you clarify what you mean by running the laser code as an "active object"?

Thanks

Intead of using the invoke node on a VI that does what you want, set-up a background VI that will do the same thing but without the "invoke node" whenever it is told to do so. In my case I use queues to send the message to thew background VI.

But that was only a suggestion on how to get er done without using invoke node with the assumption that the UI thread was slowing you down causing timeouts. I did a lot of specualting to help give you ideas.

If they help, only you can judge.

Ben

Hi all,

I have an irritating VISA timeout error which I can't seem to track down. Any help would be most gratefully recieved.

So, I'm controlling a tuneable laser over an RS232 link. The laser in question accepts byte code instructions, not all of which lead to responses from the laser. I have written a VI which communicates with the laser and can do the 4 main things I need - turn the laser on and off, set the laser wavelength, check the laser wavelength and set the laser to sweep through its wavelength range. As a standalone VI I have no problems running this at all. It seems completely stable (as far as anything can be!)

In my main application I call the laser control VI by reference (since I have a couple of different lasers I want to use with the same main application). The main App commands the laser to sweep through its wavelengths, and then tune to a specific wavelength. It then monitors a couple of external parameters via a USB-DAQ card and from time to time will send the laser to a new wavelength depending on the results of the monitoring. And its here I seem to have an issue. The laser initialises fine, I can make the laser sweep through its wavelengths fine. But when the laser has to tune to a new wavelength, it tunes once or twice and then gives me a VISA time out error on a VISA read command (Which is part of the "set wavelength" command). Within the main application I also have the ability to manually force the laser to tune (using the exact same set wavelength code within the app) and this seems to work reliably.

I've tried running the laser control VI in a loop as fast as possible to see if I can make it fail, but I can't. The only way I've been able to make it fall over myself was writing a simple program that called the laser control VI by reference and then commanded wavelength changes in a loop (alternating between two wavelengths). This setup was actually stable until I probed the error wires into and out of the set wavlength vi... at which point I noticed that the comms with the laser were suffering if I moved things around on the screen (I have a tx and rx led on the laser itself so can see if things are being sent/recieved). Without the probes, there was no problem, the leds were flashing at a nice constant rate. with the probes in place the flahing was much more stuttery especially if i moved the probes on screen. Adding the probes also seemed to induce the timeout error...

If anyone has seen anything like this before or can think of other things I can try, I'd be most appreciative!

Thanks all

Paul

I don't think I ever got a straight answer but I have this suspicion that "Call by ref" runs in the UI thread, so couple that possiblilty with some of those old serial wdget being impatient about comm time-outs...

1) Can you make it worse by run a parallel VI set to run in the UI thread that gobbles up CPU (to confirm)?

2) Can the timeout on the laser be extended?

3) Run the laser code as an active object then interact with it to do the laser work for you?

That's all that comes to this mind,

Ben

Those were the days . When men were men, and sheep were worried. (and the known issues would fit on a cigarette packet ) < wispy reminiscing emoticon>

2011 is only going to be as good as the Beta testers make it. That da#$ EULA for the Beta's (paraphrasing now... if you run into trouble with the beta code, please report the issue but don't count on us to help..) keeps all of the serious development testing out of the picture until the official release. As long as there is just a bunch of people poke around the theri spare time on toy projects.

G-Story

One of the most solid version of LV was LV 6.1. AS i understand the back story, Albert Gevens really beat that Beta version up. His work was so important in version 6.1 that NI recognized him for his efforts and made him a ... MVP or a Featured Developers or some such.

What I feel would fix the buggey releases:

Cash.

NI should go through thier records of bug reports and find a core set of bug-hunters and approach them about paying them to develop in the beta version, AND back them up with a commitment to fix any bug they find prior to the offical release.

From where I sit I am still seeing the same pattern repeateded over and over.

"dot-zero" version released and I sit back and wait for the bug reports. I avoid upgrading except where my customers have selected the blue pill and I am forced to take the dive into the hole with them. The I go into a routine where I am calling support almost daily with conversation that end with "Well senf me an e-mail with the CAR number and I have a hrad time believing anyone who knows what they are doing actually tested this!".

2010 story

NITS here in Pittsburgh, I was selected to do the Darren routine about the new features in LV 2010. So blew through his material in about 15 minutes and started answer random questions from the crowd when I found myself trying to edit the icon while they watched. Little did I realize the "New and degraded" icon editor was busting full of bugs ( ctrl-V double paste, no drag after select argh!!!). I don't think any of the crowd realized I was dealing with a bug because I stopped and "Pulled a cake out of the oven" to show the final results.

As a consultatant I also find the bugs particulary frustrating because I have to deal with customers asking "Why do you like LabVIEW so much if they are shipping crap?"

I did not expect this post to turn into a rant but I guess it did.

Ben

Wiki-leaks nominated for Nobel Peace Prize

http://www.foxnews.com/scitech/2011/02/02/wikileaks-nominated-nobel-peace-prize/

Ben

Those guys are REAL programmers....

About 20 years ago I was sticking around late in the office to teach myself C. One of the hard core Fortran Cobol types asked "Why bother?" ... it is so cryptic etc. I think there was a similar thread about switch over from horses to automobiles. My appraoch is sorta symbolized by Jim's avatar. Technology is a wave were you have to stay on the leading edge. Failure to do so will result in a wipe out and you will have to start all over again.

Ben

that's double-clicking to be precise. That will also pan the block diagram s othat the terminal is on-screen rather than off to the side. You can exploit that by resizing the diagram window to a couple of centimeters on each side. Then when you double-click on the control, it will "zoom" right to the terminal location. Then you can restore the window size and see where the heck you are.

If you see the marching ants, but the terminal is invisible, it may be behind the edge of a loop or structure. Those act like real-world glass windows where you can see stuff in the field of view, but other stuff in that universe which may be tucked off to the side is not visible until you move it into the "glass" part of whatever structure you are looking "through". Of course you probably have lots of structures within structures, which will add confusion but you should be able to work it out.

Jason

I was refering to the terminal on the icon connector.

Ben

I'm cleaning up some old code (not mine) and I have run into the following problem.

I have an indicator that is wired to the connector to pass data out of this vi. Unfortunately I can't find the thing on the block diagram. I've tried searching for it by name and haven't really had much success. (If you think this should be simple then you haven't seen the vi I'm dealing with) Is there any way to right click on the connector pane terminal and find the terminal of the corresponding indicator/control? This would also be useful because in this particular vi there are several controls/indicators with the same label. (I know - bad practices. They are not mine. Unfortunately the responsibility to make this code work is now mine. I can't throw it all away and start from scratch. As much as I'd like to, my boss seems to think it is more productive to remove cards from the house of cards instead of building the house out of bricks.)

Any ideas?

clcicking on the icon terminal should give you marching ants arounf the selected object. I guess that is not workin for you?

Ben

The problem I have is that when I rename the class, I end up with object controls and indicators that contain the label of the original class. Is there an easy way, outside of manually renaming, to do this? Maybe someone has a tool out there?

Not sure why LabVIEW doesn't do this for me. I can't be the only one with this problem.

Ditto that.

Ben