ShaunR

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.

I've not come accross Quad-tree but I have come accross R-Tree

An AE is already a singleton (thats the whole point of them). It might also be worth noting that the AE is synonymous with class methods.

Well. Some are better than others. But a single byte (max 256 permutations) coupled with 2's compliment yields many more collisions than is useful.

As an aside....... 2's compliment as a CRC really sucks. For example, just try entering the string PLPARM01:0500000000:0400=32 [/CODE]

Dare I say it? This is one of those cases where you would probably be better to go for a class and use the run-time polymorphism. That would allow you to have overrides for each en/dequeue type without having to worry about checking and casting and (assuming you only have one of each type) you wouldn't need a "database".

Well .this isn't a new phenomena. And the accepted way is to create a LV2 style global to get the reference. In fact. I supplied exactly that solution for this thread (although it was for events). I've also noted that JGCode uses this method in his classes. KISS.

Sweet. The padding length (in most cases) is dependant on the size of the block (16=128 bit block) so it really needs to be configurable. I've modified your padding VI (to account for the block length) and added the ANSI, ISO and PKCS5 (Ver 2.0) methods.

Rather than register et al. Wouldn't be more appropriate to use "add mapping" and "delete mapping"? (in a similar vein to add to list, delete from list). That semantic is fairly universal and you yourself used "add" to describe the register.

Give this a try

This Shawn bloke obviously knows what he's talking about

Hmm. So are you saying it is data tracking rather than interfacing (like different comms interfaces, different functions etc)? Maybe a DB would be a better way forward and could simplify your heirarchy to series 1,2,3 etc.

There are a few of the NI example exams coded in LVPOOP here. That'd be a good place to start since NI have equivelent examples in "proper" labview .

Operator Error

Like Tim_S. I assume this is an NSV issue since I've never seen 8 second delays with TCPIP. I havn't timed it, but it usually breaks the connection as soon as the LED goes off on the port although WiFI can be problematic for this sort of thing. You could open another connection with straight TCPIP just to monitor to see if it disapears since a lost wire will affect all connections on that wire/card. If you go that route, then it's sometimes a good idea to have it in a separate exe running in the background so that it also crowbars your main application (taskkill /f kinda thing).

No. You cannot cast clusters containing variable length items (like strings and arrays) but the clusters can be contained within an array and can be compund types. If you could set the length of the arrays to be a specific value, then you would be able to use arrays etc within the cluster (as you can with FPGA), but this feature isn't available in normal LabVIEW. The cluster is synonymous with the C "structure" (struct) which also cannot define variable length arrays within its definition.

Is that a euphemism?

Not quite what you are probably thinking. I added serial to the transport.lvlib. So I didn't exactly produce a polymorphic VI directly from the serial frames of the AE, but to all intents and purposes it is the same.

Well. My "negative" comments are'nt so much about your code. More about the serial implementation of VISA. The fact that once you are in a "read" you are stuck until it times out (not even the vi stop button will have an effect) means that you are forced into checking bytes at port and re-implementing the timeout. This makes any serial vis far more complicated than they need to be (and incongruous with all other VISA interfaces). My "positive" comment would be "if it's not broke, don't fix it" and you have proven it works since you state that you have "used for some time". Therefore it's only a style thing if anyone is going to comment. Anyhoo. Up until recently (well a year or two ago). I too used the action engine approach also. I eventually split out the sub-frames into separate VIs and pulled them together in a plymorphic VI. This has a couple of minor advantages over the AE in that you can have different terminals for each action, different icons (if you so desire) and a nice little drop-down under the VI instead of a typdef (slight readability improvement IMHO). You could just wrap the current vi in some more VIs to achieve this rather than pulling out the frames as I did, but it was just a personal preference and brought the serial in-line with tcpip and others that I chose to go that route with. Wrapping in a polymorphic VI at this level does have one disadvantage though. Since you cannot nest polymorphs, it means you cant wrap higher level protocol vis that use these into a polymorphic VI. It forces you to make protocol dependant serial transactions (e.g reads based on a byte length) an item in the drop-down at the same level (flattens the hierarchy and couples dependancy).

2011 SP1 Bug Fixes

Unlikely to be Cat. Ballistic weapons don't work too well in submarines Must be using LabVIEW 2010

OK. Which one of you has a brown sweater? : http://www.dailymail.co.uk/sciencetech/article-2108129/Railgun-Video-shows-hit-targets-100-miles-away-7-times-speed-sound.html