Jim Kring
-
Posts
3,905 -
Joined
-
Last visited
-
Days Won
34
Content Type
Profiles
Forums
Downloads
Gallery
Posts posted by Jim Kring
-
-
-
Jim,
I don't know if I hadn't made myself clear, but I had already found this Object type and one other - 'Dialog Label'. (check the 'Scripted VI Comments' VI attached to my first message.) The problem I have with these two Object types is that they both exist/are created on the Front Panel, not the Block Diagram. I checked the 'Is On BD?' property for both of these Object Types, but it's read-only and cannot be used to force the newly created Label/Dialog Label onto the Block Diagram.
Just out of curiosity, what other conventions are there for labels? (Since "floating" was a new one to me!)
Thanks again,
Tony
P.S. I already have the 'Additional Application Control' pallete from Commander, it's how I wrote my example code. My compliments to the creator(s)!
P.P.S. Please forgive the lack of Close References in the original example - that's what I get for not double-checking my work before submitting!
In order to create a floating label on the block diagram (or a structure's diagram), you need to use the diagram reference as the owning object argument in the "New VI Object" function call. See the attached example and screenshot. Note: if you are trying to place/edit comments inside of structures, such as Case Structures, or While Loops, you will need to traverse the BD object hierarchy, in order to obtain the reference to that object's diagram. This is similar to traversing Tab Controls and Clusters (by control reference) on the FP.
Good luck.
Download File:post-17-1117426951.zip
-
This LabVIEW Object is called a "Label". If it is owned by a VI's FP or a Diagram object, then it is a "floating" Label (by convention). Here is some example code showing how to drop one on a VI using the "New VI Object" function. Hmmm, you don't have that in your palette? Download Commander and get it.
Download File:post-17-1117261434.zip
-
I kick off an independent loop using a generated user-event that wakes up a single-event event structure. It occurs to me that I probably could have used a notifier to do the same thing. Are these essential the same mechanisms? The only advantage I can think of to the event structure is it could more easily expand to accomodate other events if my situation required it.
NO! Events are queued, Notifications are NOT. If your processing loop cannot execute fast enough, you might miss Notifications that happen while you are processing them.
Unlike the Queue Operations functions, the Notifier Operations functions do not buffer sent messages. If no nodes are waiting on a message when it is sent, the data is lost if another message is sent. Notifiers behave like single-element, bounded, lossy queues. -
-
I guess I'll chime in again, since I started this thread. I am very happy to see that NI has really taken this issue to heart, understands its impact, and is going to work to help the community continue to use LabVIEW as a software development environment. I am sure that a lot of time, energy, and resources have been spent by NI on this issue I commend them for making this investment in the foundation of their relationship with their customers. I haven't seen the new license, as it has not yet been posted to the NATIONAL INSTRUMENTS SOFTWARE LICENSE AGREEMENT page on ni.com -- I am cautiously optimistic. :thumbup:
-
I assume that you mean a version control system that allows concurrent access to files. "Concurrent Versions System" (commonly called "CVS") is the name of one such system, but there are others. There are a lot of people who use Concurrent Versions System (CVS) and Subversion (SVN) with LabVIEW. Subversion is a little more modern, has better support for binary files and fixed-width keyword replacement, and various other features. Here is a good comparison chart.
-
Hello,
Have you seen LabSQL?
The code you have written is probably very similar, or complementary to it. In the near future, we will be packaging up LabSQL and releasing it on OpenG Commander.
Regards,
-Jim
-
LabVIEW applications must have a user interface and be targeted at a display, even if it is only a virtual display. There is more info on how to do this here.
-
That's wonderful, Heiko. He looks just like you
-
Take a look at the lv_new_vi.vi callback VI which is documented on the LabVIEW Documentation: Development Environment Event Callback VIs page at OpenG.org
-
-
I'm new so this may be my ignorance showing. How can I call an external program ( a PuTTY SSH session) and see and process the replies?
I have tried System Exec.vi but it only allows me to set the input lines beforehand and then throws them all at the program. After the session exits I can see the whole result. This is not so useful. I need to wait/parse the remote prompt before issuing the next line of input.
Thanks in advance. Pete
If you are on linux, you can use a pipe to communicate with plink (PuTTY Link - a derivative of putty). On windows, some folks are working on supporting pipes from LabVIEW. Nothing working, of production quality, yet.
-
-
That is strange. I have activated your account and you should be recieving an email that will allow you to change your password and log in.
Regards,
-Jim
-
I'm using the OpenG Message Queue library (thanks Jim) in my project and may have come across a bug.
It appears if you try and call the "Create Response Notifier" VI (called by "Insert Msg Queue Element") too frequently, it creates duplicate names for successive identifiers...
It seems to be caused by the fact that the "Get Time/Date" function used to generate the notifier name returns integer seconds, which will attempt to create identical notifier names if called more than once in the same second.
I created a temporary fix by appending a random number to the end of the notifier name. This obviously does not guarantee a unique name, but it does seem to tilt the odds in my favor...
Any thoughts?
Kirk
Kirk,
Could you please post this in the OpenG Support Forums? This is our support channel, and ensures that the issue gets visibility by our developers and users.
Regards,
-Jim
-
Mike, I'm glad that you asked this question. Recently I have been getting DAQmx errors in WindowsXP when users perform window-related operations (switching between windows, launching apps, dragging windows around). I found that if I configure windows for "Performance" (no special window effects, classic window appearance, etc.) that the problem goes away.
Could you do us all a favor? Please compile the list of suggestions and tips that you receive and post it to the forums. This would make a wonderful LabVIEW FAQ entry.
-
I like to listen to several of the channels on soma fm. "SomaFM is listener-supported, commercial-free, underground/alternative radio broadcasting from San Francisco."
-
Wow. That is great feedback!
We, at OpenG, try very had to make useful, well-documented tools. But, unless users demonstrate that they are using a specific tool and have a need for more features and better documentation, it is very easy for the developers to simply move on to the next exciting project. We really do listen and want to make your experience with OpenG tools better.
Please get involved in the process by sending us your feedback and feature requests. OpenG has recently made its discussion and support forums a whole lot more user friendly. OpenGOOP related discussions currently belong in the Packages Forums.
Regards,
-Jim
-
Jim, I was under the impression that LabVIEW PDA will run on any device with PalmOS 3.5 or higher, as NI's PDA Page seems to indicate.
Yes you are right. I guess what I meant to say was that the LabVIEW Run-Time Engine has not been ported to Linux for the ARM processor. LabVIEW for Linux only runs on x86 and there is no compiler or cross-compiler for ARM. Also, LabVIEW PDA isn't really "LabVIEW" running on the PDA, but rather the LabVIEW code is translated into C and then compiled by a third-party compiler (automagically). The only platforms where LabVIEW is supporting this scheme is PocketPC and PalmOS.
-
No, because because the delimiter is an EOL character (each line in the string becomes and array element). However, that code has a couple small issues:
1) the LabVIEW "End of Line Constant" changes depending on platform (Windows EOL = CRLF, Mac EOL = CR, Linux EOL = LF), which may not give consistent results for the same input string.
2) the code does not handle strings with mixed EOL characters
While the OpenG version of "Multiline String to Array" does not exactly keep it simple (if you feel the need to look at the code), it does handle any combination of mixed EOL characters. It does this by first replacing all instances of CRLF with LF and then replacing all instances of CR with LF and then using a LF delimiter to convert the string to an array.
You're welcome
-
I suggest that you build a Queued Message Handler (similar to a state machine) that has a "macro recorder" which enables you to save and replay sequences of messages. This is a topic that comes up time and again. A search of LAVA or Info-LabVIEW should produce some interesting threads.
-
The "oglib_string" library which you can obtain using OpenG Commander has a VI called "Multiline string to Array".
-
Hey, Eric. I hope all is well
I've seen stuff at NI Week (a couple years ago) showing LabVIEW running on ARM. There is no productized solution at the moment for Linux running on ARM (only Linux on x86). LabVIEW PDA will only run on PocketPC. So, the answer is, "call NI and ask." Send me a private message and I'll send you some names of people who you might want to talk to.
Regards,
-Jim
Well, I'm slapping myself on the head. This one should have been obvious.
Scripted Comments?
in VI Scripting
Posted
Or maybe Martin used the INI key:
superPrivateScriptingFeatureSichtbar=True
:laugh: