Search the Community

So I was cursing my CD drive again as I was attempting to load some code on it so I could walk over to my dev laptop and see some CR code. Which made me think I needed to submit the concept of a LabVIEW Viewer to the Idea Exchange. But it's already there, more-or-less. So please wander over here and vote for this idea. Various reasons are: Community service: I kinda made a promise to myself to start helping out more on LAVA, but that's hard to do when dealing with code is so painful. Code review: I've really been pushing LV training here. I figure anyone who knows C and has LV Core 1&2 can do code review, something I have been sorely missing. But none of my cow-orkers have LV licenses so they can't look at my code. Try printing out 2500+ vis sometime... Viewing more recent versions: It would be useful to be able to look at LV 2009/2010 code (I haven't yet received permission to upgrade). Vote early! Vote often!

It's been in the gallery for a few days now. Although the gallery is not as full as usual. Guess Michael hasn't had time to upload all his stuff yet... Sure was cool to have you around. I still don't have a clear picture of what a cow-orker looks like though.

The up side of spending the time is that there will be more platforms added in the future. So if I take the time now, it will be automated in the future. If it's possible to do in the first place. Thanks, Ton! Yes, I will need to have to deal with deeply nested structures. If I go forward with this, I'll post those additions. Even if I can do this with scripting, you've started the parsing part for me. That will be a big help. That was my first thought when this was proposed to me. I know how to deal with dlls. But when I asked my C programming cow-orkers if they could make a dll for me, I just got back a blank stare. Of course, then I had to say that in LabVIEW, creating dlls is a piece of cake.

I'm guessing the answer to this is "no", but thought I'd ask anyway, just in case... I'm (probably going to be) tasked to develop Yet Another data collector/analyzer. I'll be reading (via TCP) and parsing data from many different platforms. The main collection and analysis algorithms will be the same for all the platforms, but the "headers", to use the C term, that define the message formats will be different for each platform. There are around a hundred of these message types and the header files for them are already written in C. Is there any way, other than slogging thru each of them by hand, to turn the structures in C header files into clusters in LabVIEW (or whatever else might be appropriate)? I haven't played with scripting any, but might I be able to use that to generate this header code? It would probably take me longer to write the scripting code than to actually do the conversion by hand, but it would be a lot more fun. If the answer's "no" all around, then converting header files by hand might be a good project for one of my cow-orkers who's dying to take on some LV programming... [insert evil laugh]

Try bugging Management about it for 10 months. That's what it took for it to happen for me. I feel your pain. We had a tech who played the radio all the time. Then he left. When he asked to come back I said, fine but no radio. Now I only have to deal with the roar of 30+ multi-fan data collection boxes and assorted UPSs, one of my cow-orkers continually ringing phone, and delivery guys knocking on the door all the time. I really get a LOT more done on those rare days that I work from home.

One of my cow-orkers is from Chicago and she's loving it, too. Blech.

Them's fightin' words... I can't disagree with that. "Obsessive" by who's definition? I called a cow-orker a "dunsel" once. I was making a reference to a Star Trek episode. Cow-orker #2 remembered much more about the episode than I did. Cow-orker #3 remembered everything about the episode including the title. Which one of us knows enough about Star Trek to qualify as a "geek"? Now this I agree with. I suspect the non-geeky nerds I went to school with ended up runing the financial world. And before anyone says those nerds weren't smart enough to avoid the current crisis, just remember, they are so smart that despite all the havoc they have wreaked they are still making more money than 99.9% of the rest of us.

28.20513% - Total Geek. Not so bad. And yeah, there's 5 checkboxes at the end if you're female. Cow-orkers, you say? Sounds delicious.

A few years ago this was circulating around: http://www.innergeek.us/geek-test.html I scored embarrasingly high on it, much to the amusement of my fellow geeky cow-orkers. So far only my uber-geeky godson has beat my score and that's because he know all the gaming stuff that I don't. Back then you got 10 extra points just for being female. I haven't looked over the latest version to see if that's still true.

One of my cow-orkers handed me that cartoon. No respect... Keep in mind your users, not necessary just what *you* think looks good. I had a project where I was asked to apply color accessibility standards when designing the GUI. Turns out a relatively large percentage of the users were color-blind. "Best" for them was quite different from other users.

QUOTE (JustinReina @ Apr 13 2009, 01:14 PM) Most of my cow-orkers would think Microsoft Paint was a more appropriate application to open LabVIEW in. It's just a bunch of pictures, right??

QUOTE (SULLutions @ Mar 20 2009, 06:23 AM) The book sounded familiar. It just so happens I have it on my bookshelf (I pulled it out and noticed one of my cow-orkers had put a sticky note under the title with "A Graphical Comedy!" written on it. No respect... ). I'll take another look at it. Thanks!

I'm back from vaycay (a lovely week on the shores of Lake Michigan) during which I worked too much. As a kind of reward, I'm going to take a few days off from my regularily scheduled projects and do a little professional development. At this point, I can probably squeeze in a week of time (okay, some of it will be on my own time, at home, but my cow-orkers didn't get me a "Geek Goddess" mug for nuthin' ). I am woefully uneducated on two topics(well, a lot more than 2): 1) LVOOP 2) Scripting One seems more interesting (scripting) but the other seems more practical (LVOOP). Given a week, and given that I don't know diddly about OOP to start with, anyone want to weigh in on which of those 2 options might be a better use of my "professional development" time? Cat

Apologies first: I originally posted this in info-LabVIEW about a month ago. Unfortunately no one could come up with a solution there (Uwe and Bruce, if you're here, thanks again for trying!). Hopefully the wider audience here might include someone who has experience with this. ________________ Short story: I need some way to map a UFS Solaris drive (ie, assign a drive letter to it) while it is in a Windows XP box. Long story: I have finally convinced The Powers That Be to get rid of our very small SCSI drives on our Solaris 10 boxes and replace them with SATA drives. Due to the small size of the SCSI drives, we have to offload data to tapes, and often generate upwards of a hundred tapes on a test. The SCSI tape drives are very problematic, very expensive, and random access does not exist. My thought was that if we went to Tbyte SATA drives, we could replace those tapes with 30 disks. Much cheaper, much more reliable, and separate runs of data are easily accessible. But... All that data needs to be read, processed, and transferred to a Windows-based storage system. In other words, I will pull those UFS format disks out of the Solaris box and put them into my multi-bay disk drive Windows box. At that point I need to be able to access the files, via an assigned drive letter to the UFS disk, as if it were a Windows disk. Of course, I will be doing all of this in LabVIEW (just to keep this post slightly on topic :-) I (and a couple cow-orkers) have done a pretty extensive search on the web. I have downloaded and installed several utilities, hoping they would work, to no avail. They either only work with Linux-flavored disks, or they allow the user to copy UFS format files to a Windows box using their own interface -- not a true map to Windows; no drive letter assigned. Copying the files this way would be a last choice solution, as it takes about 3 hours to perform this operation on a full Tbyte disk. And then another 3 hours to read the copied data, process it and copy it back to disk. This will double the overall processing time. And I will have 30 disks to do this on... Our fallback is to put a bunch of the disks in some multi-bay Solaris box, run Samba on it, and map the drive on a Windows box that way. But now it requires 2 machines to do this instead of 1. And as we need multiple test setups, this could be cost-prohibitive. Any solutions, suggestions, thoughts, words of sympathy, snorts of laughter, etc? ____________________ Follow-up: The boss chose the (short-term) cheaper, longer way -- copy the files using an app that can read UFS and write NTFS, and then (using LabVIEW) read/process/write the data. The data processing lab is entirely Windows-based, and I think they're scared of having a Solaris box in the same room... I purchased UFS Explorer, which at first looked like a nice little package. Unfortunately the translation is taking much longer than I expected. It runs at around 25MB/s. At that rate, what I thought would only take 3 hours, takes 9 hours to translate a 1TB drive, and that's not including processing time. I'm not sure why this is, since just FTPing a full drive drive across the network would only take 4 hours. I've got an email into their tech support to see if it normal to go that slow, but I'm not holding much hope out for a faster solution. So I'm still stuck with my original 2 solutions, neither of which are very good. Any one out there have a better idea? Something that would let me read a UFS file formated disk in a Windows box, so I can then process the data, and write NTFS, without having to go thru an intermediary write/read NTFS step? Cat

Well, actually it took me all of 5 minutes to put my own notes into a more formal format and plonk it in his lap. I understand what you're saying. However... Throughout this thread, I've been flashing back on a design meeting that we had with one of our user groups about a year into a major project. We had released the beta version of the hardware/software and they had come back to us and told us it was missing a key feature. Something that would take a few months and lots of $$$ to add at that point. This project actually did have several hundred pages of design documents, but nowhere did this feature appear. No, it wasn't our fault it had been overlooked, but it didn't matter. These users couldn't do their job without that feature. So we added it. This sort of thing happens (albeit at a much smaller level) all the time. No, you just sound like an actual engineer. My team leader goes on accasional rants about how despite all our college degrees, none of us operates as a true engineer. I just tell him to put his money where his mouth is. That may have lead to the request for the SOWs. Wow, you deliver User Manuals?!? Dang! We delivered a $2M data acquisition system a couple years ago, and then had to go begging for money to get users trained up on how to install/operate it. We had put together a training manual, but no one wanted to pay our technicians/analysts for a couple days worth of time to take the training. The culture here is for on-the-job training, which was fine for older systems that weren't very complicated. This one had been designed by a committee of several different user groups and was full of all sorts of esoteric functions. The fact that most of the hardware was bleeding edge technology and prone to needing fixing at first (talk about a configuration management nightmare), didn't help, either. So, here we are two years later, and we're still having to go out with the system when it's deployed. I'm a system developer, not an analyst or a technician. Some of my cow-orkers love the overtime, but as long as my software is working, I personally want to spend as little time as possible on submarines (the usual test platform). We're starting design of the next generation of our system, and I am finally in a postion to influence that. User-level Documentation will be a deliverable. There will be money for training. As we always say before a new project, "This time we're going to do it right!"

QUOTE (neBulus @ May 19 2009, 08:42 AM) Both you and crossrulz get lots of partial credit. The episode was, "The Devil in the Dark." The critter was a 'horta'. QUOTE I'm an old school Treker that never accepted any of the new versions. Netflicks offers a download service that we have set-up to be able to watch any of the episodes on demand. As soon as it was set-up we just had to watch the episode where Kirk makes gun powder to do batle with the Gorn. Boy are those costumes cheesy in high def! They were pretty cheesy in the original low def, too! QUOTE There few episodes where I remeber thee names but my favorite was (I believe) "City on the Edge of Forever" where the phrase "Edith Keeller must die." was used more than once and Spock used that wonderful line about using stones and bearskins to enhance his tricorder. My fellow trekkie cow-orkers and I often quote the stone knives and bearskins line to describe working here...

The book is by Craig Larman. I recommend it too, I'm reading it right now. The nice thing about the book is that he teaches UML and OO design principles hand-in-hand. He uses UML to model the conceptual system (domain model) and the OO software approach (design model). The UML visual serves as the "code", he very rarely shows what the code would actually look like in Java. So you can apply the principles directly to LabVIEW without a text-based language getting in the way. By the way, I love cow-orker. Every time I read "coworker", that's how I pronounce it in my head. QUOTE (neBulus @ Mar 19 2009, 10:11 AM)

I'm thinking about taking the NI OOP class. It appears I've missed the cruise, so I'll have to settle for a regular ole office building. I stopped programming in C about the time C++ was getting popular, so I don't know much about object-oriented programming in general. Every time my cow-orker who is a C#.NET, etc whiz tries to explain it to me, it sounds like he's talking about ways of accessing typeDef-ed clusters with data and their associated info. It must be more complicated than that. I looked at the LV OOP stuff back when it came out in 8.2, but it seemed like it was adding code on top of what I was already doing. Once again, I assume my lack of knowledge is the problem. My question is this: Do I need to learn C++ before I take the NI OOP course? I've read thru all the doc links I can find on this site and they've managed to underscore how little I know about the basic language of OOP. If they teach the class in that language (ie, here's how you all did it in C++ and now here's how we'll do it in LV) I'm sure I'll manage to stumble along, but won't get as much out of the course as I possibly could. Any thoughts?

QUOTE (mesmith @ Mar 23 2009, 02:24 PM) Actually, it *does* make me feel better, in a small small way. At least I'm not a complete idiot; it may be the software and not me. Maybe... QUOTE (neBulus @ Mar 23 2009, 02:25 PM) Please tell me you have been talking with NI Support to address those issues (please). That is one of the new widgets NI is pushing so you should be able to get some decent support. Well...... I have never had a lot of luck with NI support. Generally I've thrashed a problem up one side and down the other before I call them, and by that time I've tried everything they can suggest. Then it becomes a bug report... My favorite hardware experience was with the GPIB/ENet converter box. I think my serial number for that thing was less than 10. I was all excited to put it in my system. After I did, my program that had been taking a few hundred milliseconds to respond to commands started taking many seconds, sometimes minutes. After persistently bugging NI support for several days, they finally came back with the infamous line: "It's just going to be slow." My cow-orkers actually put that on a t-shirt for me when I left that lab. But, I guess I'll probably have to give NI support another try. QUOTE (neBulus @ Mar 23 2009, 02:25 PM) PS After you have your issues solved and you become our expert on this tool, you may want to take a look http://forums.ni.com/ni/board/message?board.id=BreakPoint&view=by_date_ascending&message.id=409#M409' target="_blank">at this Sea Story I posted over on the Dark-Side. Great story! Now I understand the bump on my head!

Hi all, I recently upgraded to LV 8.5.1, pretty much straight from 7.1. Especially right after startup it seemed to take longer to do things like access items on the menu bar, move a vi fp/bd, make a wire appear -- simple stuff. This often also happened when I opened up a new vi. It looks like LV hangs, I click on a window, and get a "Not responding" message in the title bar. This lasts 5 or 10 seconds, then everything is fine. For awhile. A cow-orker recently brought some of his LV code to me to look at. When it was running, he commented on how much slower it seemed to run on my computer, especially right after we pulled up the vi. He ran the same code on his laptop, and sure enough, the code ran faster. I started paying attention to what was going on when I started up LV and then subsequent vis. It looks like, in addition to a whole lot of disk thrashing, my network gets accessed every time I open up a new vi. So I pulled the network cable out of my computer, and sure enough, everything runs fine; no hang-ups. I'm guessing LV is trying to do some sort of network access. My lab intranet is not connected to the Outside World, so this may be problematic. If this is the problem, is there some way to disable whatever network access LV is doing? Cat