JamesMc86

VISA close releases the resource, VISA clear clears the buffers but keeps the session going. See http://zone.ni.com/reference/en-XX/help/371361J-01/lvinstio/visa_clear/

What is the message? Is it simply an Ack or something more. I think this is a question of responsibility. It sounds like this manager is a zone manager. It is receiving messages and dispatching to the zones so it strikes me that likely it should also be responsible for returning messages about the zones. Now if it is a simple ack that the zone has been modified, as the zone manager is responsible for performing the modification it should also be responsible for generating and sending the ack message. If this is something more specific then it should probably be generated from the zone somehow but the zone manager is still responsible for communication with the outside world and should be in charge of the communication. In the context that you have given I think this would be my preferred route but I suspect any that you describe could be successful.

I would make another vote for a TCP version. VI server isn't going to be designed for messaging performance so there is going to be trade offs but the performance seems like the biggest problem. Yes calling is simple but you don't get anything for free, each message requires: 1. Connection made to LabVIEW application. 2. Remote VI found, loaded and called. 3. Reference opened to existing queue. Each of these offers a new point of failure in the system. What you could do as the best of both worlds. You should be able to make some TCP code to accept requests and package this into a single VI which you can just drop to any application to add the ability. This could then maintain connections to clients to give the best performance but there's nothing to say you can't still make a calling VI that opens a reference, sends the message and and closes the connection again.

I created something like this at Uni. It was quite rudimentary and have been planning on improving it for a while so I will try and dig it out again.

This is common across scripting methods as well. In many cases it is a practical issues that the changes are modifying something that can't be changed post compile. In this case as a read only i guess this doesn't apply but perhaps has simply not been added to runtime due to it being private

Ah sorry I'm with it now, so not it is the object of the input being matched to the object of the target, not the type wire of the target, but we get the type wire out to match the input. I'm with the program now!

I still haven't gotten my head around this VI. From the help file (and Icon) it appears that it is specifically designed for downcasting in the case where LabVIEW may not think it can go as far down the hierarchy as you know it can. I think it is specifically for downcasting as upcasting can be done just by wiring (with a coersion dot) but the examples here show it can be used for upcasting as well. My question is what exactly is the difference between this and the stock downcast. I believe the downcast will also throw an error if the cast cannot be done. It appears to be designed to be an inline operation, everything suggests there must already be a object.

Another thing to look for, are you calling any express VIs? I don't know the reason behind it but when you monitor VIs on an RT target they show as a clone of the main VI, I presume the same must go for the main environment

It's true the cache should contain all that is needed although I wonder if changing platforms has more practical issues in tracking the changes, at the minute I have not been able to dig out much on the algorithm that is used. As a thought is this something where packed project libraries could help? You could have most of the code compile for x64 in these which will alleviate the issue if your code organisation suits this. I guess it would require a change in dependency locations as well though so maybe not (null)

I have the advantage of working for NI so I have ready access to PXI FPGA boards which can read the lines and return what they see. If you have any this is quite straight forward can can give 5ns resolution. The risers look good but remember that the trigger lines are one the additional connectors, not cPCI/e connectors. (null)

I think this is probably due to the fact that 64 bit is a different platform. This means you open the VI and the compiled code is for the wrong platform which forces a recompile. Even with a seperate object cache I think that because the compiled part of the VI file is for another platform it has to start again (null)

Hate to be a bearer of bad news but it is a bug that has been reported as CAR 366331. It was originally reported at http://forums.ni.com/t5/LabVIEW/2012-Dynamic-Event-Registration-Array-of-Controls/m-p/2120100/highlight/true#M688441.

To do this without any sort of structure around it is really tough, computers are still way behind where humans are in terms of object recognition. There are a couple of main approaches that I can see: 1. create a depth field using a 3D Imaging technique ala Kinect. This is the approach that many take as the hand will then stand out from the background and be distinguishable. 2. Single camera object tracking. The vision module has some pretty good object tracking algorithms included in it now. One of my colleagues has been playing and managed to get it to track his eyes. The proble. With this will be identifying the object in the first place, the hand, and it staying consistent enough. This would also require whole hand gestures, it is unlikely to be able to pick up finger movements. I suspect a scheme similar to this is what the new Samsung interfaces uses, although that appears to pick up some elements of hand changes. I hope that helps, there maybe more schemes out there but these are the two that I am aware of. James

Ah ok that sounds like a good route. I would guess something based off the state pattern sounds like a good idea then, although in this case rather than direct API being the interface the queue provides that.

I don't know exactly how VIPM deals with this but there are two external interfaces to VI server, either TCP or activeX. My thought is they would have to use activeX to be able to actually launch the application, but this would be Windows only. Of course there maybe something I'm missing, you could also launch LabVIEW using system exec, but you would not be able to control it through this.

Sorry inline was a bad turn of phrase, what I meant was a subVI in the process rather than a parallel process. I'm not sure what target you are using but if you are pushing it that hard then I would think that the transport of the data and thread swap maybe a problem overhead as well but it would be interesting to know if not. That being said if the process can continue processing data while the main thread continues then this would seem a good way to go. I would be interested to know how this goes, I'm always intrigued by oop on RT and primarily where it might break down.

What are these VIs doing? Are they too slow because of the processing or because of the dynamic dispatch. I am intrigued by a form of channeling pattern for processes so that you can have common code. Swapping the dd vi means changing the object type so I gues you need some form of fsctory method which loads the new object with the new VI. I would think about breaking down these processes in a more defined and/or fixed way though where possible. I highly doubt this will be faster than an inline VI (but will make the code parallel) and debugging is going to be a nightmare if the processes do have fixed responsibilities.

I would say yes. A good API should throw an error if it is unsuccessful and an absence of an error should mean the action has been taken successfully. I would say if something didn't throw an error in this case it is a bug with the API. If something works but extra messages are required then warnings should be used although not many of the core Apis use these often. In terms of memory leaks I would suggest that it is bound to be possible if there are bugs however I think if you are getting repeated errors to an extent these are leaking memory then you have a different issue. If you detect the error and shutdown the application then I would argue the leak is somewhat irrelevant as it won't occur under normal working conditions.

Surely the same logic can follow for these as well? I think this whole discussion highlights the need for a solid error handling strategy. There are specific errors you can handle there and then such as a network connection failing and use local error handling such as retrying a failed opening but good central handling will catch and handle those errors that you cannot anticipate and I promise you cannot consider every error!

Hi Crockett, I tried this lately with some success. I would recommend a couple of tools potentially. Using tortoiseGit then allows you to use similar settings to tortoiseSVN for diff and merge. I personally didn't like tortoiseGit very much for the workflow, I felt like it hid a lot of the functionality I was seeing on the web so I installed git extensions for windows for the day to day workings but tortoiseGit for merge and compare because git extensions runs in Cygwin so it wasn't very easy/impossible to point this directly to lvcompare. I have only got as far as experimentation though so someone may have a more complete opinion after using it for a while.

It does sound like you are missing some dependencies of your plugin VIs (this would have them report as broken). Using a source distribution for those VIs allows you to include all of their dependencies so you are sure that nothing is missing. I think packed project libraries could also be an alternative as they compile the code but I think people have had other issues with complex hierarchies in these.

What other modules have you used previously successfully? I find it odd that the different modules would have much of an effect, the underlying transfer mechanisms should be the same, but these would be potentially at the faster end of the spectrum. How many chassis do you have on one link as well? I guess the other consideration is that the latency would be increased, I presume you have a decent enough timeout but maybe the DAQmx driver dislikes the increased latency (but again why this module!). I would probably suggest getting in touch with your local NI branch, they should be able to get in touch with R&D that will have a better idea of lower level differences.