Mark Yedinak

Thanks Phil, I found the TCP_NoDelay.llb before. I have been using that to disable the Nagle algorithm. I am working with that now to configure the connection to abort rather do a graceful close. I have also tried to write a VI that would allow me to read the values back using the setsocketopt() call but so far I have been unsuccessful. The Call Library Node always returns an error. I haven't played with calling DLLs too much so I'm not sure if I'm doing something wrong in the call. Everything looks like it should work. SOCKET_GetLingerOption.vi

I need to get down and dirty with some TCP connections and need to access the low level socket options. .NET has the items I need but I'm looking for some pointers in using .NET calls on a TCP connection created using the native LabVIEW VIs. I am writing applications that are used to test the TCP functionality of another product. Therefore, I need to be able to force various TCP conditions such as generating a TCP-RST on a connection rather than the normal graceful disconnect via the TCP-FIN handshaking. The .NET libraries have a socket option that will allow me to do this but I don't want to re-write the entire TCP VIs using .NET. I would like to be able to use the .NET calls on connections I create using the LV calls. Does anyone have any suggestions? I did find Rolf's package which provides IPv6 and SSL support. I haven't look through all of it yet to see if I could build off that. In addition, when I open the VIs they have broken arrows so I need to resolve that as well.

There appeared to be an issue in the posted version of the library. I sent secr1973 the latest version and it is working for him. I have attached the latest version of the library. snmp communication.llb

It make things easier if you are working in an environment where you are building lots of different types of applications and you want/need a generalized approach for catching this type of event. By using a standardized messaging architecture (which will work) you are limited to being able to use subtasks that adhere to this architecture. You can't easily reuse code developed elsewhere. In addition, can see a system that will spawn subtasks which are effectively standalone applications which may be terminated by the user or the application itself in a normal fashion (no errors). The controlling application will want to know that the subtask has exited. This is an area like Shaun has stated needs an overhaul. Being notified an application or tasks has exited is a reasonable thing to want to catch. Why should we have to roll our own solution? Shouldn't the language provide this as a core functionality?

In order to provide a more general solution I would like to see an automatic event generated when the subVI exits. By requiring the use of one of the messaging primitives the subVI is tied to this application. At bets, you must define a standard messaging architecture that will be shared in all of your applications. By decoupling the subVI from the messaging scheme via an automatic event you significantly increase the reusability of your code. You can easily use in int any application without requiring any code modification. The primitive messaging methods would most likely require modification of code. Even with a more generalized approach should you ever change the messaging structure all of the existing code that uses this scheme would have to be modified.

I have already posted the the idea in the Idea Exchange. As for polling, I like to avoid whenever possible. I prefer to use events, queues or notifiers. However, your suggestion does sound like a reasonable work around until a true event is implemented. This would allow any subVI to be used without requiring any special code in it. Thanks for the suggestion.

We have used the toolkit extensively with MySQL and it works very well.

So far nothing is working. I have tried Shaun's approach but I am not seeing any events in my top level VI. I attached the simple example that I have been playing with. Main.vi PanelClose Event Callback.vi Task.vit

Thanks Shun. This is close but it still requires knowledge of the subVI. This requires that the calling application knows the names of the controls of the subVI for processing. Overall this is a reasonable work around but ultimately I am looking for a truly generic solution which decouples the top level VI from the called subVIs. All I want to know is when the subVI exited. I don't want to know anything about the internals of the spawned VI nor do I want to require the spawned subVI from having to do anything special to inform the caller that it has exited. It would seem reasonable that the caller should be able to be informed of specific events of the spawned VI. I do appreciate the suggestions though. And this callback solution could be useful for other tasks.

That would work because the generic VI could simply take the name of the actual VI you want to invoke and then have it wait for the VI to complete and then fire the event. However, I was hoping that LabVIEW would already provide a general method to allow calling VIs the ability to catch when a VI it spawned closed. This seems to be something missing which would be very useful for managing spawned tasks. The caller can use the method "FP.Close" to cause the called subVI to exit. However, the reverse it not supported since it appears without extra effort the top level VI is unable to detect when a subVI closes.

This would imply polling. I don't want the top level application to poll. I would like to catch the close using an event structure.

Without requiring the spawned task (subVI) to post a message to a queue, can the top level application that spawned the task detect that the subVI exited? That is, if the top level application opens a reference to a vi (using a VI template) and then runs it. When it runs it it doesn't wait for the VI to complete so it truly spawns a new task. I tried catching the spawned task's close using the Application Close and Panel Close events but neither detect the close. I know that I could have the subVI generate a user event or post a message to the queue but I was trying to catch the exit in an autonomous manner. I wanted to avoid having to pass anything to the subVI (the user event reference or queue name) as well as avoid the spawned task from knowing that it was invoked by another VI. In C when you fork a process you can catch the signal when it exits without the spawned task needing to do any special processing on it's exit. It would seem like we should be able to do this but so far I haven't found it.

I think that is the fancy name for beer money.

I don't have any specific numbers but I can state that trees con be rather slow for updating when there are a large number of elements. The way to improve this performance is to keep a separate 1D array which represents the tree and operate in this when you need to make changes. Use the property node for the tree to update the entire tree in one shot. Using this approach I have had trees with over 10000 elements in it and it updated fairly quickly. Certainly it was fast enough that it didn't cause user angst when working with it.

I had been working with several teams and began to mentor one team. I was hoping to attend the Chicago area competition but due to some personal issues I have had to back off from FIRST during the past several weeks. I am bummed that I wasn't able to continue my involvement this year but much higher priority items needed my attention.

I would also be interested in seeing the presentations. I am disappointed I wasn't able to make it.

VISA is the recommend solution because it is the current technology and it is the supported method for communications. GPIB is the older technology and while supported it is not actively being worked on (new features). Also, you never know when you will need to use some other communications interface. At the moment you may only need GPIB but if this application lives on it may need to use other interfaces in the future. (Think you equipment dies and the only option is to replace it with something that doesn't have GPIB. Most new equipment use USB or Ethernet these days.)

If you use the primitives in .llb file you can specify the community name. The two primitives that you will need are the "SNMP Get Request" and "SNMP Get Response". You will also need to use the "SNMP Get Random Port" and the "SNMP Close Port" VIs. If your device uses different community names for the different branches you will need to separate the requests. A single request can have only one community name.

Mark Yedinak = Mark Yedinak Nothing creative with my user names on either forum.

And this helps someone with LabVIEW in what way?

I haven't played with the lossy queues but what does the timeout do in that case. Will it wait that long before it queues the data and discards the oldest entry? Alex, I would recommend that you use an event structure for capturing your user events. By doing so you will not have to poll the values of the control and your code will be more efficient because your UI task (loop) will be doing nothing unless an event is detected. In a polling model it is constantly doing something and chewing up CPU cycles. (Of course if you only have the base version of LabVIEW you are stuck since NI does not provide the event structure in the base package. Something they really should do.)

I don't have experience with deploying packages, only using them. It may or may not solve your dilemma but thought it might be worth taking a look.

I'll jump in late to the conversation but I like my kindle. I will be traveling more frequently now as well as a minimum of one trip a year to India. I love to read on planes and carrying around a ton of books is simply not practical. A trip to India and back is about 40 hours of flight time for me and I could read quite a few books in that time. It is a lot easier to just load the Kindle up and have tons of reading material available. I also like the extensive amount of classics that are available for free. Reading on the Kindle is very easy on the eyes too. Let's just say that I am with Cat and Chris on this, I love my Kindle.

Does your installation package the various plugins? This may help if the installation were to update all the components. This does bring up an interesting issue though of how you can manage updates to the plugins. Have you considered using JKI's Package Manager?