ShaunR

Yes. This is a similar VI that it used in the "OPP Push File" in the LAVA CR. It opens a file and reads "chunks" that it then sends (in this case) via bluetooth. You need to do the same except with UDP rather than bluetooth..

Just read 65k bytes (or 1500 bytes is better for the reasons Rolf outlined) from the file at a time and write it using the UDP write. However. As GregR stated. It is not guaranteed to be recieved in the correct order, or indeed a chunk to be received at all! So that's not a lot of good for files, but usually acceptable for audio or video where a lost frame or two doesn't matter too much. The easy solution, as others are saying, is to use TCPIP where all the ordering and receiving reassembly is handled for you (as well as other things UDP doesn't do out-of-the-box such as congestion control, re-transmission of lost packets etc). If you really must use UDP then you will have to code all that yourself (unless missing or incorrectly ordered file chunks is acceptable-for TDMS it wouldn't be). There are a few examples of reliable UDP (RDP). Noteably UDT and NORM. I am not aware of anyone doing this in Labview however, since it is just easier to use TCPIP.

No. I'm saying the payload cannot exceed 65k. If you can send 1 payload (of 65k) every 10ms then that would be 6.5 MB/sec

Under windows, the default udp datagram size is 1500 bytes (i.e the default MTU). The maximum it can be is 65535 bytes (you can set it to more than this, but it will still be limited to 65k ). This is because the UDP header field is a U16 and cannot represent more than 65k. UDP, User Datagram Protocol

Indeed. A good example. The "never use globals, they cause race conditions" is a one line, easily conveyable axiom, that you should adhere to, until you can put forward convincing arguements for using them and demonstrate that you understand the implications/pros/cons. The "no bigger than one screen" is the same. The only major difference (for me) is that I have not come accross a single scenario where it cannot be achieved or, even, where it is not an improvement. Show me an example where you think it is better to have a sprawling diagram and I'll attempt to "improve" it. Sitting on the fence just hurts your arse "Single screen coding" are words you put in my mouth. I have already intimated that I "aspire" to 1/4 (of my) screen for diagrams. That should still fit on yours even at 640x480 Not really a code smell. I iteratively develop. So I design in a very much top-down manner but develop bottom-up. As each increasingly higher layer gets laid down, so natural re-use appears and gets encapsulated (within the framework of the design). Each bottom segment goes through a few iterations before it is "worthy" of becoming a module. That happens module-by-module, layer-by-layer. Eventually you get to the UI and all hell breaks loose. I came to the conclusion quite a while ago that our brains are wired differently (not in a bad way, just different). For me it is just breaking the code into bite-sized chunks that I can paw over. I find it much easier to analyse a small VI and only have to remember its terminals when thinking about interactions with the next. It is the same as only having to remember the API interface, not the details of the insides of the API (so yes, encapsulation). To me a diagram is more akin to a UML model than code and the sub-vis are layers within the model. So (learning from Crelf) What is a "typical" LabVIEW user? I think a LabVIEW starter thinks in this way. But by (initially) requiring less than 1 screens worth of spaghetti, they eventually start to see the patterns emerging that experienced coders see in the minds eye (this I think is the beauty of LabVIEW). So yes. The sub-VIs may not be encapsulating correctly or "as the book says", but from module-to-module, project to project. They soon start realising that they have done that before or that "the VI I made last week almost did that". After a while they have thier own little set of "utils" that appear in every project they work on. If you allow them to just throw code at several screens worth. That never happens (couldn't resist). Like I said. Bite-sized chunks and the modularity/re-use drops out. Good code is code that works, flawlessly. Thats all the customer is interested in. It doesn't matter if it is one digram that fits on a whole roomfull of screens. I am proffering that more than one screen is shoddy programming. Why? Because I have to run the whole screen in debug to see one bit of it (and assume I don't know which bit I want to see yet). If you have 4 while loops on one screen (that I have to keep scrolling around or it keeps jumping around to see where it is executing) it makes it so much harder to debug. Compare that, say, to 4 icons in the middle of the screen. Instant 4 breakpoints. Instant 4 probes (i.e their front panels) and I don't need to go chasing dots around with the scroll bars. Plenty of room for notes and comments and (if you have sanely labelled, used distinguishing icons and a put in a tiny bit of thought into the design) I can identify identical functions at a glance and have a pretty good guess which sub-VI I'll probably be looking into first. I can also run them separately, two at a time or any combination of the 4. I can wait until the FP controls have some data in them that I'm interested in. Stop it. And run it over and over again whilst looking inside. Oh. And it looks better

Most of the overhead is the front panel control (of course). I get about 1.5ns without it and 40ns with it (still using the +1). VI overhead is vastly over rated for this sort of stuff. Shove it in a sub-VI and you can get it down to about 0,3 ns

That's a bit arse-about-face. It promotes readabilty and forces you to think about modularity. There is no excuse for scrolling all over the place, it is a symptom of poorly thought out modularity and hierarchy. It has become more "acceptable" because it is so difficult to encapsulate queues and notifiers - hence my preference for named queues with a string input (it enables very simple encapsulation of them).

Forums are a much better format for in-progress development IMHO. You are also far more likely to get contributions to bring it to fruition. You can decide on a license that suits you and is much clearer to people than the NI site. Additionally, once mature and if you decide to, it can go as part of the Lava tools network, a package under the jki thingy, or just remain in the CR with no major headaches. Documentation isn't that rigorous (readme and version history if I recall). Perhaps start it off in the uncertified. Nice work.

Hmmm. There is something weird with the vi that cannot be shrunk to less than 50px. If you create a new one you can shrink right down to the toolbar. Haven't figured out why that one is stuck.

Another Win API example...... (press a key to stop it)

According to the text in the code....yes

The enable terminal will prevent the FEEDBACK VALUE (FV) being propegated not prevent the action of the +1 as it does in your top scenario. So,after initialisation (FV=0) you get an output of 1 since 0+1 =1. So the feedback node is behaving as expected, however your shift register example is not equivelent. Below is how the feedback node behaves in your example.(I agree with Todd-the enable terminal is not a good usage for this scenario).

มีดื่มสำหรับผม. ชนแก้ว ฝรั่งติงต๊อง

A good one would have been that NI are releasing a "Home/Hobby" edition and service packs for LV 2010 and down.

I like using 2 monitors (when they are availabe-I just use the inbuilt windows extend desktop). However. I still maintain that diagrams greater than one screen is shoddy. I use them in a slightly different way in that I will have diagrams on one screen and FPs on the other. It saves a lot of hunting through the myrriad of windows and moving FPs from over diagrams when you switch to a VI (if you aspire to one digram being less than 1/4 of a screen , you can work on 4 VIs at a time with no fuss )

In principle it's a good idea. However...... 1. All "patches" that I want can only be supplied by NI and, after one year, I have to lump it (I still use 2009 through choice). 2. Isn't most of what you are proposing exactly what the JKI thingy is for? (and I still argue that NI should have their own) 3. One mans meat is another mans poison so what some might see as "valuable" another almost certainly will not (all the items you list in No.1 for me). 4. If I see "useful stuff" it goes on my "G:\" drive which has 3 directories (2009, 2010 and 2011). Each is an exact duplicate of arbitrary "useful stuff" downloaded from forums, bits and pieces I've written and other miscellaneous bits and bobs (2009 is the "source" and gets copied accross to the others now and again). Each installed version on the dev machine(s) has it's search path pointing to the appropriate verson on the G:\ drive (the 2009 dir is backed up in SVN). Very little gets installed in the palletes above and beyond the vanilla install except my own re-use code (there are only 2 of them) and others on an as needed basis for that project (which are uninstalled after completion). This is the way I avoid dependancy and "compiled for later version" hell. I should perhaps also add that most of my work is on machines that are intentionally not internet enabled so "whoops I forgot to download and install that package" is not a viable proposition (sometimes machines are in different buildings or even in different parts of the country). The 2009 directory copied to a usb stick solves all that.

Depends whether it was run from within a project or not

OK. I get 1ms accross the board (even 2011f2). This is just loading it straght up and running. However. Add the file to a project, dbl click and run-> 256 ms.

Yeah. Sorry. Not much for you to go on All 1ms (LV2011x32SP1 andr 2011x64SP1 Win7 x64 and Win8 x64) About time you put in a capital req for a new PC

They are all 1ms for me (including the first one).

Using OpenG Zip Tools On 64-bit LabVIEW I think they are waiting for Rolf to find some time

Well. "the company purchases the license to use at work" isn't really what they do. They buy a license to enable them to produce product. Where its produced is irrelevent. I suppose an analogy (albeit a poor one perhaps) would be you don't need a different insurance policy to drive a company car out of work hours. However the arguement would be along the lines of "if they (the company) hadn't bought the software/license. Could you have legally produced the code?" The answer is only a difinitive "yes" if you have a license in your name, that you have bought. Otherwise you have used a company resource as they have the payment receipts, license and inventory ledger stating that they have it, You, on the other hand, merely have access to it whilst you are in their employ - under their license). Combine that with the work for hire clauses and you really don't have a leg to stand on.

All the NI licenses allow installation on a home computer. This is the "trap" that many people fall into when creating 3rd party LabVIEW software outside of their working environment (using employers resource to create the code) and gives the employer very strong arguements to claim the code as theirs.

Well. The glib answer is find a company that doesn't implement slavery (we own you, everything you do, everything you think and everything your cat thinks!). But pragamatically I don't think there is a particular recipe because it depends (on which country, who they are, whats in your contract, whether you used their resources etc). Perhaps this will at least point you towards the right questions and some of the issues involved. http://answers.onsta...-st/20136#20136 I've generally found, most companies don't care until you produce something they want. So they would let you do it then want to take ownership citing your contract etc. In terms of contracts, the bit in your contract that says they own you has to be mitigated, but that may be an "unfair contract" clause in some western countries anyway. The biggest problem with LabVIEW is that not many people can afford to buy the software outside of thier working environment (the classic arguement for stating ownership). But I understand some people have negotiated with thier emplyoyers that the employer buys the software for them rather than the company (and they keep the license when they leave). However. I would hardly say that was usual.

The structure of file paths in the exe layout changed after 8.x. You could try checking the 8.x layout to see if your problem goes away and, if it does, it will confirm it is a file path problem.