is a huge scam by NI to repackage the C/C++ language and sell it back to you.

stay away.

3/18/2009 12:57:49 PM

We use it pretty much exclusively in my group for rapid R&D test developement. It has its uses.

But i'll stick with the theme:

3/18/2009 5:49:46 PM

MATLAB FTW?

3/18/2009 8:45:22 PM

Matlab is never FTW unless you are comparing it against Maple

3/18/2009 9:12:24 PM

i always liked Maple, but I think I would prefer matlab nowadays. luckily I have no use for either at this point in my life :-D

3/18/2009 9:27:50 PM

I always liked MATLAB. Sadly, I have no use for it at this point in my life :-(



as for LabView, i'm SOOOOOOO glad i never have to learn how to use this shit. I'm actually in the process of ripping out an entire industrial LabView system designed by EADS and rewriting it my damn self in C.






[Edited on March 18, 2009 at 10:04 PM. Reason : ]

3/18/2009 10:02:32 PM

why would you do that?

sounds like a lot of redundant effort

[Edited on March 18, 2009 at 10:07 PM. Reason : s]

3/18/2009 10:07:01 PM

Quote :

"i always liked Maple"

this proves you are not an actual person

3/18/2009 10:09:11 PM

I loved it in my all of my 400 level engineering classes... All my classmates who thought it was cool to hate maple had to work these epic multi-page problems out by hand with tedious transformations and calculus. I just asked my professors if it was ok if I used Maple after I'd set up the problem properly. They said, "of course - thats why we teach it to you" and after all, the tedious calculations didn't have anything to do with the subject matter of those higher level courses anyway.

So, long story short - the "cool people" who hated maple spent hours on their homework while I just plugged shit in and clicked print. I got a lot of glares when I would turn in my big stack of white papers next to all their yellow pages of handwriting

3/18/2009 10:13:37 PM

yes, i'd much rather use maple over doing things by hand

but there are much better math packages out there than maple

3/18/2009 10:15:58 PM

mebbe so but maple's the one that I know (knew) and its not all that hard in the first place to use it to just do random hw assignments.

3/18/2009 10:17:16 PM

Quote :

"why would you do that? ... sounds like a redundant effort"

because it's running a massively complex test system including 4 separate DAQ cards, external equipment, etc., and is composed of a big stinking mess of files that no one can maintain. not to mention, it's not scalable, and it currently takes 15 minutes to test one medical device from start to finish, when it should only take about 6 (that's our fault, poor specifications when the design was contracted out 4 years ago)

in short, it was developed by EADS and was apparently designed with the primary goal of keeping us dependent on their R&D department to charge exhorbitant fees any time we want to upgrade the system. like now, because 15 mins/device is untenable.

i could spend the next couple months learning the gory details of LabView, but I am refusing to because I believe that LabView is nothing more than a clever marketing ploy by National Instruments to lock mediocre programmers into some goofy proprietary system with endless dev licenses, runtime engine licenses, and nonstop seminars and classes to learn their convoluted rules.

its just a fucking wrapper around the C/C++ language, for chrissakes. if you want to program in C/C++, then freaking do it. dont abstract a mess of overhead just so you can connect pictures together to accomplish the same function

:grr: :grr: :grr:

[/rant]
[/blog]








[Edited on March 18, 2009 at 10:34 PM. Reason : ]

3/18/2009 10:22:40 PM

I see... However, without knowing the slightest thing about your situation, I would have these concerns:

1) Maintenance. Now you are on the hook for fixing every little problem. Its nice to have a vendor you can call and/or blame if something goes wrong.

2) Scalability. I'm sure your code will work fine but what happens when you're busy on something else and mgmt decides they need this other feature that will take up all your time to implement? If you were using a vendor tool, you could just offload that requirement on their AE.

3) Verification. This is related to #1, but how do you verify what you're doing? Sounds like a big risk which might be ok, but I'm risk averse, personally. Have you ever heard this phrase: "No one ever got fired for buying IBM NI." In fact, this is probably a major reason why your system is in the state its in now.

4) Free lunch. If you invite NI to come help you, they might buy you lunch.

[Edited on March 18, 2009 at 10:37 PM. Reason : almost forgot the most important reason not to leave NI...]

3/18/2009 10:33:58 PM

(1) we have a bunch of C programmers or at least people who can hack their way through C. no one knows squat about LabView. and some of us (like myself) have a philosophical hostility to the idea of LabView.

(2) EADS is hugely expensive. they're the european version of our NASA. we can do it cheaper. we can also do it better because these are our devices and it's all right here in plant. rather than trying to deal long distance with their umbrella org in Southern California. and, again, we have devs and test engineers here who know C.

(3) as a mfr. of medical devices, all we do is verification at the FDA-traceable level. our entire company eats and breathes verification.

(4) we may use NI's TestStand as our executive. that's not cheap either. we can still get that lunch. and not have to buy EADS's lunch.


anyhow, i want the challenge. theres a lot of high visibility on this project. so either they'll sing my praises or fire me. either way i add a significant project to my CV





[Edited on March 18, 2009 at 10:45 PM. Reason : ]

3/18/2009 10:43:48 PM

sounds well thought out.... you have my approval to carry on.

3/18/2009 10:50:09 PM

aye aye. by your leave, sir.

3/18/2009 10:51:19 PM

Labview is such a crappy program. It's like an incredible machines for engineers except all the levels suck and you never win.

I actually use math cad and prefer it to maple. I wouldn't compare it to matlab though.

3/19/2009 8:15:57 AM

[quote]Labview is such a crappy program.[quote]

its good for some applications, like for non-programmer scientists who want to get some basic prototype experiment with a DAQ card up and running quickly.... but for more complex applications, you're shooting yourself in the foot if you choose to design in labview.

you should see the convoluted symbolic contortions you have to go through just to stream some input into a log file, for instance.

any time you've got App Engineers trying really hard to sell you some proprietary system, telling you that "once you learn it, you'll never want to go back"... man, thats some sketchy shit there. if you get approached by some LabView evangelist, ask them this: "If I already know how to program in C/C++ why the fuck would i want to learn how to program in some proprietary expensive system that is just a GUI wrapper around a C/C++ compiler?"

3/19/2009 11:12:28 AM

oh god - all you had to say was that it was a GUI

who in their right mind would want to use a GUI??

3/19/2009 3:17:35 PM

Quote :

" I loved it in my all of my 400 level engineering classes... All my classmates who thought it was cool to hate maple had to work these epic multi-page problems out by hand with tedious transformations and calculus."

Calling bullshit.

No wait...was this the power systems class you cried in when Mr. Military Associate Professor bent you over like a little girl?

3/19/2009 4:42:31 PM

Do you also feel this type of anger toward Simulink?

3/19/2009 4:50:42 PM

^^ must not be since I made an A in the class...

Regardless, I didn't need to use Maple in power systems. In fact, that wasn't even a 400 level class if I remember correctly. I mostly used it in my communications classes. There were some other classes I used it in too, but I can't remember which ones.


[Edited on March 19, 2009 at 5:12 PM. Reason : s]

3/19/2009 5:08:54 PM

Seriously, which classes at the 400 level allowed you to just punch it in maple and turn it in, I'd love to know?

You're right, power was 305.

3/19/2009 5:14:44 PM

Like I said, communications for sure and I know there were a number of other classes too, but I don't even remember all the classes I took back then....

Just took a look at my old homeworks and in addition to my communications classes, I used maple for homework assignments in ECE 301 (shudder), ECE 314 (circuits 3), and I couldn't find any assignments from 403 (analog circuits), but I'm pretty sure I used it in that class also. Didn't have to use it for 303 (emag) or 305 (power) since those problems were mostly straightforward and relatively easy. Control Systems was matlab so maple wouldn't have had any application anyway



[Edited on March 19, 2009 at 5:28 PM. Reason : s]

3/19/2009 5:17:34 PM

I turned in a TON of ECE homework from matlab. Pretty much anything you would have used a calculator on. I lost my TI-89 for a couple semesters.




[Edited on March 19, 2009 at 11:30 PM. Reason : .]

3/19/2009 11:29:31 PM

^ there's no reason not to

Engineers should be all about efficiency anyway. We should've gotten bonus points for being more efficient than our peers

3/19/2009 11:31:03 PM

xpcTarget ftw?

3/19/2009 11:50:27 PM

MATLAB is the single most useful thing I ever came across in my EE/CPE undergrad. I don't understand why people bitch and moan about it. It kicks so much ass. If you think Maple is better than Matlab you've either never used the latter or you're just a complete idiot.

meh towards labview. I had to learn it for one of my projects, I definitely liked the data acquisition integration and testing features it has but programming does suck a bit.

3/20/2009 2:18:54 AM

I don't think Maple is better than Matlab. My OP said that I was pretty sure I'd prefer matlab to Maple nowadays... I just didn't learn matlab until control systems so Maple was what I used

[Edited on March 20, 2009 at 7:44 AM. Reason : s]

3/20/2009 7:44:24 AM

This is what my last labview "program" looked like.

3/20/2009 7:54:00 AM

bump

10/4/2010 9:28:11 PM

I've been working with Labview lately and figure I'd give this forum a shot at this question. I have a hysteresis-like plot that I need to calculate the difference between the two curves to make sure they are in tolerance.

In Labview, the waveforms are in terms of dt so the x values are one waveform and the y values are another. It's easy enough to subtract corresponding x and y values for the same t but this isn't hysteresis. I need to calculate the difference between 2 points of xy.

For example, if my data is

X Y

0 .1
1 .1
2 .1
3 .1
4 .1
4 .3
3 .3
2 .3
1 .3
0 .3

The hysteresis would be the difference in the Ys at the same point, or

0 .2
1 .2
2 .2
3 .2
4 .2

This is one instance where I think I could do this calculation better with pure C++ but it would be an ugly brute force type of function and I'd like to avoid that if there is some type of Labview built in that will do it for me.

10/4/2010 9:40:18 PM

If I were doing what your describe in Matlab:

for i=min(X):max(X)
   Y_diff(i)=max(Y(X==i))-min(Y(X==i));
end

10/5/2010 12:27:39 PM

LOL AT MYSELF ITT

10/5/2010 2:56:11 PM

Im sure theres a better way, but a solution would be to:

1. Get min value in X array
2. While loop
2a. search array for min X
2b. if found, note index and increment search start point for next search
2c. if not found terminate while loop
3. compare Y(index1) Y(index2) Y(index3) etc
4. Place minX and Ydif in new array
5. remove X(index1,2,3,etc) and Y(index1,2,3,etc) from arrays
6. start back at 1 until no more values

This assumes you don't know how many instances of X and assumes X values will not ramp up and down as in the example.

10/5/2010 5:41:40 PM

Quote :

"missing error handling and doesn't specifically check for X values that have multiple Y values* "

That is actually what is complicating this the most. The X values actually change at 1/5 rate of the Y values. So I'm getting 5 (in some instances 4, some 6) Ys for every X. The data actually looks like

0 0.001
0 0.000
0 0.0012
0 0.0011
0 0.0008
1 ...
1 ...
1 ...
1 ...
1 ...

etc.

Quote :

"will not ramp up and down as in the example."

The very nature of hysteresis is you get two different "Y" values for the same X values depending on which direction you are approaching the X from, or more scientifically

http://www.electronics-tutorials.ws/electromagnetism/magnetic-hysteresis.html

I ultimately ended up brute forcing it (mostly thanks to labview) for now by looping through the entire X array and for every element in X I then loop through the entire array again looking for all indexes that match this given element. If I find a match, a take same index in the Y array and copy it into a temporary array. After I've looped through the entire array searching for matches I can then use a labview built-in that will pull out the max and min and from this I can compute the hysteresis.

This is just the first attempt. Since I am certain I won't have more than a handful of the same Xs, I can likely sort the array and then for any given element my search range only needs to be 10-15. This is really easy to do in a text language but in Labview (at least, as much as I know of it working with it for 2 months) it isn't cut and dry.

10/5/2010 9:59:38 PM

so....you did what I posted?

What size data sets are you working with? Is there some requirement to do this more quickly?

10/6/2010 8:47:53 AM

Did you ever check the LabView code exchange website for hysteresis functions?

http://search.ni.com/nisearch/app/main/p/bot/no/ap/tech/lang/en/pg/1/ps/10/sn/ssnav:cod/q/hysteresis/ses/false/

10/6/2010 1:01:41 PM

^ Believe me, I scoured all of that, and stared at all the signal processing and waveform palettes available as well as posted it to LV forum. I got one reply saying to run the data through a curve fitting function and go from there. I actually looked at this and may come back to it if I get anal about the code.

^^ Ugh, sorta. I don't think my example data set is perfectly displayed. In particular, it defintely ramps up and down. The data sets (for now) are 6 arrays of ~20k items. I got a chance to run it today and it seemed to take a C2D (not quite sure how fast) ~6 seconds to do the computation.

[Edited on October 6, 2010 at 9:01 PM. Reason : .]

10/6/2010 9:00:21 PM

Fuck LabView

I'm part of the cabal at my company that regularly cockblocks any LabView sales reps from NI ever getting a toehold in here.

we've got one test system that uses LabView (developed by a 3rd party) and it is an unmitigated disaster. probably more the fault of the 3rd party, but even still.

10/8/2010 11:43:04 PM

Quote :

"probably more the fault of the 3rd party, but even stil"

Wouldn't this be the case with a text based language as well?

This is coming from someone who is a CPE/EE and hasn't done a ton of hard core coding and really isn't efficient with modern programming tasks, working with APIs, etc...I kind of like Labview.

I can imagine for a programming purist, they can accomplish the same thing I've done so far in labview in C/C# in probably a similar amount of time, but for someone who is more a CPE than a CSC, it's allowed me to build some fairly nifty custom instrumentation and custom DAQ tools in a pretty short amount of time.

10/11/2010 10:57:07 AM

Quote :

"Wouldn't this be the case with a text based language as well?"

at least if it were in code, any C/C++ programmer could dig into it, trace and debug as needed. now we have to hire LabVIEW consultant to make any revisions. latest guy, has like 15-20 years of LabVIEW experience, says it's a convoluted mess like he's never seen. it was a mismanaged project, and they put several different people on it, some of whom obviously were not competent labView developers.

yes LabView has it's place. you can build custom stuff pretty quickly once you learn the paradigm. it is indeed originally designed for scientists and research techs and the like to build simple DAQ systems without having to learn low level C code

but when you start getting into very complex test systems, especially in regulated industries, forcing this tool to be used in design becomes a nightmare. the whole LABVIEW has become ridiculously complex, as they have to abstract away more and more features into a drag-and-drop GUI scheme,

add levels of abstraction you get more overhead and suffer performance. and you have to rely on National Instruments to find and fix their own bugs. which happens a lot. so many stories of a new LabVIEW version breaking something and then people have to argue for months with them to prove it's their problem. And most importantly, rather than enjoying the portability of C, you become locked into a proprietary GUI-programming method and you are at this vendor's mercy.

the whole thing has become a racket to lock you into their development environment and runtime licences are expensive. especially compared to C, which can be completely free.

FTR, I'm an EE grad (not CPE). i took one "real" programming class, CSC 114 C++. then the required ECE206 C/Assembly, and an elective ECE 520 Verilog. Ive taught myself to be a C programmer, for developing hardware interfaces and instrument drivers, and wouldn't do it any other way.







[Edited on October 16, 2010 at 5:44 PM. Reason : ]

10/16/2010 5:31:33 PM

I'm about to have to learn some labview to finish a thesis project .... if anyone knows any sites other than the NI site for tutorials and such, it'd be much appreciated

2/17/2011 9:20:12 PM

they have a lot of self-contained library examples within the application itself. experiment with them, thats the quickest way

2/17/2011 11:40:12 PM

I took the basics 1 class and was understanding the labview paradigm (data flow, tunnels, registers, controls, etc) in a couple weeks. Able to debug some pretty convoluted non documented code in maybe a month.

joe, I think you really sold yourself short not bothering to pick it up. Maybe you just never got the concept but I can't imagine doing some of the stuff I've done over the past few months in a text based language. The run time debug tools alone, being able to break execution, probe wires, is worth the price of admission.

2/18/2011 6:35:29 AM

Quote :

"I can't imagine doing some of the stuff I've done over the past few months in a text based language. "

LABVIEW is a gui wrapper around proprietary libraries written in C and C++. that's it. perhaps you need to understand your text based languages at a more comprehensive level.

i'm not saying it doesnt have a place. but be prepared to get locked into a completely unportable proprietary system that you'll never get out of. and be prepared to get overwhelemed with mountains of "spaghetti code" for any moderately complex system.

2/18/2011 10:52:23 AM

Quote :

"that's it. perhaps you need to understand your text based languages at a more comprehensive leve"

Ok, now you've done it. I apologize in advance, but I'm about to rip you a new one...

Quote :

"is a huge scam by NI to repackage the C/C++ language and sell it back to you"

Clearly any company that has been public for 15+ years outside of finance that got to a 3.7B valuation did so because their core product is a scam.

Quote :

" i'm SOOOOOOO glad i never have to learn how to use this shit."

Oddly enough, you never learned to use it yet you knew with certainty the language is a piece of shit. gfg with that one.

Quote :

"I'm actually in the process of ripping out an entire industrial LabView system designed by EADS and rewriting it my damn self in C"

I'm on the cusp of doing something similar, but I'll be replacing it with properly coded Labview. Surely you don't think that terrible coding practices are limited to Labview? Assuming you aren't that retarded, are you attempting to make the case that somehow Labview lures people into doing dumb stuff by design?

Quote :

"because it's running a massively complex test system including 4 separate DAQ cards, external equipment, etc"

So? Any industrial automated test system doing anything more than a highly specific task will be fairly complicated. C++ doesn't make this go away.

Quote :

"it was developed by EADS and was apparently designed with the primary goal of keeping us dependent on their R&D department to charge exhorbitant fees any time we want to upgrade the system"

My last job the home office did just this...only it was written in a combo of Fortran/C and the configuration management was done with SCCS + perl for years until we finally managed to at least convince them to use SVN...where they promptly reused all the file naming convention/config management bullshit.

Quote :

"i could spend the next couple months learning the gory details of LabView, but I am refusing to because I believe that LabView is nothing more than a clever marketing ploy by National Instruments to lock mediocre programmers into some goofy proprietary system with endless dev licenses, runtime engine licenses, and nonstop seminars and classes to learn their convoluted rules. "

Come on...lets be honest, you saw something you haven't seen before and thought to yourself it would be way easier to do this from the ground up with something you know rather than to undertake the uncertainty of learning something new and doing it with that.

Quote :

"its just a fucking wrapper around the C/C++ language, for chrissakes."

No it isn't. The language is called OpenG. Aftermarket equipment makers (I'm not sure about native NI stuff) are likely writing their drivers in C and exposing the interface to Labview, but the core Labview engine is absolutely not C++, or a wrapper of C++, or whatever you made up in your mind as an excuse not to learn.

Quote :

"either way i add a significant project to my CV"

You're right...but in one instance you just add the project, in the other you add the project + a new tool for your skillset.

Quote :

"you should see the convoluted symbolic contortions you have to go through just to stream some input into a log file, for instance"

With TDMS you have one VI to open the file with a name and any properties for it, with the next you stream waveforms you wire to a single input, and with the next you close the file. You likely didn't know this existed and were trying to write the data out by hand with some more native file I/O VIs (page 6, does it get any easier ftp://ftp.ni.com/pub/devzone/pdf/tut_9334.pdf)

Quote :

"we've got one test system that uses LabView (developed by a 3rd party) and it is an unmitigated disaster. probably more the fault of the 3rd party, but even still."

This isn't the same system you were going to re-write 2 years ago was it? What happened?

Quote :

"and be prepared to get overwhelemed with mountains of "spaghetti code" for any moderately complex system."

We have just such a system. It isn't outright spaghetti, but the team of guys that created it were device driver and C guys who took what they had running in C and converted it to Labview. Instead of Test Stand they somehow got ahold of an old Test Executive that NI was developing in the mid 90s before they bought the Test Stand folks and it's coded in a way that I'd expect a C guy with very little re-use and OO understanding to do. But even as bad as it currently is (and we're in the process of fixing it the right way) it's still actually quite a bit more capable given all the NI palettes/tools than the C based software they had running the stands before.

Btw, no AE sold me on this, I've never even met an NI rep.



[Edited on February 18, 2011 at 6:15 PM. Reason : .]

2/18/2011 6:13:20 PM

tldr

and the soap box is that way -->

2/19/2011 7:44:12 PM

haha, I knew you'd pussy out

2/19/2011 8:01:47 PM

2/21/2011 12:33:34 PM