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.

You are right, I've never test this because I use an another way to load dynamic VIs.

If you use Static VI Reference (see attachment) :

- You don't have to add explicitly your dynamic VI in your build specification

- You can rename your dynamic VI worriless

- Your dynamic VI is hidden from end-users

- code is the same in development or runtime

As far as I've understood the question, I think this can fit with the issue.

Regards,

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.

If they are include in the EXE, I think they are in memory when the EXE is loaded. Try and let me know.

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.

For the cable issue: I am using the NI USB-232/4 which is a 4 port hub for RS232 to 1 usb. As stated on the website http://sine.ni.com/n...ng/en/nid/14583 there is "DTE and DCE transceiver modes with automatic transceiver detection eliminates null modem cables" This should eliminate that problem, correct?

For the contacting JDSU issue: I have, and it took me over a week to get the following reponse to similar questions I've posted here: " We don’t/won’t provide any additional control program. The section on computer control states that control may be accomplished by sending specific ASCII strings through the RS232 port. This requires that the user write or have available a program that may accomplish this." Needless to say I have sought out different avenues to solve this problem before I take on the burden of getting any help out of them.

Lastly, referring to my earlier post that I believed the write processes were occuring without error: I attempted a loop-back test http://zone.ni.com/d...a/tut/p/id/3450 which was successful. I am than left with the question, how do I trouble shoot if my device interprets the command properly, or if it is even sending commands to be read by the computer - how do I test these?

*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

The sequence

Byte 0 ESC ESC

Byte 1 Laser # 0

Byte 2 Command 9

Byte 3 Parameter D

Byte 4 MSB data D

Byte 5 next MSB data 5

Byte 6 next MSB data 5

Byte 7 LSB data 5

Byte 8 LF LF (a Control J on a terminal)

Byte 9 CR CR ( a Control M on a terminal)

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.

The data out from the read and into the write are identical, yeah, but you've overlooked a pretty important terminal on the write node:

The "prepend array or string size" parameter needs to be set to false or LV prefixes a value to your data when it writes it back to disk. Pretty silly default value for that parameter, if you ask me.

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.

Not sure whether it should have spaces between the characters but CR and LF should be replaced with \n and \r. Try something like "esc040\n\r" (without quotes) if that doesn't work try the same with spaces. Make sure your string control in the left hand example is set to '\' Codes Display (right click menu). In the max example try the same. It's not SCPI compliant so it won't respond to an IDN? command.

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.

I don't understand what you're saying here... you can send a notification when no one is waiting on it, and it will be seen by the next Wait on Notification unless the "Ignore Previous" input is TRUE.

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 doubt anyone can protect the public interface of an API as proprietary, but those are legal questions and way out of my experience or comfort zone. I'm not a lawyer and I don't even play one on TV. There is presumably some degree to which you can say "hey, they can't copy our API. People might think it's our product" or something along those lines, but I don't know where that line is.

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 can say that there are valid technical reasons for using similar connector panes and I doubt this even has any serious ethical issues. Unless you explicitly sign a contract preventing you from working in the same field, there is nothing preventing you from building a similar product (although personally I probably would have an ethical problem with that and I doubt I would do it), and there's no logic in starting completely from scratch. You as a developer already have some knowledge and habits, the users already come to expect certain things, etc. So far I haven't seen any clear indication that AddQ has done some something wrong (except for deleting the posts and pulling out, which is a PR suicide), yet people seem to decide that they have, despite explicit denials. I REALLY dislike such judgement.

I have no idea what the technical merits of AddQ's framework are either. I asked for a demo video, but the thread kind of exploded after that, so I never got my wish.

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 in software? Like algorithms? Sure you can protect HOW to get an end result but not the end result itself (falling back to copyright).

If you don't get other protection for an algorithm (like CSS) then anyone can implement a version as long as they don't copy your code.

And trade secrets are, by their very nature, only valid when nobody knows about them. If a second company implements something which was previously a trade secret, then it's not a secret any more is it...

Seriously, does anyone thing there's a relevant protection for software beyond copyright? Seriously.

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.

NI had patented the graphical representation of a while loop... Probably expired now, but still that's one example.

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.

Going back to my original diagram I would argue that the queue could be thought of as logically connecting the wire in the Producer loop to the wire in the Consumer loop. Each time through the Producer loop the Initialize Array creates a new buffer to hold the array, and the Consumer could use the same buffer without copying because there are no branches in either the Producer or the Consumer.

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.

Yes and no. Is it a copyright issue that most programmers use a 4x2x2x4 conpane and put object in/out and error in/out in the four corners? The styles of the controls on a front panel are all part of LabVIEW's development environment and licensed to be used as part of the purchase of a LabVIEW license from NI. Therefore, unless you have special controls/indicators specific to your app (XControls might be an example), you might well put your terminals at the same spot as your competitor, if only not to throw off the user or as part of good programming style. For all we know, both front panels could have sprung from the same copyright-free template. Thinking of it, G# might even have been programmed using a paid professional version of GDS, therefore using the GDS templates they'd rightfully acquired by paying for the software. (That's a lot of "ifs"... and that's another reason why AddQ should not have deleted their posts.)

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.

Connector panes and front panel positions are not enough evidence to throw the stone because they're part of the public domain of even password-protected VIs.

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.

Also, your argument about creating buffers for queue element refs makes a lot of sense except that the Show Buffer Allocations tool specifically shows an array buffer being allocated in my snippets above - if I do the same thing and replace the the array with a string (and the array size with a string length) the Show Buffer Allocations tool now shows the buffer allocation on the dequeue as a string. So the tool thinks a buffer is getting allocated of whatever type of data the queue holds.

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

I don't doubt that you get exactly the performance you report, but I can't create a dequeue operation that doesn't show a buffer allocation . So in order for LabVIEW to "see" a data buffer in a queue is no longer required, LabVIEW has to decide at runtime that the buffer is available? For instance, the first code snippet is perfectly valid at compile time but because no queue exists it fails at runtime. So this means the Show Buffer Allocations can't accurately show the runtime allocations for a queue ? I'm confused!

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

I don't like the term "IP" in conjunction with software. It's copyright (which is enough as the GNU Licence has proven). There are no patents involved (outside the US).

IP is a mix of trademarks, copyright and patents. Only copyright applies to software. Calling it "IP" implies there's more to it than that.

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.

Labview is endlessly crashing on me.

...

Is there any way to load a VI without labview trying to load its subvi dependencies? I think this would allow me to atleast remove the problematic calls.

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

Since the output of the init array is used for multiple iterations, that buffer can not be re-used because the consumer loop mod of that buffer could goof what get queued up next time.

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.