Jordan Kuehn

Ah, yes that makes sense. I don't think you can make any splitter zero pixels, though I'd love to be proven wrong.

A classic splitter with the same color as the background produces no border for me? Even when it is stretched out pretty wide.

That would be pretty funny to me if it were. I don't see the ads though

Yes the company also makes Himachi. Himachi is different than using the web-based client. Himachi must be installed on all the computers in question to form the VPN, must be connected to the 'cloud' server so it can see the VPN, and windows must not get confused with it and a real network adapter on the computer (this happens to me frequently). After that all it gets you is a local IP address to use to access with whatever remote tool you care to use. Logmein is far simpler. Just requires installation on the computer to be accessed and then you can remote in via any computer with internet access. So, yes related, but Himachi provides a very different experience. It is useful if you need a VPN, but I find the web client to be far easier and more reliable for remote access.

Hamachi has worked for me before, but it was slow and a bit annoying in my experience, though it is a very quick and simple VPN. For quick and dirty connections teamviewer.com works very well and for permanent connectivity logmein.com is excellent. The first requires software loaded on the computer you are using, the second just requires an internet connection. Additionally it can be used on a smartphone in a pinch. I've used UltraVNC and the like, but in my experience the hassle of getting it set up correctly, ensuring the correct ports remained available, and having the software be installed on both machines was problematic. The two options I mentioned 'just work' unless IT is extremely restrictive.

Other than staying focused (which is a problem in the office too at times since coworkers can be distracting), hardware is probably the biggest hurdle. It obviously depends on the kind of work you'll be doing, but I'll be working more remotely than usual this summer and plan to bring a cDAQ, cRIO, lots of modules, several sensors and anything else I can think of to at least approximate a system I might need to design and work with. If it is too large to transport, you'll most likely run into issues similar to what hoovahh describes. Having a machine that you can remote into that is connected to whatever system you are working with is helpful and I have also made use of a webcam occasionally. Identify someone who you can apologize in advance for bugging with your problems and supply them with :beer_mug: as needed or is appropriate.

Would this accomplish what you are trying to do? Quick and dirty, but it gets the idea across. Edit// Interesting looks like the snippet tool doesn't care for the linked nodes. Edit x2// Here is CCT capture. Much better.

I think it may require an add-on for firefox, but it works just fine in browser. I almost exclusively use it in browser.

I've been using Feedly daily since the announcement. After spending a few minutes tweaking the layout to my liking I almost prefer it over Google Reader. I believe it meets all of your requirements.

http://www.news9.com/story/22301266/massive-tornado-rips-across-moore-hits-elementary-school The tornado ripped through Moore, OK this afternoon. 16 miles north of our offices. It's heartbreaking to watch the coverage. Preliminary report is EF4 or bigger.

Two approaches. The first should be what crossrulz suggested.

Both of those look good to me. From your response I take it that there is no consensus yet though. If I were to go and make a one-off diagram, it would likely look something like what you made in your example, but if there is a 'right' way to go about doing this I'd like to conform to a standard. If one doesn't exist, it should.

I've been working with the Actor Framework for a little while now, and have been watching some of the CLA Summit videos (thanks for those btw!) and I'm wondering what is the best practice for documenting the architecture of a system built with the Actor Framework. In one of the videos AQ mentions that UML doesn't have a representation for this. The class hierarchy gives a small glimpse into what is going on, but doesn't describe how the actors are interacting and the messages that are being passed between them. I gave the Symbio tool a quick glance and it didn't immediately seem to provide the outline I was looking for. I want to be able to generate a diagram quickly and easily that describes the architecture so I can hand it to someone and say this is how things work. I can create something by hand that is UMLish but I'm wanting to ask all of you guys to see what your approaches have been.

James, Thanks for the benchmarking. How do things perform with added load on the SVE in terms of additional NSVs?

I have considered this and is a big part of my favor of this implementation. The NSV is hosted on the cRIO, but I don't care to use them for local processes and favor more traditional communication in general.

Thanks for the suggestions everyone. The action engine seems to be the more robust approach in regards to guaranteeing the completion of the initialization in the RT code, though the others that monitor the variable are also good approaches. Using the action engine then takes the NSV out of any functional code and merely publishes the data to the host, which I like. I may wind up implementing a mix of approaches here, we'll see. Thanks again.

Not to detract, I don't have much knowledge about Git(hub), but HG + RhodeCode provides a nice interface and you have complete control over the server rather than trusting the 3rd party to host it for you. Not that BitBucket isn't also nice.

Especially if the default tolerance would automatically adjust according to the type of floating fixed point number wired into it. (misread and thought the title said fixed point. would still be cool if it could automatically adapt to fixed point inpuits).

Once during the initial initialization and continuously updated in the loop that communicates with the FPGA. All in the RT code. I will think about this suggestion. Basically you are suggesting making a FGV for local access and using the NSV to keep the communication back to the host (the only reason why it is a NSV). This is a well established project and modifying the current communication process is a much bigger change than using a NSV to monitor this flag.

I've seen this behavior as well. Especially with case structures and simple 'state machines'.

The network variables are hosted on the cRIO where the code is hosted. Unfortunately the SV needs to be written in at least two locations, immediately after initialization and then it monitors the status subsequently. It's checking the Drive Status of a 9501. We've had problems with it failing under heavy vibration and this flag is an early indicator. NI doesn't have a fix for us, so we need to at least know when it is dead.

Thousands of people use LabVIEW and NI products every day to great success. I've made many systems that work day in and day out without failure. Otherwise I'd be getting constant calls from our customers. I don't know why you aren't succeeding, but I'm not certain you are pointing your fingers in the right direction. You mention you have some code developed in house and some code developed by a 3rd party. What made you bring in this party and are you certain everything has been integrated well? I'd start with looking at the quality of their work. Finally, if you are convinced it is an NI issue I am confused why you come here to complain about them not taking care of it. Their support can take a while to filter up to R&D if you have a legitimate bug, but you will get there or will have your problem fixed. If no one can reproduce it though, it is very difficult to not look back and ask what is happening with your system.

Have you called NI? Have you tried to resolve this problem with them? If not, why are you complaining about NI not having a fix for your problem? That's like me going to change my oil and complaining about how my car manufacturer has some strange problem with the shifter. A problem that no one else can reproduce. I don't think that NI is perfect, but you are being unreasonable. If I were NI I'd tell you to go change your code to C++. Your disposition would certainly turn me off from being an 'external partner' that would provide you >1000 VIs.

Google found me this: http://labwerx.net/

It looks like this was the issue, the network variable was intermittently getting populated in time. Race condition fixed. I cannot recall if the original problem code had the NSV error wires connected or not, but they are now and a small delay has been added afterward. No issues since. Thanks for the suggestions.