John Lokanis

Since the Send function is self contained, I designed it as a fully encapsulated function. I pass it the machine name, port and VI to call. It then does everything in one shot. If I was to cache the VI Server ref and the VI ref, I would have to devise some sort of FGV mechanism and then find a way to deal with multiple calls to this re-entrant VI that are directing the message to different targets.

Oh, and I would love to hear a detailed explanation of the similarities and differences between the root loop and UI thread, including all the potential blocking operations.

The reason I went with this message architecture is it was the only one I could think of that did not require any polling on the receiver's part.

I have been working on an architecture that uses VI Server to send messages between application instances, both local and across the network. One of the problems I have run into is the fact that VI Server calls are blocked by activity in the root loop (sometimes referred to as the UI Thread).

There are several things that can cause this: other VI server calls, system dialogs (calls to the one and two button dialog functions), if the user drops down a menu but does not make a selection... (I'm sure there are more...)

Since this is a pretty normal way of communicating between applications, I was wondering if anyone had any ideas for a work around.

Here is a basic description of my architecture:

Message is created and sent to local VI that sends to outside application instance.

Local sending VI opens VI server connection to remote instance. It then calls a VI in the remote instance that takes the message as input.

This remote VI them places the message in the appropriate queue on the remote instance so it gets handled.

If the remote instance root loop is blocked, the sending VI on the local machine is also blocked.

I could try to eliminate all system dialogs from the remote application, but that only partially addresses the issue. I really wish a future version of LabVIEW would eliminate this problem with the root loop and VI Server all together.

BTW: using LV2012 but this issue exists in all versions.

-John

Resolves host name?

Yup. I love to see new devs scratch their head when they see that in my code...

Know what this does?

Thanks Darren. I will give that a try. Any speculation if a wizard will be forthcoming in a future release?

Was looking into creating a project template for our team using the new features added to LV2012. Before I dive in an start hacking away at it, I was wondering if anyone has created or found a wizard to automate the process a bit. The only doc on NI's site (http://www.ni.com/white-paper/14045/en) I could find made it looks like a rather tedious process to do this manually.

I was actually surprised they would create this feature and not build a tool to guide you through the process of making your own template.

thanks,

-John

Wire Warrior - That is exactly how I am setting up my reuse code now. Glad you are having success with it.

Paul - I see why that would be good in your case. My reasoning is I want to have visibility to dependencies to in-house code. I want to hide dependencies to 3rd party (NI, OpenG, general purpose re-use) code. This is because I will need to trigger a build if my in-house code changes so I want everyone to be thinking about that and know where things are used. The other code is not likely to change much so I worry less about that. But this may not be an issue to you or you might have other ways of dealing with it.

As to the re-use code I do put in user.lib via VIPM, I also want that code to be available via the palettes when editing. The re-use code that is more specific to our company's projects is not something I feel the need to have available via the pallet and can store in our separate area on disk. Also, we are calling it directly from that separate area, where as the stuff in user.lib is never edited there but instead its source is kept separate and it is installed to user.lib where it is called from.

I hope that last paragraph made sense!

Thanks for the reply.

In the case of reusable code, such and the XML libraries, I was planning to have thing in their own project along with their unit tests and keep that physically in a shared code area (not user.lib) along side the projects that use this code. Then, in the main project, I would have virtual folders that point to the folder where the shared XML code is.

I was mainly asking if all the class folders should be at the same physical directory level or if it was an ok practice to nest them (not by inheritance, but by some common area of responsibility, like dealing with XML or a database or an instrument).

I prefer to limit the code in user.lib to reuse code that is very generic, like OpenG type stuff and to install it using packages only.

Also, I prefer to not have anything in the dependencies other than vi.lib, user.lib and OS files (.NET DLLS). I make a virtual folder for everything else called external code or shared code so I can see that when looking at a project. The dependencies are just too out of sight, out of mind for me.

What about groups of classes? Like if you made several classes that deal with reading and writing XML. Would you put those into a separate folder under your classes folder in your project?

I am looking into better ways to organize my project files on disk. The existing setup I have used for many years is not conductive to LVOOP classes or easy code reuse. So, I am looking for some 'best practices' information on how to layout my various project folders and organize the classes and VIs and support files within. I need to get this correct upfront before I start building and committing anything to SCC, as rearranging it later is a pain.

I did some searches for information on this but came up empty. I am hoping someone can post their thoughts or a link to a good article or thread on this subject.

thanks for any help,

-John

Well, the only way for my 'server farm' to be aware of each other is to have this central coordination application that they can register with. If I do not implement that, then I cannot transfer data from one instance to another.

This is not central to my overall goal of separating my view from the model and making my system 'client-server'. It just would have been a more flexible and 'clean' system if I could have decoupled this so asynchronous processes that needed to coordinate actions could live withing different app instances. Perhaps I will pursue this again in the future.

Thanks everyone for the input. It was all helpful.

Having a central server can lead to a single point of failure for the entire system. So, I think I may have to back off on this goal and do something more rudimentary, like having the coordination restricted to an app instance and not allow networked coordination. Since that solution already works well, I am inclined to stick with it. That just means my load balancing will have to be more granular and controlled at the client level and not by the server. And fail-over will not be a possibility. I think I can live with that more than I can live with the risk that all my systems go down if the single coordinating server goes down.

I've never really used SVs before so I suppose I need to do some reading and experiments. But, the problem I need to solve is all the machines on the network will be siblings with no central server, so they all need to be servers to each other. I really want more of a peer-peer network where they can automatically find each other and coordinate.

As to UDP, the solution has to be 100% bulletproof, so perhaps that is too risky.

The answer to #4 is yes, in one circumstance. I have other use cases as well but that is the basic one. So, it seems you are saying that using the low level UDP and TCP functions is the way to go, vs using some sort of share variables or network streams.

I figured the network streams were the wrong path, but I was hoping there was a way to do this with shared variables. Since each machine will be running the LabVIEW Runtime, each one could host a shared variable. The question becomes: can I create and destroy these variable at runtime? Can others find them at runtime?

If not, then your suggestion of using UDP and TCP seems like the only way.

As for the number of systems, currently we can have up to 50 'siblings' using the same shared rendezvous at a time. And there could be 10s of these type of groups operating independently So, the code would need to be able to differentiate between these groups and allow a sibling to join the right group, without affecting the others.

All machines would be on the same local private network, but not necessarily the same sub-net. There would no no firewall issues as this is a closed private network.

To address the issue you listed, I would need to support a sibling leaving the group either in the controlled way or if it crashed, having timeouts to deal with that. I already do this in the code that uses queues to accomplish this.

My biggest concern is how to broadcast a unique named connection and have others join that connection while ignoring other simultaneous broadcasts.

I am designing a method for multiple application instances to coordinate an action across a network. I have previously implemented this using queues for coordination of asynchronous VIs within a single application instance. I now need to make this work across a local network. I have been looking at network shared variables, network streams, TCP/IP, UDP. I would like to know if anyone else has accomplished this and what you learned along the way.

The basic requirements are:

• N number of independent applications need to coordinate some action (essentially a rendezvous).
  
• No one application knows if the others exist. (don't know their IP or anything about them)
  
• No one application knows if it will be the first to join or will join later.
  
• All applications will share a common name for the rendezvous.
  
• The first application should create the rendezvous
  
• As other join, they should see that the rendezvous already exists and join it instead of creating a new one.
  
• All applications should be able to see how many have joined.
  
• When all applications depart, the rendezvous should be destroyed by the last one to leave.
  

Thanks for any tips or examples you can share.

-John

Well given that this 'trick/feature' was used in the Core3 materials and WAS NOT EXPLAINED, it is going to lead to misuse and abuse. When my coworker asked me to explain it, I could not and told him he was right to think this was bad form. I prefer any such operation to be explicit. The implicit nature of this will lead to confusing bugs in the future.

One of my minions is working thought the online Core3 course and showed me some code that made no sense to me. I am wondering it this is a bug or some little known feature.

In the code, he was told to wire a variant to the 'variant to data' function and wire in a path constant so the output would be a path. This was later wired to a function needing a path input. So far so good. But later in the same code (in a different case) he was instructed to do the same thing but this time there was no input to the 'variant to data' function to tell it what to cast the variant data to. But for some reason, the output was still a path and he could still wire it to another function that needed a path as input. Here is a screen grab of the magical code:

So, what is going on here? Bug?

One of my ideas finally made it to 'In Development'! WooHoo!

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Detect-runtime-installers-needed-for-installed-components/idi-p/960679

I always flush the buffer, read 10000 chars with 1ms timeout and then send my command. I also make sure that my target is not set to echo the command. (or if it does, I deal with it explicitly).

This has worked well for me in a large system with 100s of ports for many years.

I suspected as much. Looks like "build your own" is my only choice.

Here is a strange request but I am casting a wide net to see if anyone has seen a solution to this.

I need a device that can route a USB dongle to a DUT's USB port. I need to be able to simulate the insertion and removal of the USB dongle without physical access to the dongle. I need this to be controlled via Ethernet.

Ideally, this product would allow me to insert a single USB dongle and route it to multiple DUTs simultaneously. If that is not possible, I could insert multiple dongles and route them 1 to 1.

So, why do we need this?

Well, our product is designed to boot off a USB dongle and get us a basic OS that we can then use to load a full test OS from a network server. But, once we install the network OS, we want to reboot and not see the dongle anymore. Right now we need someone to physically pull the dongle from the DUT. We would like to automate this process.

thanks for any ideas, thoughts or sympathy...

-John

Did anyone record Darren's Tips and Tricks session? I was so disappointed that I had to miss it...

I have used both. They both seem to work, but the mobile app does not show my personal events I have setup.

The mobile app is better at showing me what other sessions are available at a particular time.

Cant believe my whole calendar is fully booked and I had to skip several key sessions again. NI really needs to gauge interest in the sessions before they lock in times so they can avoid overlap of the most popular ones.

I got an email from NI with the links and my access code. I would have assumed everyone who is registered and paid in full should have gotten the same email. Maybe I am a beta tester of the system?

I would check your registration with NI to verify everything is correct.

The session register is up and running.

Access the NIWeek App online or on your smart phone.

• On your PC/laptop go to http://portal.niw2012.alliancetech.com/
  

• On a smart phone go to http://mobile.niw2012.alliancetech.com/
  

You will need your confirmation number to sign in.

For some strange reason there is only one 'What's New in LabVIEW 2012' session and it conflicts with one that JKI guys are doing. Bummer...