Louis Manfredi

Not sure about the exact serial protocol these chips use, but if its I2C or SPI, take a look at NI's USB-8451. I'm using one for SPI comm with a DUT & very happy with it. (Wish I could say same of my I2S comms -- that't being somewhat of an adventure.) Best, Louis

Hi Zmarcoz: I was in a similar position to you a few years back. A few points to make: First, in (partial) answer to your specific question, a few years back I taught myself basics of C++ using Metrowerks Codewarrior U. No particular certification, but it was free web-based learning, I learned a lot, I recall even the compiler was near free. So a good place to start, first learn the stuff, then worry about the certification. From what I understand Metrowerks is sort of a thing of the past, but their parent company Freescale, still sells some of their stuff & perhaps runs the Codewarrior U. Little enough difference, I think between one flavor of C++ and another-- at least at the entry level. Second, as it turned out for me everything I did to reinvent myself made little difference in the long run.-- Getting my (no longer current) CLD certification, learning a little C++, etc. didn't really end up making that much difference for me in my search for gainful employment. Got a few consulting gigs through the CLD, was happy to be able say I wasn't totally ignorant of C, even though I never got a job as a result. The LabVIEW was almost always helpful not on its own, but as a compliment to my broad experience in the wind industry. None of the programming skills had that much to do with my ultimate return to steady employment. As it turned out, what did it for me was my skill and experience in my old industry, and friends and contacts in that industry. So here I am, working for someone I went to school with 35 years ago, working in a field I've been in off & on for 35 years. I've written maybe a few hundred lines of C or C++ code in the line of duty over those years (far less than I've written to teach myself the languages). Currently I still do some LabVIEW programming, maybe 5% of my time, but for me its just a tool, not an ends unto itself. So, maybe for you the best thing to do is to focus on the field where you have your degrees & where you've spent the most time, make sure your colleagues in that field know you've got programming skills in LabVIEW that might give you and edge, might help you to be more useful in that field. Third-- An on this point I'm most certain! Don't get panicky or down on yourself during the job hunt. Its a down economy. Its not your fault if you don't find a job, unless you give up looking. You might have to chase 20 leads (or more) to get an interview, might have to go on a half dozen inteviews (or more) to get an offer. Best to be chasing several leads at once, that way the ones that don't pan out don't hurt as much if there's other ones that still might work. I'd pretty much gone into zombie mode, putting in applications without much hope, and out of the blue my old college pal calls to see if I'm available to consult, which eventually grew into a full-time permanent position. Keep an upbeat outlook & present an upbeat public image-- including in public forums like LAVA-- (even if upbeat is not totally real) and things will work out eventually. Best Regards, Louis

QUOTE (alfa @ Mar 12 2009, 04:10 AM) Wow, that explains a lot!

Hi Folks: Seems to me that the vast majority of times I do stuff that needs execution order without data dependency, it is i/o with file system or hardware of some sort... most often things that can pop up with some kind of unexpected fault I'd like to detect. It also seems like there have been many times I've designed code using the error cluster for purely execution order purposes only to discover later that I want to trap some condition and flag it as an error later, and been glad the wiring of the cluster was already done. So I sort of think the error cluster is fine for establishing execution order, and no new wire type for that is needed. (Though if you want, you could always use a U8 or something as a proxy for a null wire, if you really want one.) On the other hand, not at all sure I'd design the error cluster just the way its used in modern LV, but that's a whole different topic... my 2c, Best regards, Louis

It just doesn't seem as catchy as "The software is the instrument." Best, Louis

QUOTE (hooovahh @ Feb 12 2009, 10:49 AM) ...Well there aren't that many threads where the other means of navigation get cumbersome. Best, L

Hi Folks: The go to page control in a multipage thread doesn't seem to work for me. for example this: doesn't seem to do anything when I push the Go button. I'm running Firefox 3.0.6 under XP. Best Regards, Louis

Haven't priced Aardvarks lately, but I guess they must be around $400 the pair. Doesn't seem like that much, but if your DUTs are going to throw 28 v in inappropriate directions with any regularity, I guess it can add up. Sounds to me like you might need some high power zener diode protection circuits-- Perhaps backed up with fuses. Transorb is one brand protective diode I've used before. Also some current-limiting resistors might help, especially in combination with the diodes. Might also be possible to opto-isolate the inputs, but that can get dicey if your running at a high clock rate. (Whatever you do, be sure that the protection system also flags the DUT as bad. Seems quite likely that any DUT sick enough to put 28V on the clock lines would also fail any reasonable tests, but it wouldn't do to protect the tester and have the DUT blow up its target system instead.) Best Luck, Louis

Will NI's 8451 do the job for you? I've got one, seem to recall it was economical, and definitely was pretty easy to set up. (not that my I2C traffic was all that easy, but that too is a long story) at any rate, the 8451 is working fine for me. Best, Louis

QUOTE (zmarcoz @ Jan 22 2009, 11:24 AM) A skilled proofreader, in their native language, can work pretty quickly- but not two pages in 15 seconds. (I don't really think its possible to do a thorough proofreading job in less time than it takes to read the document aloud.

QUOTE (Gary Rubin @ Jan 21 2009, 04:04 PM) --Be that as it may, no excuse for them not finding out-and-out grammar errors! zmarcoz: I have given the latest version of your resume a quick read (I didn't have time to proofread closely). But based on the kind of quick read I would give a resume if I were hiring someone, this version is much better, gives a much clearer picture of who you are, of why someone might want to choose you over other applicants and reads much more smoothly. Probably room for further improvement, but at least to my eye you are heading in the right direction. Best, Louis

QUOTE (Manudelavega @ Jan 21 2009, 10:41 AM) Definitely start with empty array and use "insert into array" -- much more efficient, especially for larger arrays. (many threads discussing this in both LAVA and NI site.) What to do when the array fills, if it ever does? Sort of up to you... Several approaches: 1) Blank out the whole array, start again from scratch. 2) Start at the beginning, overwrite the first sample, but leave the old data up for display, then overwrite the second sample, etc. 3) Like (2) but blank out the first few samples, overwrite the first sample, that way there is a scrolling blank spot between the newest sample (at the right end of the left part of the trace) and the oldest sample (at the left end of the right part of the trace) 4) Like (2) but rotate the data before you display it, so the oldest data sample shows up at the left edge of the graph, and the newest at the right, doing this means the display will start to scroll once if fills up. A bit more work than some of the other choices. By the way, initializing the array and blanking out some samples are an excellent place to use NaN-- Not a Number. Just type this into an array of data and play with it to see how it works-- in display and calculations-- if you are not familiar with it. Best, Louis

Hi zmarcoz: I agree with most all of the other comments, and join them in wishing you best results in your career search. In particular, I agree that networking contacts are worth far more than trying to get a job through simply posting a resume or contacting a few recruiters. Just the same, the resume has to be near perfect, even if you make contact with a potential employer another way, they will be influenced, positively or negatively, when they see your resume. Also, I think its important not to emphasize the programming tools, but what you are doing with the tools. Programming languages are just tools, like hammers. If you were a sculptor or a carpenter, you wouldn't write a resume about knowing how to swing a hammer, you'd write one about what kind of sculpture or carpentry you do. Perhaps you have a separate resume for your particular field, and the one you have shared with us is simply a back-up in case you have to apply to jobs outside of your field-- If so, and if you are anxious enough to find a job to take one outside of your field of work, this is fine. But if not, try to slant the resume more to what you've done and want to do, not the tools you use to do it. In a similar way, your statement "presented my work in conference" is way weaker than it need be... If it were me, I'd say "Presented work on reaction injection molding of wind turbine blades at the 2004 AWEA conference." instead-- My field, not yours, but you get the point. Finally, you always need a really good proofreader to go over any resume very carefully for grammar errors. True even if you are a native-speaker of the language, but even more so if not. For example, I think you mean , "Power Systems, Modeling Statistics, Probability theory"-- now what you have written. (Although perhaps I'm wrong on the last one, although I've never heard of it, it seems like there should be a field called Possibility Theory...) the proofreader has to be someone who is good at proofreading, who isn't afraid to risk offending you by pointing out the minor details (like the above) that are wrong, and who is willing to take the time to help you out. If you have a friend that is a journalism or English literature student, that friend might be a good choice. Again, best results in the career search, my comments intended to help, not to criticize. Best Regards, Louis Edit: Fixed font size.

Hi Manudelavega: Welcome to LAVA. Your array size is pretty small: 8640 samples/channel for the 24 hour period. Even with a large number of channels, you shouldn't have any problems in that regard, you could fit the whole array in memory if there were not other problems with the approach. (If you use an array, be sure to initialize it to the size you need when you begin, since you know what the size will be that is most efficient-- see other threads on memory allocation.) Trusting the computer to stay running for 24 hours is another issue. For that reason, you should probably be writing your data to a file, so you don't end up losing a day's work. The probability of having Windows crash within a day is less than it used to be, but still unacceptable if the cost of a day's experiment is at all high. If the reading and graphing routine can afford the slight delay (it probably can) the easiest approach would be to write the file, and let the other guy's display programs read the same file. If not, keep the array in memory, but also back it up to a file often. Best, Louis

QUOTE (Zac @ Jan 19 2009, 11:49 AM) Pretty cool project-- If it is for a wind tunnel, my previous comment about LabVIEW drivers goes in spades. Worst comes to worst (and only if worst comes to worst) chuck their software, and also chuck their electronics, and wire the strain gauge bridges directly into a cRIO A/D convertor. (I believe NI makes a strain gauge bridge device for cRIO.) Best, Louis

QUOTE (Zac @ Jan 17 2009, 05:06 PM) Hi Zac: Using Portmon, or something like it, is a very good approach. Often serial communications between instruments and the host computer is in printable ASCII, sometimes it is even in a human-readable form. Another approach is to try getting in touch with different people at the instrument manufacturer. If you can get in touch with a technical back-office person somehow, and chat up with them what you are doing and why you want to bypass their software, you might get lucky and get a copy of the communications protocol specification from them. We engineers love to talk about our work. At very least, you should try and find out why they don't want you to bypass their host software. A number of possible reasons: 1. There's a lot of complicated and perhaps proprietary final signal conditioning done in the host. (In this case, you probably don't want to try and bypass the host firmware.) 2. Disclosing the communications protocol might disclose something about how the sensors work that the manufacturer would rather keep quiet. (In which case, portmon is the best bet, unless they have taken the trouble to encrypt the communications.) 3. The manufacturer hasn't done a publication-quality specification, and is ashamed to show what they've got. (Offer to sign an NDA, and to take what they have without criticism. Even if its not totally complete or accurate, it will help you when you go to portmon.) 4. The manufacture simply doesn't want to go to the trouble of supporting a bunch of programmers all trying to write slightly different programs, in different languages. It is easier for them to support just the one simple case of the instrument talking to their own software. (Again, offer to sign an NDA and promise not to burden tech support with questions, and they might give you what you need.) In any case, if the manufacturer is unwilling to provide support for you directly communicating with their instrument and if they actually intend to stay in the business of selling instruments to the technical community, they should provide LabVIEW drivers for their instrument. If worse comes to worse, nag sales staff about this. Unfortunately, I've found that many LabVIEW drivers for non-NI instruments are atrociously written by text-line programmers who haven't got a clue about LabVIEW programming. Often, however, these programmers don't know LabVIEW well enough to know how to lock the block diagram, so the "LabVIEW drivers" are at least useful as an awkward documentation package for the communications protocol so you can write your own from scratch. Just my thoughts on this, hope to have helped, Louis

Hi Mounir: Osvaldo's advice works, I did it this way a few years back. I'm not certain that RSLinx is the only OPC server you can use for the job, might even be servers available with LabVIEW? But certainly the RSLinx path worked and was straightforward to set up. Best, Louis

QUOTE (alfa @ Oct 29 2008, 04:19 AM) Ah, Great News! Are you going to let those of us in the 98.6% know who?

QUOTE (Neville D @ Oct 17 2008, 02:05 PM) I wouldn't exactly call the LabVIEW/Daqmx support of the 653X series of cards "Seamless" -- I've found the documentation for 653x DaqMX a little cryptic, and for things like figuring out how to use external sample clock input, hardware triggering, and the like, you need to refer also to the traditional nidaq documentation, which is more thorough, but unfortunately seems to use different signal names, from the Daqmx. Count on needing a little patience to understand this hardware's finer points. Just my perspective, and in any case, Neville's point is still valid-- even if the support isn't seamless, the good folks at NI support will do their best to get you across the seams. If you buy hardware from someone else, they may lack the moral obligation, motivation, and probably even the knowledge to help you out. Best Regards, Louis

QUOTE (neB @ Oct 1 2008, 10:49 AM) Hi Ben: I'd vote in favor of the Right-Click on Label option... I think that's and excellend idea which would be a time saver & encourage better vi documentation. I'm not hot about any wholesale copying of free labels to documentation-- too many of my free labels are labels for adjacent shift registers, notes over wires, notes to myself about things to fix or hooks for future features, and the like. If all that stuff ended up in the VI documentation, it would be counterproductive. Best, Louis

QUOTE (Ben Zimmer @ Aug 18 2008, 07:49 AM) Not recently, but in years past I quite commonly used four and five dimensional arrays as the test case matrices for automatic storage triggering for data acquisition in wind turbine test projects. (For each bin of wind speed, For each bin of wind direction, For each bin of windspeed turbulence, For each bin of wind direction turbulence, For each of a number of possible turbine controller states, store up to so many ten minute samples of high bandwidth structural loading data.-- One five dimensional array for the number of samples desired, another for the number of samples obtained.) But recently, I've been able to handle everything with two or less dimensions. Best Regards, Louis.

QUOTE (Yair @ Aug 14 2008, 01:21 PM) Fine old tradition in the U.S. of A. too.

QUOTE (EJW @ Aug 1 2008, 09:35 AM) Hi EJW: Not sure why you're having this problem, and why only in executable not in Development system, but I'd worry about the DAQ Assistants creating handles to Daq processes, and not--for one reason or another--destroying them when done. You might want to try opening these up, and breaking them apart into three pieces-- Initialization part to move outside and before your while loop, part that needs to be done every loop cycle inside the loop, and part that closes the processes outside the loop and after. Might not be as easy as I'm making it sound, but if you can do it easily, might be worth a try. Best Luck, Louis

Hi Folks: My 2 Cents: Certainly agree with Crelf-- I wouldn't like to see merge errors autoinserted. Occasionally, but rarely, I merge error streams from parallel paths. Much more frequently I'll add a sub-vi in the middle of a chain of stuff tied together by the error wires. Usually do this by ploppiing the new vi down near the error wire (and often a handle wire of some sort) wiring both the input and the outputs, then cutting the short circuit between input and output, then drag the new vi into line. Not sure this is the easiest way to do an insert, but its the way I normally use, and autoinserting a merge error vi would be a real annoyance for me. Not sure that I agree that Express vi's are poor learning tools. As an experienced user I find them very handy for learning how to do something new, and same true I think for new users. I just caution new users to use them only as an example of how to do something, and not as examples of proper LabVIEW programming style, since, like many other NI examples, the style is often atrocious. And obviously you usually should throw away all the code in cases you're not selecting, but I don't see that as a problem since it is a chance to learn other ways that things could be done in other situations. Best, Louis

QUOTE (Neville D @ Jul 16 2008, 04:32 PM) For others, another try at linking to Neville's post: http://forums.lavag.org/index.php?s=&s...post&p=6013 Not sure why I can't get the regular style link to work, but copy and paste above might work. Hi Neville: Thanks for getting back to me. Helpful advice. Seems like the best thing to try is to read the old DAQ manual to form a basis of understanding for the more cryptic DAQmx documentation, but to stick with DAQmx. I'm not sure that I really will have to use external breakouts to patch through my triggers-- I think the PXI rack provides the hardware paths I need, all I have to do it learn how to configure and use those paths, but I'll definitely look at the links you gave on this topic before I beat my head against the wall much more. Again, thanks for the prompt and helpful response. Best Regards, Louis [edit- third try at getting link to other post to work.]