Cat

Hi all, I have a strange little problem. I have two computers talking to each other via TCP (thru a router). Computer A sends out a short (1200-ish bytes) message via TCP Write.vi and Computer B responds with a different short message. This happens every 10 seconds. Here's the strange part... If I disconnect the network cable from Computer A during the 10 second wait, the TCP Write from Computer A still "completes" without an error even though there is no physical connection to the network when the function executes. It's not until Computer A tries to read the response from Computer B (via TCP Read.vi) that it errors out (with error 66, which is another problem). This lead me to believe there was buffering going on with the write and it just didn't know there wasn't anything out there to talk to anymore. So, I tried disabling the Nagle algorithm (both manually via the registry and then using TCP_NoDelay.vi) but this seemed to have no affect. Any comments on what I'm seeing? If this is buffering, is there any other way of forcing the TCP Write to actually write (and hopefully throw an error)? Cat

When I got labSSH a year or so ago, it didn't have 64-bit support. I can't tell from the blurb if that has changed any.

No, no. This was a very important thread. It gave hooovahh his best tag line: "Maybe Hoovah is really Crelf's alter-ego, which he uses to irk people?" (Gary Rubin) On a more serious note, here's a link to the Wiki that examines the actual topic of this thread. It's really interesting to see how it all turned out. Whether one believes in GW/CC or not, it looks like there was no "scam".

Michael's response was: "We don't offer that anymore. Thanks for asking."

I just did...

I really need to re-up my premium membership. I assume we're still stuck with PayPal? I've searched far and wide for info on what to do and come up with mostly stale links. Help!

I have a project with a top vi that (along with a bunch of other stuff) calls a couple other vis dynamically. This top vi also uses shared variables to communicate with a separate executable, but there are no shared variables in the dynamically called vis. I have an application build specification set up for this project. When I build the executable, after the build is done, the source version of the dynamically called vis mysteriously start running. The front panels don't appear, but errors messages in there come up (since they're not being "called" correctly). The executable built from this works correctly. I just figured out today that I don't even need to build the executable. If I just open up the specification, click on the Shared Variable Deployment category, and cancel the Build Specification window, the source for the dynamically called vis starts. FWIW, I call these same vis dynamically in other projects, and this behaviour does not occur. The project I'm having a problem with is the only one where I use shared variables. I haven't had any luck finding a similar issue online. Since this is my first time using shared variables, I don't know if there's something I'm supposed to be setting/doing that I'm not, or if I've stumbled on a bug. Any thoughts??

The screen resolution and font size/magnification for the different systems has to be the same in order to avoid objects and text moving or resizing.

Over what must be by now multiple decades of interaction, I never ever ever ever thought I'd say this: Rolf, you are WRONG! :P

Just don't tell my boyfriend about her.

Surf your way to here. Somewhere around post #35 the thread wanders off onto the topic of the stability of various versions. Everyone seems ot have adiferent opinion. I had nothing but trouble with LV11. LV12 SP1 works fine for me. YMMV... (and yes, conditional loop indexing is great!)

Must. Hide. Bends.

I am definitely a pixel-pusher. Gives me something to do when I can't figure out how to fix my crappy code.

I had the same reaction regarding trees, multicol listboxes, etc. and all I've had to do to program around issues in the past. Also, I was severely bitten in multiple ways by 2011 -- the last "stability release", IIRC. I installed 2012 the moment it came out and got rid of several big problems. I'll be waiting for all of you to test out 2013 for me before I upgrade.

It seems to be working in my 12.0.1f2 (64-bit) version. What are you running?

I agree, like I said the tech support guy was very helpful. I just don't get the sense they have a team of programmers who can hop right on recompiling their code. And yes, the whole issue of whether or not I can even officially use labSSH is another tangle. That's what I thought I'd do at first. But I will have multiple destination ips depending on the ever-changing system setup. So programatically building a command line just seemed easier. Our installation of putty doesn't include the telnet utility... Yes, I guess what I'm saying is that from my (admittedly biased viewpoint) I'm using the telenet protocol but not telnet server. We are actually extremely lucky to be working with some folks who understand our environment -- a submarine is considered a closed secret container, and is guarded by big burly guys with guns at all times. I think they will be reasonable. Of course we had to go outside of our own organization's IA/IT people, who think that how recently the fire extinguishers have been checked is just as important as how recently a virus scan has been done on the computers in the system. Definitely no sense of humor there.

She knows all the tricks -- she's been programming in C longer than I've been programming in LV. You'd still have a hard time convincing me it's faster! But the next generation will probably be drilling down telepathically and wondering why Old Lady Cat is still pointing and clicking with a mouse.

We have a solaris/c programmer who we're dragging kicking and screaming into the linux&windows worlds. If she is looking for a file on a windoze box, she will still open up a command window and start typing in a few hundred characters of directory path. I've given up pointing out she could do the same thing with a few clicks of her mouse. I have to admit, she's a great typist, tho. I asked the guy at Labwerx about making a 64-bit version and there was a bit of whinging about how much time it would take, how much testing there would be, etc. Maybe I should volunteer to be a beta tester. But you never really know if there's a real company behind products like that or it's just some guy in his basement doing this in his spare time. Unfortunately I can't just not use telnet -- telnet has to be removed from the system. But that may not be a problem... (see part B) A) current problem If I understand you (and the putty doc) correctly, if I want to talk to 192.168.3.24:5678 on a remote machine, I can run something like the following: c:tempputtyplink.exe -ssh -L 127.0.0.1:1234:192.168.3.24:5678 -i c:tempputtyputty_key_noPassword.ppk then just set up my telnet session to talk to 127.0.0.1:1234, and putty takes cares of getting the messages to/from the linux box via ssh. Yes? Last but not least, I assume I'm issuing the above command with "System Execute.vi"? B) just semantics? I just wandered thru the LV telnet commands and want to know if I'm missing something... It looks like all they are doing is setting up and monitoring a TCP connection to port 23. So in regular usage the connection is actually to some remote box that has a telnet server listening to port 23. But now instead of a telnet server, I will be talking to putty. So, in essence, I'm not running telnet on my machine, I'm just using the telnet mechanism to open a plain ole tcp connection on my own machine to putty and format writes/reads between my code and the remote machine. Am I off base here, or if I do all of the above (and it works!) am I actually *not* using telnet?

I looked up Plink, and what documentation I found says several times "Plink is probably not what you want if you want to run an interactive session in a console window." I don't want to run an interactive session in a console window, but I do want to run a sorta interactive session from LabVIEW. It looks like what you've sent me is just how to run a one-time script. Is that correct? I need to maintain a connection thru several command/response cycles where the next command may be dependent on the response received (all automated -- there is no user intervention other than selecting the box to talk to). I do this with telnet now -- it's just finding some way to do the session connect/maintain part with ssh versus telnet that I'm stuck on. (Since you're being helpful, I'm ignoring the slam on us "point and clicky people" )

The Grand Poobahs of Information Assurance have decreed that telnet is too much of a security risk to be allowed anymore and must be removed from our systems. SSH is marginally acceptable, so I searched around on LabVIEW and SSH and came up with lots of people saying how wonderful it would be if it was available, and that's about it. NI has this article that recommends using PuTTY: "The PuTTY software package also has a command-line interface to the PuTTY back ends named Plink that can be easily used by LabVIEW." But everything I've read over on the Dark Side says this is anything but easy and no one has been able to get it to work automatically from LabVIEW. Everyone just gives up and uses telnet. There is a product out there called labSSH that I ordered, downloaded, attempted to install with no luck. After several back-and-forth emails with the (very nice) tech support person, I was told that labSSH won't work with the 64-bit versions of LV. Sigh. (They are updating their website...) Does anyone know of any other LV/SSH implementations out there? All I need to do is remotely log onto a Linux machine from a Windoze machine and send it a few command lines and get back responses. Nothing fancy.

Oh lordy. Don't get me started...

Hmm. Maybe it's my Big Brother-mandated browser settings or something.

I've noticed that the "Go to first unread post" button, doesn't actually take you to the first unread post -- it takes you to the bottom of the thread. Steps to replicate 1) See into the future and determine a thread that will generate many posts for awhile 2) Read the first few posts of that thread 3) (This is the hard part) Don't read LAVA for a week or so 4) Go to thread predetermined in #1 5) Push said button 6) Note that it takes you to the last post of the thread and not to the 15 posts before it that you didn't read.

AQ, when you complain about LV, it makes me chuckle.