Leaderboard

Actually, the Shift Right with Carry is O(1); since all processors (to the best of knowledge) have a shift instruction making it a single instruction (perhaps 2, if you include the register check), rather then the 3 from you version. As for a memory efficiency, I'm pretty sure that no data copy is made since the shifted value is not used. Feel free to benchmark it, I found that the Shift Right with Carry had a 2x improvement using a 64bit Integer. Though unless your doing millions of Is Odd evaluations the calculation time is insignificant. I just don't see a reason to have an OpenG function for this operation, since the Shift Right with Carry in already available. I included the VI I used for the benchmark. Is Odd.vi

It is not only important where to bend a wire, but also HOW to do it: Here is RCF plugin which does the job. Seriously, the Invoke Node you are searching for is "Create Described Wire": "Wire Desc" input is tricky one, because you have to specify coordinates of wire nodes in opposite way - as an array of (y,x) pairs...

Yes, that's the node I ment. Working with LabVIEW FPGA I make use of that function all the time. The same node is also useful for divide by 2, along with the shift left with carry for multiply by 2 .

I with AQ I think on this - I'm not sure it's a particularly common problem and the code to do it is both simple and obvious. Sure, one could make OpenG an incredibly rich toolkit but with the danger of it taking longer to search for the right function than it would to write the code inline directly.

I'm working on a new re-use library which I hope to have in a semi-complete state within the next month. It will ultimately contain much of what was discussed in another thread, but I figured I would post what I have to date, mostly because all the discussions with people at NIWeek have recently got me pretty excited about the advanced OOP based frameworks that are being worked on. I figured I'd throw mine into the fray for comments as well. It has what I hope to be the next version of my MessagePump framework, and some supporting classes (Callback, and descendants). For the uninitiated, message pumps go by other names such as message loops, event loops, or message dispatchers in other languages. In more traditional LabVIEW lingo, you could recognize a message pump as a consumer portion of many producer-consumer based architectures. I'll point out that there are some completely unimplemented classes in the attachment as well, this is literally an export from the current (incomplete) source code I'm working off of. If you download the current snapshot, you'll find a project file in the root directory, or you can browse right to the examples folder if you'd like. This code is entirely pre-release and not complete. Please do not redistribute it. Of note: The MessagePump is now entirely a by reference class. The public interface handles only DVRs, and does I think a decent job of defining an overridable interface which by necessity must be by value (and is not public). As before I've gone through and made some fairly verbose examples, I think they do a good job demonstrating the fundamental use cases for the class. Speaking of examples, I dislike #2...It's too much too soon and I need to find a better demo case for callbacks. For now though, it's what's we got. If you recall the original MessagePump, you'll notice the pump is now entirely FIFO based (no more posting to the front of the queue), and there are absolutely no built in synchronous posting methods. This was a conscious decision. Finally, unlike the first version which I had been using for about a year before submitting it to LAVA, this version is entirely new and hasn't really been put through it's paces. So if you see something that doesn't seem right, say something...it probably isn't! Note the code is 2010 only. I don't think it can be saved for previous versions as it uses some of the newer features. LabVIEW.Messaging.2.0-PR01.zip Have fun, -Michael

I've also experienced TCP/IP issues with Windows 7. We haven't fully isolated the issue but an application we have that sends quite a bit of data over TCP/IP in Win7 experiences lots of problems but runs like a charm on XP. I also did some traces of the communications and the traffic pattern in the Win7 cases was very strange from a networking perspective, including unexpected TCP-RSTs.

Hmm. Yes. A bit of a trend apart from LV2010. And it may be why I cannot see any problems on my machines (none of the examples fall over after running for 29 hrs now ). My windows TCPIP is highly modified from a standard install. It was the only way i could "reliably" get TCPIP transfer rates of up to 80 MB/sec. (Not in loop back; across the network). The sorts of things that were changed were the TCPIP auto-tuning, and Chimney Offload. Also had to play with the TCPIP Optimiser, but can't remember exactly what now. This was in addition to the TX buffers. But i wouldn't have thought 25MB/sec would/should be that much of a problem, but I guess it is windows eh?