mzu

Something should be done about general program structure. Say, having to press 4 stop buttons is annoying and the resistance will be displayed only after everything is done. I would get a separate loop (thread) for UI (with the stop button), separate loops (threads) for every instrument, one other loop to process the data (i.e. divide one by another to get resistance). I would use queues as a mechanism for sending stop requests and data around the loops. Also, error handling have to be done in some way (another loop which accepts error messages?). One more thing.Initially I was not able to open this file. It seems to me that the characters with accents were the cause, when I renamed the vi, all worked.

giopper, I ran into this problem, and managed to squeeze 50-60% of gigabit speed on a pci system. first of all your card is PCI, and your gbit card is PCI as well, right? So they both share same bandwidth (out of total theoretical 133MBytes/s, practical ~100MBytes/s). And you can not expect much more then 1/2 of the throughput going throught your gbit network. If there is a direct link, why don't you want to use UDP, to get get rid of the TCP overhead. I do not think that Nagel algorithm delay is causing a problem here. There are 2 different characteristics of the network connection: throughput and latency. We want to improve the former, but disabling Nagel delay addresses the latter. Second thing is enabling "JUMBO frames" if both of your gbit cards supports it, and try to send data in chunks just below the JUMBO frame size (to account for UDP header). I did all the above, but I was not able to get more then ~25% of the gbit throughput. (Data was streamed from shared memory of a PCI card through Gbit network by using LabVIEW API to stream the data). I believe it has to do with LabVIEW memory management, and most important with the fact that UDP write returns only when data is actually written, i.e. there is no non blocking mode. This may justify creating separate thread to send the data over gbit network. The speed was slightly higher, but I do not remember the exact data. What I did in order to raise it to ~50-60%? I implemented my own FIFO in C++, so that it does not use LabVIEW memory management heavily. Then I implemented a reader from this FIFO which stuffed things in the UDP socket. This was done in C++. I used separate elevated priority thread and non-blocking windows sockets for that. Some simple API was provided for LabVIEW.

QUOTE (Matthew Zaleski @ Mar 21 2009, 07:41 PM) Refnum is a reference, so when wire forks you get exactely the same refnum in both wires. AFAIK, file access serialisation occurs at Windows IO manager (VFS subsystem in Linux), in other words LabVIEW will allow you to call two file access functions with the same refnum (translated later to a file handle) at the same time. The question is what kind of a behaviour do you expect from such a class in such a case? IMHO, you will have so synchronize execution between two worker threads somehow to get predictive behaviour. I have a limited expertise with OOP design in LabVIEW, but on one of my projects I have used Singleton pattern for the case like yours (http://forums.ni.com/ni/board/message?board.id=170&message.id=216094&requireLogin=False' target="_blank">LabVIEW OOP design patterns This pattern (together with other things) explicitly serialises an object access. It worked

Dear all, Task: Need to draw a pretty rotating mesh the question: any simple way to draw an anti-aliased line on picture indicator, so that my mesh does not look like this: Do I really have to draw it pixel by pixel implementing anti-aliasing manually, or develop a C#, ActiveX, ... indicator? Please, advice.

I am a graduate student, doing my PhD in experimental physics. I am finishing my PhD in ~4 month, but I became disappointed in academic career. My PhD is a experimental one, so several scientific apparatuses were built, and Labview was used in many. most of them distributed (many instruments (20+), several computers (2-3.) many required precise synchronization between different instruments including real-time feedback based on image processing software development culture was maintained: all code kept in source control (subversion was used), requirements of specifications were composed for each project, technical documentation was properly maintained for each project. Projects consisted of 500+ VIs, including multiple state machines communicating by sophisticated protocols. enjoyed every step from development of architecture development to implementation, many pieces of software became standards de-facto for the lab supervised development of couple less complex projects in academic environment. What else? Around 6 years ago had a job, where I developed number of kernel drivers for Linux and Windows. Had some taste of embedded development (C, C++, asm for MIPS R4000) for VxWorks like operating system. Developed network card driver and implemented a special purpose low level protocol. Was responsible for quality assurance on one of the projects. Was responsible for communicating with hardware engineers on another one. Debugged multiple hardware-software issues. During last ~8 years knowledge of C, C++, and general Windows/Linux architecture allowed me to connect multiple (20+) devices to Labview which did not have native driver (different flavors of cameras, nano-positioners, special controllers, raster output device, etc) Just for the fun of it I took CLAD certification and will take CLD next week. From what I read about CLA, I think I can master CLA as well – just not sure this is the right move for me now. I even have an article on Labview accepted for the last (unpublished) volume of Labview Technical Resourse. (have a pdf draft with editors corrections) I think all the above makes a strong continuation point in Labview career. The question is what kind of job matches my qualifications? Does it qualify for Senior Software Developer? Does taking CLA make me stand any better? Or something else should be done before getting back on the wagon. Any advice, please?