Interested in hearing from programmers who work remotely.

[Mike Le]

Hey folks,

 

I'm going to be taking a year to travel around the world. During this time, I'll be doing LabVIEW on the road for my employer.

 

I have a VPN and access to our source control (thank goodness). However, I've never done remote work before. I think there'll be some challenges in terms of communicating with hardware that's on-site. I'm also concerned about passing questions between myself and the local programmers.

 

For those of you who program remotely, especially in LabVIEW/G, do you have any tips? Suggestions? Pitfalls to avoid? Best practices to maintain? Utilities or apps that have come in handy?

 

Thanks.

[hooovahh]

Not sure the kind of work you will be doing, but at one point we had some remote developers write the software to talk to a device over serial (I think it was a power supply).  The developer needed to power cycle the device periodically, to put it back into a known state.  So we hooked up a USB NI daq card, and told him that P0.0 would toggle a relay that would turn 120VAC off to an outlet.

 

Later he needed to see the device to see the status of the front panel.  So we hooked up a web cam and gave him the IP address so he could see the device update in real time.

[Jordan Kuehn]

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.

[ShaunR]

Use your mobile phone for wifi tethering (3G is about 2Mb up/down). Hotels usually require you to go through a webpage access gateway which wont work for VPN and besides, you can then work on trains, coaches or whilst having a beer cofee in the local . 3G dongles are OK, but make sure it is one that accepts a SIM rather than locked to a provider otherwise you will have to get a new one for each country you visit (phones are just easier). Get your IT to set it all up and test it BEFORE you go and SMS all the settings to your phone.  

 

For cheaper calls/internet I've always found it a lot, lot cheaper to buy SIMs (usually free) in the country with top-up cards (roaming charges are sometimes 10-20 times the local prices). It also has the advantage that you don't have to try and find coverage for an in-country provider that is buddied with your home provider so you can choose the best service (ask the locals). You can then claim it all back on expenses

 

Companies love their VPN systems but the best system I have ever used, by far, is Hamachi. We could transparently remote desktop in via satellite to PXI racks sitting on oil rigs in the Gulf of Thailand just as easily as to the lab next door. They just appeared as nodes within 2 mins of getting the satellite dish up and running. The field engineers just went from one platform to another setting them up whilst I sat in the air conditioned comfort of the beach hotel (WiFi teathered) and configured them as they appeared

 

Another point. It's always useful to have some sort of Chat program on the PCs you are supporting. If you are troubleshooting and it requires some human input, you can paste snippets, passwords, and error messages to each other much more easily than talking about it, especially if the PC is nowhere near a usable phone..

Edited May 31, 2013 by ShaunR

[Tim_S]

China's cell phone system is far better than their landlines to where we've plugged in cell phones into customer's test equipment so we could get a workable connection. Touristy cities or those that cater to businesses should have better internet connections. We've had a lot of problems in countries like India where we could only rely on phones and email at the hotel (VPN was out); this could be due to where the plants we've installed equipment in are located as the plant was built and running, but the road and power lines to the plant hadn't been built yet.

 

PCAnywhere and Remote Administrator have been good friends. Both allow you to see the screen and interact with the computer as if you were there. We typically turn down to 256 colors to help with refresh rates. I believe both have chat features, though we've used notepad to chat when in a pinch.

[bmouring]

I would recommend getting a VNC server setup on the machine that you will be remoting onto (it allows you to show what you are doing and basically act like a multi-player computer). Then, when you run into an issue/want to review something with a coworker they can see what you can see.

 

I've used UltraVNC on my old Windows machine with a fair amount of success (was out of the office for a few months, was able to do VI code reviews this way)

[jzoller]

As far as hardware is concerned... this USB over Network tool is on my list to check out.  I've also found that a serial console server is nice for remoting in to system serial ports.

[mje]

It should be pointed out if you're doing any remote coding that the LabVIEW IDE requires a bit more finesse over a remote desktop connection since it's (obviously) more graphic based than other languages. Ideally its best to keep your code development local and just drop the final product onto the remote machine, but If you need run a debugging session remotely because of an interface to some piece of hardware, you're probably going to grow annoyed.

 

I have to do this from time to time, and usually do one of two things: open the code remotely, probe and take notes, then go back to my local machine to modify the code, commit/build/whatever then finally update the remote copy and iterate as need be. Or code in a plethora of debugging displays into your application so you can just distribute it and have access to as much debug info as needed.

[Mike Le]

Thanks for all the great feedback so far, guys! I'll definitely look into the Hamachi, VNC, PCAnywhere, and USB Over Network tools.

 

@ShaunR, this might sound horrible but I actually don't have a smartphone and have never done data tethering. Definitely sounds like something I should figure out before I leave, though.

 

@mje, I do imagine coding in the LabVIEW IDE to be nightmarish over remote. As you suggest, I plan on coding on my local machine and syncing the results to the source control server. That's a very clever idea about adding a suite of debug tools into deployments, so before I even have to touch the code again I can ask for feedback from the endusers.

 

Fortunately, there's another very competent LabVIEW programmer who is local and working on the same projects. I'm hoping to be able to transfer most of the hardware communication aspects over to him - so that'll be a "blackbox" to me that my code will trust works. Though even the best laid plans never survive contact with the enemy.

[mje]

@mje, I do imagine coding in the LabVIEW IDE to be nightmarish over remote.

 

Oh, it's hardly nightmarish, it's just the latency of having to track the mouse over a network gets in the way of my normal cadence when coding in LabVIEW. Compare that to a keyboard only environment, where I don't care if there's a fraction of a second delay between when I press the action happens on screen. It's totally usable, but definitely requires a conscious slow down when working over a network. For anything beyond trivial edits while debugging, I revert to the local machine and resync when done so productivity doesn't suffer.

[ShaunR]

@ShaunR, this might sound horrible but I actually don't have a smartphone and have never done data tethering. Definitely sounds like something I should figure out before I leave, though.

Any old android phone with 3G/HDSPA will do. You just connect with a usb cable or bluetooth(for older ones). Latest models have Wifi tethering and can even set the phone to be a wifi hotspot (so you can connect several devices)

[Jordan Kuehn]

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. 

[Phillip Brooks]

Also, don't forget about enabling NI-VISA Server for remote access.

 

I've installed NI-VISA server in the lab on a PC and a GPIB card so I could develop code from my local PC with only the SCPI commands going across the network.

 

It works for other connection types too...

 

This describes the general process...

 

http://digital.ni.com/public.nsf/allkb/F3AB0B5D7DBA367C86257982005BBF2C

Edited May 31, 2013 by Phillip Brooks

[BigAngryHillMan]

I agree with all the above. I would also suggest buying a USB drive and make sure you have backed up you laptop drive to it so if a virus gets on to it or a badly formatted Linux command wipes the laptop (My boss did that in China recently) it only takes an hour or two to fix it.

It is also very handy to back up the system you are working on so you can use the image to reproduce software problems you cannot recreate in the office.

[ShaunR]

for permanent connectivity logmein.com

Logmein (logmein.com) is the Himachi client.

[Jordan Kuehn]

Logmein (logmein.com) is the Himachi client.

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.

[Darin]

Is this thread why I am getting LogMeIn banner ads on LAVA or are you guys susceptible? 

[Jordan Kuehn]

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

[Darin]

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

 

What you have failed to realize is that the ads appear and then go away for premium members, so there is a subliminal effect.  Now where is the emoticon with an Al-foil hat?

 

Edited May 31, 2013 by Darin

[ShaunR]

Is this thread why I am getting LogMeIn banner ads on LAVA or are you guys susceptible? 

 

What ads?

 

[Mike Le]

Is this thread why I am getting LogMeIn banner ads on LAVA or are you guys susceptible? 

 

What's really going to trip you out is when you discover I'm actually part of the LogMeIn viral marketing team.

[Aristos Queue]

@mje, I do imagine coding in the LabVIEW IDE to be nightmarish over remote.

If it helps, I do about half of my LV work over a VPN connection, working on my laptop but saving on my work machine. I prefer to work locally on my Mac, but because of the font size differences between Mac and Windows, once I'm going to start publishing something, it's better to maintain the code on Windows. (Dumbest part of LV in my opinion -- the lack of a standard, across-all-platforms font for use in all property nodes, diagram constants, comments, etc.) Anyway, over the VPN connection, LV is sluggish at times, but the only place where it burns me is when I'm wiring a node -- have to have a half-a-heartbeat pause between placing the mouse over a terminal and clicking otherwise it may pick up another terminal that I passed over. Other than that, the twitchy pauses don't cause me difficulties. I am not saying it's great, but I do feel it is totally workable if you find yourself needing to do that. Working on your local machine is nicer.

[Tim_S]

(Dumbest part of LV in my opinion -- the lack of a standard, across-all-platforms font for use in all property nodes, diagram constants, comments, etc.)

It's not just different OS, but versions of OS. I went from WinXP to Win7 with the new work laptop; now I have bends in wires that were strait before mainly because the spacing of property nodes and bundle/unbundle by name.

[Aristos Queue]

It's not just different OS, but versions of OS. I went from WinXP to Win7

Don't kid yourself. Those are different OSes. ;-)

But, yeah... the diagram follows the OS theme, and when it changes, argh.

[Tim_S]

I paste this into the LabVIEW.ini file of every new installation of LabVIEW

 

Good tip.    Sadly it would have been a better tip so many VIs ago...