Mark Yedinak

There is a function in LabVIEW to retreive a reference to the socket. You can use this to manipulate the socket outside of LabVIEW. I used it to adjust the TCP buffer size. There is also a VI to return a UDP socket ref.

See this NI forum link...

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.

Thanks for expaining.

Personally, I'd prefer a standard messaging architecture. When a VI exits unexpectedly (assuming this is what your trying to catch) I'd want to no why. That is, the error value on exit.

While I can see how a built in event would be easier, I'm not sure if it would be more useful than queues and notifiers to my typical usage.

~Dan

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?

How would this event be more useful in managing spawned tasks? (As opposed to using and messaging primative queue, notifier, user event.) If the Dymamic Asynchronous VI (Daemon VI) is running in its own call stack and exits autonomously, wouldn't the VI Reference of that VI become invalid? If so, I'd suspect that the VI Ref terminal in the "VI Exit" case of event structure on the top-level (spawner) would be invalid and otherwise useless.

I don't mean to knock your idea. I'm just missing how this would be useful.

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.

Are you averse to any polling, or just polling in your top level (UI?).

Maybe define a 'monitor' task that is run at start and receives an event ref and notifier.

Pass your task VI instances via the notifier (or queue or functional global or carrier pigeon) to the 'monitor'. The monitor would periodically evaluate the array of task VI refs by checking the Execution.State property of each ref; generate an event for each vi that is not 'Run top level'.

I smell an Idea Exchange suggestion in this problem...

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.

You might look into the LabVIEW Database Connectivity Toolkit, though you may not have a license for it. You can use the evaluation version to see if it fits your use case. Additionally, there has been some code written specifically for MySQL that works well, albeit much slower than the toolkit.

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

Yes. The callbacks were also saved in 8.6.1.

I've attempted to save back to 8.0 and took them out of the LLB. Hopefully converted them all, but labview was very insistant on saving them in its current version.

Try these anyway and let me know.

Download File:post-15232-1241736385.zip

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.

This kind of involves a level of involvement I think you're looking to avoid, but you could try using a generic wrapper VI to call the actual subVI and signal the top-level VI in whatever manner you like. To use an event structure, I suppose you would have to pass something into the wrapper VI so that the top-level is aware of it as well.

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.

Check the "VI's in memory" list?

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.

This thread is cracking me up.

There's a "LAVA fund"??

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.)

I am trying to make the last "snmp get" file from last post to work but i have no success.

The device has private OID, how can i change the community name from public to private?

In which vi do i change it?

OID 1.3.6.1.2.1.1.1 works ok

OID 1.3.6.1.4.1.32111.1.1.2.1 DOES NOT [enterprise.private] work in the same device

Thanks...

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.

Here is what i have come up with for creating tabcontrol and pages at runtime in vb2005

Dim i As Integer

Dim temp As TabControl() = New TabControl(1) {}

Dim SComp2 As String() = Nothing

Dim CNT As Integer = 0

temp(CNT) = New TabControl

temp(CNT).Name = sString(3)

temp(CNT).Location = New System.Drawing.Point(Val(sString(5)), Val(sString(6)))

temp(CNT).Size = New System.Drawing.Size(Val(sString(7)), Val(sString(8)))

temp(CNT).Tag = Val(sString(2))

'temp(CNT).TextAlign = ContentAlignment.MiddleCenter

'temp(CNT).ForeColor = System.Drawing.Color.Black

'temp(CNT).BackColor = System.Drawing.Color.LightSalmon

SComp2 = sString(4).Split(";")

For i = 0 To SComp2.GetUpperBound(0)

temp(CNT).TabPages.Add(SComp2(i))

Next i

For Each ctrl As Control In SplitContainer1.Panel1.Controls

If TypeOf ctrl Is GroupBox Then

If CType(ctrl, GroupBox).Tag = Val(sString(1)) Then

CType(ctrl, GroupBox).Controls.Add(temp(CNT))

End If

End If

Next

And this helps someone with LabVIEW in what way?

To clarify the timeout is the amount of time the enqueue will wait for a spot to become open in the queue.

For queues that have no size limit it's value has no meaning.

a timeout of 0 simply means the node will not wait if the queue is full and will discard the input element.

Mark

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.)

The installation used is a separate scriptable installer used due to the scope of the end application. I can update the components, but LV apparently doesn't always respond favorable to change one of the components. And yes...this is my current dilemma in trying to update the plugin VIs/controls etc. Am not very familiar with the JKI Package Manager and unsure at this point if I want to try and introduce another level of complexity to this system and deliverable. Do you have any experience with the Package Manager?

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.

Thanks....this is a very complex large app that is a plug-in based architecture. The main app is an executable and the plug-ins are just distributed VIs...this is kind of the answer that I expected, I just wanted to see if anyone had come across a better way to do this. And yes...I use projects...much easier to view all the pieces that are used!!

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?

How are your applications deployed? Are they built as stand-alone applications or are they actual VIs? If they are stand-alone applications you shouldn't have issues with new applications using updated versions of VIs. If you are distributing raw VIs and hoping to keep everything up to date the only option you have would be to recompile the VIs. You could potentially write an application that would go through your code and load, recompile and save the affected applications but this isn't an ideal solution. This application would need to have a list of the applications it needed to update and somehow report any failures it encountered. This would make the maintenance process fairly complex and subject to problems. The best solution is to build your applications are stand-alone executeables.

Also, are you using projects for your applications? If not you should really consider using them. They help to manage this process.