Mike Ashe

QUOTE(crelf @ May 11 2007, 09:34 AM) "The Truth, The Whole Truth, and Nothing But The Truth" Your quote is two out of three, more than that I am not willing to articulate ...

Possibilities, possibilities ... How do you propose to convey the desired information without wires? What would really be great, is if there was a LabVIEW installation in a dedicated editor (with button on the compose post page, just like inserting a picture or link) on the web, that we could do the quick diagram on, etc, then hit a "publish" button, and it would be inserted into the LAVA post.

QUOTE(Michael_Aivaliotis @ May 3 2007, 03:19 PM) True, but this seems a cluttered work around rather than having just the Test panels open.

As a quick off the cuff example, I was involved with a project almost two years ago, where we used 5 Basler B&W Firewire cameras into a single CPU Dell computer and LabVIEW 7.1. We triggered the cameras off of a Hall sensor on a conveyor wheel to give 15 fps, but each image was then subdivided into 6 images and each of those images was processed with about 10 image functions to get the data we wanted, then output to digital out to run solenoids, then logged and archived in a local flat text database, then we provided some simple running statistics. This ran just fine, in fact we had CPU idle time of over 50%, so I am pretty sure your application above should be doable, especially with the new core2 duo machines. Good luck.

QUOTE(Gary Rubin @ May 2 2007, 08:31 AM) Very true, and patience when seeing someone explain something that has been explained before is a virtue.QUOTE I think we're starting to see a pattern here. In the last week, I've counted 4 people with 23 years combined LabVIEW experience expressing doubts about whether they were advanced enough to be posting here at LAVA. I understand the desire to run off the homework hustlers, but if it is done in a way which makes others feel unwelcome or intimidated, then LAVA will eventually become a forum that is, in essence, dedicated to a handful of people who are primarily interested in discussing GOOP and X-controls. Since I have bagged my limit of HH's here on several occasions I thought I'd chime in. Although I have been "short" with several HH's over time, I (and I think others) think the practice has usually been to try to convert them into someone who uses the forum the right way, to ask a question the right way, rather than just to hustle them off to NI's forums. I have been pretty busy of late, and have not posted or even been reading much, so I missed "The recent comments about 'go to the NI Forum' ". While we don't need unrepentent HH's here, we do need newbies, and we need an atmosphere that incourages them to ask questions (the right way) and that includes "dumb" questions. Along those lines, of encouragement, in a proactive way, perhaps there is some way that registration of a new user could include mandatory reading of the two articles many of us repeatedly point out. "How to use the LAVA Website" and "How to ask questions the smart way." These get quoted to newbies, HH's, etc over and over. Perhaps Michael could make a link to reading those a mandatory page(s) during new registration. If there were only one change, how about a quick bulleted summary of how to ask questions, post your code first, show what you've tried, and maybe a polite request to at least attempt to use English rather than "chatspeak texting", since we all have real keyboards. I agree totally that we should be very accomodating to those for whom English is a second language (don't say it crelf, I know what you're thinking ...), but if someone does not have the time to post in anything but chatspeak they probably should not complain if we reply in cryptic compressed engineering talk. Gotta go, the Kona is calling ...

QUOTE(i2dx @ Apr 23 2007, 10:41 AM) Mainly because I've been really busy lately and have not turned on the RSS feed, this being a way to insulate myself to concentrate on Real Work (using, appropriately, LV Real Time). That and the fact that I've switched to Kona lately, very smooth, so I've been purring more than growling lately. (But I refuse to call anyone "darlin").Regarding a useful template post to direct HH's to, I agree that AQ's http://forums.lavag.org/index.php?s=&showtopic=7587&view=findpost&p=28597' target="_blank">Perfectly Pithy Prose was a gem. lol

QUOTE(Aristos Queue @ Apr 17 2007, 12:07 PM) Ahhhhhhh, snifffff, snifffff QUOTE Problem: All the example code is in JAVA. Need someone to convert JAVA to LAVA. Not a project I'm going to get around to doing, but I think would be useful for someone to do. Nor will I at the moment, as I am on vacation and still putting in a bit of work there, and I'm swamped for a while back at the ranch, but .... This might be fun someday.

QUOTE(Michael_Aivaliotis @ Apr 17 2007, 03:20 PM) On the front panel Logical Clusters (LC) would normally not be apparant. You would either pick from the groups menu or popup on a bare patch of turf on the FP and select "Show Logical Clusters" or equivalent. When you did, the FP would temporarily darken and Controls that are part of an LC would have a designator or number in the upper right hand corner. Members of the same LC have the same number.On the diagram I think we would like to see this all the time. Either/or a colored number at the upper right corner of terminals that are part of a LC or some type of highlight. I like the number (or name) since all terminals with a "2" are part of the same cluster. We would also be able to popup on a terminal and select "Show/List other LC Members", etc. I like the number showing though, since it doesn't involve a menu step. Perhaps if we hovered the mouse right over the number (LC designator or LCD ;-) ) then all the rest of the members would highlight. Of course we'd have to have a scripting method to list all associated members, etc

I suggested this on Info-LabVIEW and also to NI via email a couple years ago and never heard anything from it. I suggested that it be part of the "Lock, UnLock, Group, UnGroup menu on the FP and that another menu item would show all such cluster items, like we do with cluster order now. This feature would really make certain UI layouts much easier.

Thanks to eveyone for their replies, I'll make responses. QUOTE(Aristos Queue @ Apr 4 2007, 03:18 PM) Correct, this is being used to create memory only Tags that are derived by an expression containing other real Tags based on DAQmx readings taken inside the critial RT loop. I am moving the data out of the RT loop using RT FIFOs, just like you are supposed to. For each system, however, the client will want to be able to define Memory Tags, by a configuration file that can be edited. The math is not a total parser, just 4-functions, AND, OR, >,<, etc. No trig or anything fancy. Basically just slope and offset and simple boolean math for discreets. After the real data is sent to the Tag Manager Module, it is available to other modules. The first thing we want to do is run the critical safety checks, then we want to evaluate the Memory Tags, then do all the non-critical warnings checks, etc. QUOTE Given that, why not use the stack base approaches? Yes, you try to avoid such things on RT, but if you really need them, they are there (to varying extents on the different targets). I have been so far, and it works in the non critical loops, but I have been hearing that there are issues with memory deallocation over the long haul with RT. These test stands will need to run 24x7 for months on some tests and any memory leaks, etc could cause problems. I have had some people say that any strings at all are bad things, so I was just trying to get rid of as many as possible. I don't actually want to parse the expression every time. I only want to do it once, at system startup, for each Memory Tag, then store the operators and Real Tag indexes in 2 arrays for each Memory Tag. At run time I will always run the same operators/indexes for each Memory Tag. I'm just trying to follow Andrew S. Grove's (chairman & founder of Intel) maxim that "Only the Paranoid Survive" QUOTE(Neville D @ Apr 4 2007, 04:39 PM) Have you taken a look at CalcExpress by Konstantin Shifershteyn? Yes, I have in the past. His is a good product, but not to boast, but I already have one that is better. It is a basic semi-compiler, all written in G, that has more flexibility and functionality. Somewhat like the LabBASIC tool that someone just posted here on LAVA, but not an express node. I've been thinking of releasing it as open source for a long time, but there are issues. In any event, all of these types of tools use a lot of strings and are built on stacks on the inside, therefore, build arrays, etc. They also are overkill for what I am trying to deliver. We're trying to keep it lean and mean: four functions, simple booleans, no more, and make it robust and memory efficient. QUOTE(Louis Manfredi @ Apr 4 2007, 06:42 PM) I did some work with a general parser long ago-- I think I'd rather start from scratch than try and clean up the old code. But I do recall one aspect that worked pretty well... Rather than parsing the text string each and every run, I would "compile" object code from the text string on the rare occasions that the string changed. I substituted each string, such as "*" or "^" or "sin(" with a U8 in an array. These were used to select cases in a case structure. Getting rid of the text scanning made a HUGE improvement in execution speed. If I were doing it again, I'd use an enumerated type rather than a U8. That is exactly what I am trying to do now. I am already using enums and my stacks are preallocated arrays with floating indexes. Almost like a circular buffer, but without the wrap. If you have any of that old code, I'd love to take a look at it. By the way, I got permission from the client to post code here. I will do that tomorrow after I get it working a bit more. Thanks everyone!

Hi all, Has anyone used the G Math or another math expression parser in LabVIEW Real Time? Most of the parsers I've seen are stack based, with build array and subset of array nodes everywhere and they evaluate the original text string each time through. Obviously we try to stay away from those functions in LabVIEW RT for memory management reasons, to keep determinism. I am currently working on a modified version of the "Parse Arithmetic Expression" VI to try to get something that is suitable for RT. I am substituting a preallocated "stack" of 50 variables and an index for the stack, rather than just looking for the "top". Instead of building a new value on top with build array I am substituting into the array and incrementing or decrementing the index. I'm doing the same for the operators, which I am converting to enums. Has anyone done this for RT? Ideally I'd like to parse all the formulas once and initialization of the RT target, then run with no strings at all and no array resizing functions. Thoughts and wisdom, oh wise ones? Thanks, PS: I am doing this for a client, under NDA or I would post the code I already have. I am going to try to convince the client to let me post just the parser snippets. I've just recently got the to start using openG toolkit code, so there is hope of going in the other direction.

QUOTE(Jim Kring @ Apr 2 2007, 12:47 PM) Is this an online web-based exam or it is onsite doxied?

Look in the LAVA Code Repository, under User Interface, for String Autocomplete This can be modified to do what you want.

Post your VI here, the one that you have tried and are having trouble with. Secondly, don't post with all bold or caps, it is considered shouting on forums and rather impolite.

When I have had to do this type of thing I have used an array of Control Refs and an array of Control names bundled in a cluster for the VI. For each VI that I want to do this to I create a cluster of the arrays on the first call to get a control ref. On later calls, I obviously do not get the refs again, I just search the arrays. The clusters themselves can be kept in an array. Usually, if I know I have to do this I don't even wait for the first call, I just do it at program startup and initialization. If I know I won't need all the refs I usually then filter the arrays. Cheers

Thanks for the opening post on this topic Jim. Please keep them coming. I got a lot out of the first one.

QUOTE(Louis Manfredi @ Mar 30 2007, 03:22 PM) I don't think this is dumb at all, it is adhering to the KISS principle using Occam's Razor. One of the guys who posts to Info-LabVIEW has a signoff block quoting someone else to the effect of: "Elegance in design is achieved, not when there are no more features to add, but when there are no more features to take away". I really like that. QUOTE(george seifert @ Apr 2 2007, 08:15 AM) I don't know for sure yet, but I think the delay will be too long. I don't have the hardware yet and I've never used this Corelis JTAG interface before. I wanted to have a backup plan. Having a backup plan is always a good idea, but if your JTAG hardware can handle "X" number of registers, then it should be able to handle sending all of them at once. If it cannot, I'd be pretty surprised and I'd look (if possible) for another JTAG vendor. Lastly, you can probably code up the "send everything every time" version in a very very short time, (before the HW gets there) since it is so simple. Then, if you have spare time and an itch that won't go away, you can work on a "backup" method. If it turns out that you finish both and both work, remember KISS & Occum.

QUOTE(Jim Kring @ Apr 2 2007, 10:36 AM) Not bad Jim, not bad, even though several of us suspected as much. I think it was as good or better than NI's this year. Their "rerelease" of LabVIEW 2 just wasn't up to the standards of their old years. I think the best LabVIEW related AFJ in recent years has to be Michael's announcement that NI had purchased LAVA. That one nailed a lot of us. If NI had really wanted to AFJ all of us they missed a golden opportunity this year. Since some of the patents just expired earlier this year they could have said something to the effect that LabVIEW 2 or 3 or best yet LabVIEW 5 was being rereleased with open source code, ie, all the newly patented stuff still protected and hidden, but the basic G language now free. Hmm, then again, maybe that would have been crossing the line as to what was acceptable disappointment for an AFJ, and they were just too kind to pull something like that on us. Before my second cup'a joe, it might have been fatal for me...

QUOTE(Ben @ Mar 29 2007, 07:40 AM) See Signature Block Below...

I don't think there is any way for us non-NI mortals to do this directly, make a circular control frame picture control. The suggestions above about importing images is just cosmetic. However, using Windows API calls, you can make a VI circular. So, you could make a VI that had no title bar, button bar, etc, then make the entire front panel one picture control, then make the VI round. If you get George Zhou's G Toolkit it has VIs to do the arbitrary shaping of the VI. Well worth the money. http://www.geocities.com/gzou999/ Look for the "Bitmap Shape Window" VI and example.

I did one with a FOR loop once, quite a while back. The application was a sort of Tag list, which was rather large, but the individual reads and writes were allowed to be sparse arrays. The actual read or write variable was a cluster of two arrays, one for indexes and one for the data. This allowed for non-contiguous get-set of data chunks. The FOR made this a little simpler, although it could have been written easily enough with a While.

Jim, This is great. I've often thought that the array palette was one of the ones that could use the most expansion. OpenG is leading the way in that. Are you still looking for more functions in this area? There are a couple of array functions that I use all the time that I think might warrant inclusion. Like some of the string array functions that operate in one direction, but not the other. We could use those "others". Again, thanks for all your hard work on behalf of the LV community

Hello Gurkan, Welcome to LAVA. It is great to see people who worked with 3.1 return to LabVIEW. Yes, a lot has changed, like the fact that your Ctrl+S keys don't wear out and your screen doesn't spend half it's time in blue, as in BSOD Seriously, I hope that you get and give a lot here!

Have you tried running LabVIEW in the VPC? What kind of performance hit does it make? I wonder if you could run a VPC inside a VPC?

I figured if we gave him several similar equations with several simular unknowns he could ...