shoneill

QUOTE (Aristos Queue @ Mar 21 2008, 11:47 PM) Apologies for a bit of a thread hijack... The new info about sub-arrays (for me - Since when does LV work with sub-arrays?) is fascinating. So does this mean that we can "undecimate" a sub-array coming from the "Decimate Array" function? Does it also mean that if we do a 3x Decimate, then we have 3 sub-arrays basically all pointing to the same array in memory with different start and stride settings? I assume there are optimisations made based on the assumption that all of these sub-arrays are mutually exclusive.... What happens when we Interleave sub-arrays of the same array in the same order they were decimated? Does this simply return the original array, or does it create a copy? I suggest a new INI setting SuperFunkySubArrayWires = TRUE. I don't like LV doing things like this behind my back (Unless I program it that way). Shane. Ps I just spotted NevilleD's post..... Can this "Decimate (Continuous)" function re-create the original array? Can't this lead to a race condition if other sub-arrays are also running around?

QUOTE (Pollux @ Mar 25 2008, 05:19 PM) It's a common problem if you are entering a text-based model. It's not the most efficient way, even though it is very flexible. You COULD write some hard-coded model VIs which can be switched at run-time by passing a different reference to the LM function. This requires that a change in the model recorrelates to creating a new VI for that model. You can then optimise the code within the respective VI. The gains in speed by using a hard-coded model versus an interpreted one must be weighed against the flexibility enjoyed by the string method. I had the situation once where I started doing multi gauss fits via text-based LM (LabVIEW 6.1) and the fits were taking something like 20 or 30 minutes to complete. After switching to a hard-coded model (And making a few optimisations) I got the fitting time down to something like 5 seconds. Without my extra optimisations (in the LM module itself) I was timing it at about 30 seconds. Even that is a 60-fold increase in speed. If you NEED the flexibility of a string model, you will always be slower than a hard-coded model. How are you interpreting / entering the model string? Shane.

QUOTE Are you saying that this VI Is only included when the VIsion builder is installed? That's a bit weak from NI. What are we supposed to be able to do without a simply copy function? Are these VIs at least included in the run-time licence for the vision module? Shane.

I wonder if he was a Futurama fan? Shane.

QUOTE(Aristos Queue @ Mar 8 2008, 01:10 AM) I have done the .mnu thing, and it works pretty well. Awkward if you need a mnu for each class, but at least it's possible. Native support would rock! Shane.

QUOTE(Aaron L @ Mar 7 2008, 12:29 AM) Aaron, The setting of the TermChar settings should be done only once immediately after you open a reference to the serial port. There's no need to call it in every loop. It might even have detrimental effects. Shane. PS Glad to be of help.

@Dan Thanks for the reply. IIRC I never actually tried setting the TermChar and ASRLEndIn AND using events. That's probably my problem. @AAronL Set the number of Bytes to read to the maximum you should ever receive. I typically set it to double my maximum packet size. The reason is that the VISA read will terminate whenever the number of bytes was read OR the termination character is received, whichever comes first. So we remove the limitation of our Nr. of Bytes by telling it to read s silly amount of data. Then it will quit when it receives the LF Character. Of course, don't set the Nr of characters to read TOO high, otherwise you'll be risking locking up your program...... Also, set the termchar options immediately after opening the port, before the wait. Otherwise it'll miss the first X events. This actually seems to be a downside of my approach. With user-controlled Buffering, blocked programs can be avoided nicely. Is there a way to trigger an event on the serial port? Preferebly without OS calls? I suppose a break might do it, huh? Shane.

QUOTE(ASTDan @ Mar 6 2008, 05:19 PM) Dan, slightly off topic here, but How do you get them to work? I've tried them in the past, but I can NOT get them to work...... On the other hand, isn't this basically what the VISA read does in the background with "ASRLEndIn" set to "TermChar" ? You're also not guaranteed that the string read at this time is only up to the TermChar. Timing effects (especially at hugh Baud) mean you still have to deal with reading more characters than you want and buffering and so on..... Shane.

QUOTE(neB @ Mar 6 2008, 02:36 PM) True, True. It would of course be required to check and received string for a proper \cr\lf combination, otherwise buffer until both are found...... I personally prefer the half-half approach of leaving the buffering to the OS and just taking string by string (or sub-string by sub-string if some buffering is required). Generally though, any element of a termination character should NOT be present in the transmission data. It's just good design. OTOH, much in life is simply beyond our control..... Shane

QUOTE(Phillip Brooks @ Mar 6 2008, 01:11 PM) Why not just do this? http://lavag.org/old_files/monthly_03_2008/post-3076-1204806507.png' target="_blank"> "10" is the ASCII value for Linefeed. You can also set the termination condition seperately for both in and out directions (Bottom enums). These are found under the "Serial Settings" for the Serial Instr reference type. All others are found under "Message Based Settings". Shane

QUOTE(Justin Goeres @ Mar 5 2008, 04:11 PM) I agree (obviously judging by my previous response). It's enivitable that, due to either space constraints or pure optical luxury, different "groups" of block diagram objects get to overlap. Moving that "group" is, as Justin says, a multi-step operation. We have a graphical language. The visual representation (orientation of objects) has a lot to do with understanding how the code works. We (I'm not quite sure who "we" are, but either way....) automatically group parts of code with similar functions visually on the BD, so why not lock their positions to each other? This allows us to pull the whole code section somewhere else without either destroying the arrangement or needing to do a multi-step move. Another case I would like to address is inherited code..... I can imagine some cases in which code would have been MUCH easier to clean up if I had this tool available. I also think it's something NI HAS tried. I too would be interested in knowing if this is even probable.... @Ben. I think as per normal usage, a group behaves as a single unit. Shane.

QUOTE(T_Schott @ Mar 5 2008, 02:34 PM) Yeah, but this would be an extra option. I like the idea (I've never tried it, so I don't know if it's already possible or not)...... Just my 2c Shane.

QUOTE(BrokenArrow @ Feb 26 2008, 08:16 PM) OK, People, please forget I even posted here. I live in Switzerland, and I get confromted with the comma, point argument quite a lot, so this is why I thought the problem had to do with that. It doesn't. If it did, a 3.51 would NOT be rounded to 4, it would be rounded to 3. As to the "format deal" I don't really now what you're referring to, but I meant that if scanning from string, one must let LV know what type of decimal seperator we are using, otherwise it gets all confused. Shane.

QUOTE(micman2 @ Feb 26 2008, 04:59 PM) Er yeah, like I edited my text: My interpretation of your original question was incorrect. QUOTE PS Scratch that, it seems that what normandinf says is correct. Your problem lies elsewhere. Shane.

If you are converting from string, then you need to take the decimal point character into consideration. You seem to have a comma set as the decimal point (3,51 not 3.51), so you need to let your "Scan from string" function know this is being used, not a ".". You can do this with "%,;#%05.2f". The %,; tells the interpreter to use the "," as the decimal seperator. Shane PS Scratch that, it seems that what normandinf says is correct.

Oops, Yeah, I re-read the post. It is indeed a different kettle of fish entirely...... I had looked into a similar problem regarding what was essentially the travelling salesman problem, and I kind of "recognised" that from the original post. Darned Neurons, playing tricks on me again. I'll punish them by drinking copious amounts of beer! Shane.

QUOTE(Yuri33 @ Feb 15 2008, 08:16 AM) I don't think that's what was meant. The algorithm is also called "the travelling salesman" and it's anything other than trivial. EACH point needs to be visited exactly once. There is only ONE optimal path. Search for it on Wikipedia. Shane.

QUOTE(Neville D @ Feb 13 2008, 07:46 PM) I repeat: QUOTE What you need to realise is that the DLL calls are all configured as Reentrant. For some reason (The wisdom is beyond me unless it's a bug-fix) all the VIs CALLING the DLL-nodes are NOT set to be Re-entrant. This effectively makes the calls NOT reentrant. It's not just the DLL call, but also the VI the DLL call is in. Shane.

QUOTE(TiT @ Feb 11 2008, 04:30 PM) Well that's true for sure. I'd expect the "problem" to get fixed though..... Any idea if the newer versions of the IMAQ functions are any different? Unfortunately I don't know ANYONE in Austin...... Shane.

QUOTE(TiT @ Feb 11 2008, 02:19 PM) But why aren't they reentrant when they're installed?! Given the amount of marketing with "The multicore crisis" and so on, you'd think these VIs would be optimised for parallel processing. It's not like Vision is an area where this kind of thing wouldn't be expected or anything..... Ask my NI engineers. Hmm, tried that a few weeks back. Didn't help much. I suppose I'll try again though..... There are times I really DO notice the geographical distance to the US of A. Shane.

QUOTE(Ernest Galbrun @ Feb 11 2008, 10:35 AM) Congratulations. I'm assuming humour mode...... Good luck.

QUOTE(lraynal @ Feb 11 2008, 10:55 AM) I've had the same problem. What you need to realise is that the DLL calls are all configured as Reentrant. For some reason (The wisdom is beyond me unless it's a bug-fix) all the VIs CALLING the DLL-nodes are NOT set to be Re-entrant. This effectively makes the calls NOT reentrant. I've played around with simply setting the VIs to Re-entrant, but this seems to lead to the occasional problem with the IMAQ functions. I think there are certain functions which can be made reentrant (without problems), and others which can't. Maybe newer versions are better? I was using the 12t Quarter 2007 Developer suite version. Shane.

QUOTE(TiT @ Feb 6 2008, 10:19 PM) I'm certainly not the most qualified to post on this, but..... Dynamic dispatch means that the ACTUAL code being called is dependent on the CLASS of the object being passed to it. The default method (VI) in the parent class must be overridden in a child class. If a child is passed, the child VI is called. If a parent is passed, the parent VI is called. The "choice" is determined at run-time if I'm not mistaken. Shane.

QUOTE(Justin Goeres @ Jan 11 2008, 10:13 PM) You mean like he would have derailed 24 vehicles in half the time?

QUOTE(Aristos Queue @ Dec 12 2007, 06:22 PM) Correct. first post: "How does one actually create multiple constant instances of an object with different content without creating a new Class?" second post: "So you take a snapshot from a "live" object (with different data as the default)." I'll try to remember that in future..... Shane.