Jump to content

Cat

Members
  • Posts

    815
  • Joined

  • Last visited

  • Days Won

    15

Posts posted by Cat

  1. I just read through this thread in its entirety.  My opinions on many LAVA members has been irrevocably changed.  I almost wish I had never read the entire thread.

     

    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)  :P 

     

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

  2. 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??

  3. LV 2011 SP1 crashes regularly.  Is LV 2012 stable?  Conditional loop indexing looks great.

     

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

  4. Don't get me wrong, I can't wait to try it out and see what other features 2013 is going to have.

     

    So generally LabVIEW releases are hit and miss.  They will have a stability build, then a feature build, where the feature build will be great but usually rough around the edges.  Since having a service pack mid-way through the year this seems to make sure all released versions are solid.  For this reason I have no fear about using a SP1 version of LabVIEW.  But I am still apprehensive about switching to a new version before this SP1.  

    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. :P

  5. Nothing wrong with a guy in his basement offering software ;) Difficult for defence companies however, that have preferred suppliers and require dedicated support channels.

    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.

     

    Yes. But it is even easier than that. Just set everything up as a profile in PuTTY (being a point a clicky person I find a GUI is much better) then, when you need it, just run putty.exe -load myprofile (with system exec).

    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.

     

    Well. Telnet is a protocol but it is also used to refer to the client. Windows 7 doesn't come with a telnet client installed as default any more (which is called "telnet" and has to be installed with add/remove programs) but the term is used interchangeably.

    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.

     

     

    I don't find it very useful to get into semantic arguments with IT people who tend to be very anal, no sense of humour and completely unreasonable when it comes the their network.

    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.

  6. Completely off topic, but I also sometimes go oldskool, and it can be much faster than using the UI, if you know some tricks.

    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. :P

  7. If you want to really annoy them. When they rattle off a command line (because every Linux user has an Eidetic memory and therefore anyone that doesn't is an amoeba to be treated with scorn), just say to them "you lost me when you said 'type in' " ;)

    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. :rolleyes:

     

    As a slight tangent. I also looked at that software package you mentioned earlier a while back. It looked great but relies on a DLL and is just a thin wrapper around that (not cross platform, so no good to me). You could get them to compile the DLL for 64 bit so that you could use it (or you could use LV 32 bit).

    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.

     

     

    By far the easiest solution for you would be to tunnel your telnet through SSH (you can tunnel anything through SSH :) ).

    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?

  8. What's the issue with putty? I can connect to my VPS and execute commands with LabVIEW without any problems. (Maybe they are hesitant that you don't see anything in the DOS prompt as it is redirected to the Shell Execute)

    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" :P )

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

     

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

     

     

     

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.