jdunham

But the way I would do it would be to make a plot, and then overlay it with lots of cursors, one for each plot point. Then you could trap "cursor move" events and modify the plotted data to match. So the users would be dragging the cursors around, but it would look like they were dragging the plot points. I would probably make the plot points themselves transparent or point type = 0 so that when you move the cursor, you don't see the plot point stay behind until your event handler fixes it. I don't know whether something like this already exists on the web.

Yes, if you can use static VI refs, that is far easier than any other method. You only need to load stuff by name if it's important to take it in and out of memory under programmatic control.

That is almost surely wrong. When the EXE loads and executes, the startup VIs load and run, and that's it. There is no mechanism for dynamic VIs to be loaded unless you write code to load them. George, by nature it should be hard to browse the EXE for VIs. It used to be really easy, since it was just an LLB, but finally NI tightened the security. No offense intended, but I don't want you or anyone else looking into our executables and harvesting the names of our proprietary routines. But if it's your code, you have some options. You can drop all of your dynamic VIs into "Dynamic VI Container.vi", and include that as the only Dynamic VI in your project. Then code running in your EXE could load it and get its callees from its VI reference. If that's too ugly and/or slow, you could mantain a list of those VIs (you could actually get that from the lvproj build specs with property nodes, but it might be easier to just maintain your own list). Store the list as a default value of a simple subvi and build that into your EXE.

Well I'm at 496, so I'll need to know that too. ... erm, make that 497.

A more 'modern' and reliable way to do this would be to turn or LabVIEW Web Services IIS or some other web server on each computer, and configure it to serve up the data on request. IT department can seem crazy, but making sure each computer can serve port 80 requests is a lot more secure than allowing random other computers to access \host\c$. It seems like your system is already 98% complete, but if not I wanted to suggest it. Jason

For Serial at 9600 baud, you can transmit roughly one character per millisecond, so often a motion control system will be activated by commands of 5-10 characters in length. 9600 baud is very common, but when speed matters, it's also common to run serial 115kbaud, about 12x faster. Some modern faster UARTs (serial chips) go up to 921kbaud, but that's not so common. The serial connection has a UART chip at each end, but I don't think they will add anything noticeable to the latency. Many motion control system have a pretty slow processor as their controller so the gating factor is often the time it takes that processor to interpret and act on the position update message you are sending. So, often the link latency has very little effect on the control latency.

That's a great topic. We are doing automated builds. Rather than running on every check-in, I have designed it to run every night, and it exits quickly if there are no checkins. However, I am currently only running builds on demand. The build system has a couple purposes: making sure the builds are very consistent. keeping our development machines available, since validation and building is taking several hours configuration control: nothing extra or new (i.e. driver updates) is installed on the build machine without documenting it, and there is no way for code or any other dependency to be on the machine except via an installation or an SCC checkout. options: we can build off different SCC branches, select a subset of the build specs, and apply different conditional disable symbols We were running this on a dedicated workstation, but we started using the machine for other tests, and had some issues with LV upgrades and configuration management, so I am moving the builds to a dedicated virtual machine. As far as licensing, I have been told by local sales reps in the past that the intent of NI's licensing is to make sure that each developer uses a purchased copy of LabVIEW. Since we comply with that, and since my builds are taking huge amounts of time, I don't have any qualms about another LV installation onto a VM. Another thing to consider is your source code control workflow. Currently most of our development takes place in the trunk, since merging is so awful and difficult, and we are careful to minimize conflict. Now that LV2010 allows you to store compiled code separately, merging should be easier, we could stop developing in the SCC trunk. I'd like to be keeping the trunk in a shippable state, and doing all development work in SCC branches, but we're not there yet. I have a huge to-do list for the builds, including ever more automated testing, but it's a lot of work. I would like to continue discussion of this stuff, but today is not a great day for me to write more.

My understanding is that only "Open" functions like Open VI Reference or property/method outputs can generate a reference which needs to be closed, and that sometimes closing those is a no-op, specifically when the reference is to a front panel object. Since your reference is coming out of a cluster, something else (internal to the XControl system) is generating that reference and must take responsibility for destroying it when the XControl is released.

*sigh* Well I guess that's one of the many reasons JDSU's stock price went from $1100 down to $12, or I guess the fall from grace gutted their desire to offer decent tech support. I looked at the manual a bit. Why don't you post the VI you are using? It would be easier to correct the VI than to describe how each byte should go. You definitely don't want any spaces or \s symbols. You need the escape char, and the laser number, command, and parameter bytes need to be plain numerals, that is, '1', not '\01'. So when the manual says Your string in '\' code display mode should look like: \1B09DD555\n\r. Also the manual says that if you send it an S (maybe with a LFCR, not sure) then it should start spitting data back at you for display on the terminal screen. If you send S and get nothing, then keep checking your cable and your serial port settings. If you get a stream of data but you can't stop it with a properly-formatted command, then check your command building.

Be sure to check out queues and notifiers. Although they just look like fancy ways to pass data around, they are very flexible for all kinds of asyncrhonous operations, and can act very similar to an interrupt. (True hardware interrupts are not really available in LabVIEW). Generally I would have one loop waiting for a queue or notifier message, and one loop polling or waiting on the microswitch event, maybe with a DAQmx Event or a DAQmx triggered acquisition.

It is a goofy default, but the OP has the correct value wired.

Have you looked at the files? are they the same size? You could down load a hex editor or compare the files byte-by-byte in LabVIEW. If you can find out where the difference is, it might help your debugging.

Have you called JDSU? They should be able to get you some help. Chances are you're not the first person who has had trouble with the interface. Especially given that whoever designed their protocol should be hung by his or her thumbs. If they have an example program and you have another serial port somewhere, you could run that into your first serial port and read it in LabVIEW and see what characters they are sending.

Shaun is probably right about getting rid of spaces and of course using the correct end-of-line characters, but also check whether "esc" is supposed to be a single Escape character (\1B in slash code display). The MAX routine is using SCPI commands, but given the commands you found in the manual, it's very unlikely that your instrument understand SCPI commands. Also check baud rate, data, stop bits, and parity, and flow control for the serial port settings. You can set them directly in LabVIEW VISA. Good luck.

Yeah, ditto. We use notifiers all over the place and we don't have synchronization problems. They are awesome.

So why are you using SEQs for something the Notifier was designed to do? There may be some good reasons, but if we know more about your use case, you might get more useful advice.

I think you are right in the first part "you can't protect an API" and wrong about the second "there is some degree to which you can [protect an API]". Unless you agreed to a license forbidding you to reverse engineer a product, I don't see how you can be prevented from doing so. I googled a little and found this discussion vaguely helpful. http://stackoverflow...ch-of-copyright (no real lawyers there either). Interesting point that the DMCA legislation may make otherwise reasonable activities into illegal ones. I don't think it's unethical to start a business competing with your former employer. Many, many great businesses started that way (Intel comes to mind). Many business owners underestimate the contributions of key employees or treat them unethically. Sometimes key employees underestimate the value of an organization, and leave when they would be better of having stayed. The free market is able to sort that out most of the time, dividing businesses into winners and losers. But if you're a key employee planning to break away, you ought to be scrupulous about not copying (stealing) IP and about avoiding any appearance of copying. I would say that someone's failure to do one of those has given this LAVA thread a longer life. Is that judgmental? And sorry about exploding the thread. I'm not trying to take any sides in this, since I don't know either of the parties personally nor do I have any financial stake in their arrangement. I was adding my opinions because there are some misconceptions going around and I thought there was some value in clearing them up, to the extent that I am able, since I am not a lawyer (did I already mention that?). However I have had plenty of dealings IP, which any lawyer or wikipedia will tell you includes copyrights, patents, trademarks, and trade secrets, so I am contributing what I do know. If I read some of the posts correctly, there was an idea that software copyrights would only apply to a LabVIEW diagram, or that only the diagram or an xcontrol could contain protectable "code", and that the look and feel of the panels, even though they were just subvi panels, might not be protected by a copyright. I don't think you could convince a judge about any of that, so I posted. I hope I haven't irritated or bored too many people. Trade secrets are absolutely IP, but I would agree that they are a terrible way to protect software. Protecting your software with trade secrets is basically assuming that none of the other 15 million programmers on the planet is as smart as you are. Even worse, if you turn out to be wrong, then they can protect the IP with patents and copyrighs, and then your trade secret is worth nothing. (That's what Shane is getting at, and he's totally correct). There is plenty of place in the world for protection beyond copyright, namely patents. Many software people rail against them, but they are recognized under the law, so you pretend they don't exist at your own peril. CSS is a great example. In addition to whatever copyright and patent protection they had claimed, they got Congress to write them a brand new law to prohibit formerly legal methods of imitating (reverse engineering) their product. Absolutely. NI's copyrights say you can't make software that looks like LabVIEW, and the patents say you can't make a software that acts like LabVIEW. Both methods of IP protection have served them well, which is my opinion as an extremely minor shareholder.

I think it is like that, but because queues are flexible, that decision to reuse the buffer has to be made at runtime. In fact I believe it could come out differently from one iteration to the next (especially if your program were more complicated). Therefore the dots aren't able to show you the whole reality.

What you say makes some sense as a programmer, but I don't think it matches the law as far as I understand it (since I am not a lawyer). The LabVIEW license is an authoring tool like Microsoft Word. Whether you use Word or a pen to copy a Harry Potter novel you would still be infringing. Even if you changed every 10th word, or renamed the main character as Barry Snotter, the author's lawyer just has to convince a judge that it was a copy or a derivative work, and it's an infringement. The fact that LabVIEW does a lot more for you than Word is irrelevant. Those parts of your LabVIEW work that are created by your own mind are your copyright. It doesn't matter whether they are what we call 'code', or whether they are color or layout, or whether they are password-protected or not. So if you "just happen" to put controls in the same place and the same color, and with substantially similar labels, you are probably infringing, unless you can hire some expert witnesses to say "oh yeah, everyone does it the exact same way. So I would feel comfortable making a case to a judge that using the 4x2x2x4 and error in/error out is not infringing, but I would not enjoy standing up in court and trying to say that it was the merest coincidence that my front panels all appeared identical to or derivative of the copyrighted work of my former employer. I've never seen the license for GDS, but it's very unlikely the owners of its copyright allow you to use their product to make and distribute a competing product just because you purchased a license to use their copyrighted work. I suppose both front panels could have originated from the same public domain template, but almost nobody puts software in the public domain anymore. Even if you open source your code, the norm is to use GNU/MIT/CC/etc. licensing. The AddQ version had their own copyright mark on the help description with no other attribution, which I believe would violate all of those licenses. It's a bit sad that the AddQ guys have withdrawn the comments, but if their lawyer isn't telling them to shut the heck up, then they need a new lawyer.

I am not a lawyer, but I don't find any basis to say that the front panel is "public domain". Maybe you are trying to say that the functional design of the API can't be copyrighted, but the layout, the fonts, and the verbal content of the front panel and the diagram should all be under copyright, just like the visual appearance of any movie or magazine ad.

Don't think of them as queue element refs. Any array or string wire on a diagram is going to have an allocation of a handle structure, and you will see at least one allocation dot somewhere at the source of that wire. These handles are totally hidden by the implementation of LabVIEW (unless you use CINs), so don't expect to be told "this allocation dot is just a handle, and may or may not become an dynamic object (array or string) on the heap". Regardless of any queues, pretend instead that your array wire is in a case structure. If that case never executes, nothing should ever happen with the heap; no array should ever be created, but your compile-time handle will still exist, and you'll still see a buffer allocation dot. Unless you have very simple code and there is some constant-folding going on, the dynamic heap stuff can only happen at runtime, so there's no way to show the behavior before your VI runs. So I believe it's not a correct assumption that a buffer allocation dot is shown, it means that a fresh copy of dynamic data will be generated as that node executes. The dot makes it more likely that your data will be copied, but if the run-time realizes that no one else needs the data it should be able to point the handle at the existing heap object. There is no way to know that at compile-time (in most cases), which is when the dots are drawn, so you will see a dot if a copy might be made. Jason

How does your first snippet "fail at runtime"? If you mean that it throws an error, well sure, but the correct data, an empty 2D array, will still be transferred onto the blue wire, dropped into the buffer allocated for that purpose. Now here's where I wade into the deep end, exposing near-total ignorance and waiting for AQ to rescue me... For any queue of variably-sized data, I would expect the queue itself to contain an array of handles, where the handle is some kind of LabVIEW data structure (it used to be defined in the CIN manual, if that's still around). The handle is going to point to your 2D array of data, and the LabVIEW memory manager is going to allocate memory from the heap and store pointers to those dynamic memory object in the handle. So when you dequeue an item, you have to allocate a new buffer to store the handle, but it's possible that the handle could point to the same memory in the heap. The queue itself is done with that handle because it's been dequeued, and so it needs to live somewhere else, which is in the newly allocated buffer. So just because you have a new buffer to store the handle (which is small and fixed-size), doesn't necessarily mean you have made a copy of the heap object (which is dynamic and might be huge). However if there is any chance that the 2D array in the heap is needed in some other wire or branch of the same wire, LV will have to make a copy of that part of the heap so that dataflow integrity is assured. So just because you see an allocation dot on the diagram, the question is whether it is 100% required that the heap memory object is also copied. I think using a DVR is a way to try to make sure that the the same memory object is the one in use, but if no other wires are laying claim to the dynamic memory object, it could reuse the buffer at runtime even though your buffer allocations (which is 100% compile-time information) might show a copy. Waiting to be corrected, Jason

If the mix happens to be 0% patents, it's still could be called a mix. IP is the right term for this mix. IP also includes trade secrets.

Can you drop a diagram disable structure around the subvi call you are trying to delete? Can you drop a case structure around it, and then delete the whole case structure. If you want load a VI without its dependencies, you could try moving it to some other folder on your hard drive, and load it alone. It will give you lots of warnings and searches, but you may be able to get the diagram open and delete the unfound subvis. Then you could move it back and cross your fingers and it might load. If none of that works, you can probably send your VIs to NI, and ask them to recover the damaged VI. Jason

That's what I was trying to say, but Ben said it better. The data wire doesn't branch, but you've got two 2D array wires, one in each loop, and the upper one (dequeue) could be running at the same time as different data travels on the lower one (enqueue). So you are going to need separate buffers for those two datasets unless you use a DVR to tell the compiler to try to use the same data. In this diagram, the 300ms wait and the private queue make it extremely unlikely that any other data could get into that 2D wire, but I wouldn't really expect the compiler to rely on that in the optimization.