David Boyd

I haven't tried this, but the Tab Control reference has a property called Pages[], and methods called Add Page, Dup Page, and Remove Page. A Page reference has properties for getting all Controls[], Decorations[], AllObjs[], as well read/write properties for its visibility, enabled state, caption, page description, etc. My first guess is that the 'New VI Object' primitive could create a control and you could specify a Page as its owner's reference. It's too late for me to try this right now. If you have trouble getting this to work, post back and I'll see what I can do. Best regards, Dave

What sorts of front panel objects are you using? In my limited work with remote front panels, I got the impression that objects with heavy amounts of internal data (such as charts, graphs, array controls/indicators) have all their internal data copied over to the remote client, not just what's visible (or decimated for display). Not sure if this is true, but thought it might give you something to look for... Best regards, Dave

Let me chime in here just to suggest that the application may neither require nor benefit from multiple instanciations of a VI. The only thing I know about the application so far is that you have multiple identical devices with which you need to communicate (and thus perhaps maintain state information on them). But you also said that they share a common RS-485 bus. So, is it correct to say that the system hardware constrains you to only communicate with one device at a time? If this is the case, could you do all your operations in a for loop, indexing on some array of state clusters? Unless the devices may be in multiple states requiring more or less access to the shared resource (the RS-485 communications channel), it may be much simpler to design a system that just traverses from device 0 to device N-1, calling a common code block that takes state info as input and produces state info as output. The array can grow or shrink at runtime as needed to accommodate device additions or deletions if this is a requirement. Fundamentally all presentation to the user interface begins with arrays of controls/indicators, which may appear as tables or lists. If you choose to go the dynamically instanciated VI route, you'll still need some mechanism (a semaphore, or a non-reentrant subVI) to marshal the access to the shared resource. Your call - I've designed such things both ways in the past. Just figured it wouldn't hurt to ask about the particulars a little more. Best regards, Dave

I have ZERO experience with PDAs. I just may have to change that based on a 'blue-sky' conversation I had at work the other day. What's the current PDA of choice capable of supporting an NI PCMCIA DAQ card, preferably with WiFi built in? Thanks for replies, Dave

See the attached VI. If you are unable to create these nodes on your BD, you need to reread other posts in this forum on how to access scripting features. Dave Download File:post-195-1106468566.vi

Perhaps there is more scripting that you have not yet encountered. Attached is your VI with modifications. I hope this helps. With best regards, Dave Download File:post-195-1106467549.vi

If you know how to get a reference to a numeric control (Generic->GObject->Control->Numeric), one of its properties is 'Representation'. The parameter is a U32which appears to be the index of the floating palette for selecting representation. It is, of course, only writable on a control owned by an idle VI, since it alters the VI's code. Hope this is helpful. Regards, Dave

Jean-Pierre, I'm familiar with that application property, but in fact I didn't use it in the tunnel wiring wizard. It seems more appropriate when you want to launch an action on a particular VI. What I decided I wanted was a floating tool, which needs to get references to the currently selected object(s) on any open FP or BD window (even though in my case, I'm only looking for BD objects). For that, I used App.ActiveVI, then got the SelList[] property from the active VI's BD. So the developers gave us two pretty handy application properties which are the cornerstone of both menu-launched and floating tools. I hope this clarifies things for some of the other folks who've been interested in how to create such tools. Best regards, Dave

While I respect your enthusiasm and involvement, I must politely disagree. Even though this excellent set of forums (for which I heartily thank Michael for creating and tirelessly maintaining) is part of a group named LabVIEW Advanced Virtual Architects, it's still a public website. As we've seen countless times, participants vary widely in their LabVIEW experience. The tool I wrote was one simple example of using scripting features that are undocumented and unsupported by NI, to automate a specific task that a fairly advanced LV developer would encounter. (I'm certain that many inexperienced LV users here have never used a state machine construct in their code, but that's another point.) I published it here for several reasons: It's a useful tool which I can give to the community. It's a practical demonstration to gently show NI's developers/decision makers how a released scripting feature could make LV users more productive. And I'll admit, it's a bit of a 'hot dog' move (translation: it says, "Look at what I can do!"). Judging by the number of download hits, and the other posts here, it's been useful even though I left it locked. And I did so at the time because, to release it openly, would have been to put a lot of undocumented/unsupported features on a public website. Now I have no qualms whatsoever about lobbying NI for releasing and documenting these features, but I respect my relationship with NI and will not compromise their internal 'roadmap' for making scripting publicly available. I understand that you may not agree with my reasoning. However, nothing prevents you from using the other details of LV scripting which have been posted here to work out your own uses for it. With best regards, Dave

Well, I was going to tack on a VI that I first wrote around 1998 (and have re-written over the years for differing instruments which implement CRC's in their protocols- Siemens ELAN, Tescom, etc.) But there are already a number of other candidates submitted, so you should be well on your way. Here's a link full of interesting reading - it suggests that the more common implementations of the CRC-CCITT algorithm out there (including one I wrote) are in fact erroneous. Sort of a moot point, since the devices I'm talking to use a compatible algorithm, but worth looking at nonetheless: Discussion of CRC-CCITT Best regards, Dave Edit: Since I downloaded the other VIs, and found they differ from each other and from the most recent copy I have, I decided to post mine too. All I know about my own version is: - it works with the Tescom ER3000's implementation of CRC-CCITT (whoo-hoo!) - it faithfully matches the 'Bad_CRC' example given in the above link (which seems to be in common use); - it's semi-documented. Download File:post-195-1103327346.vi

Isaak- I took a quick look at your first attached LLB - I hadn't seen the GetLastError support VI from MGI before, although I am aware of David Moore/MGI, mostly through Info-LabVIEW. You should note that his VI calls GetLastError() through a Call Library Node that is not marked reentrant- which guarantees that you'll be getting GetLastError() results on the UI thread. This may be what you want, as long as all your other CLNs are set to run in the UI - which is the default. Where I ran into problems was when I tried to set locale items, which are (if you believe MSDN documentation) globally inherited, but controlled on a per-thread basis. In the case of the SQL toolkit, I think my problem was that I could never guarantee that I was modifying the settings for the same thread that ended up handling the innards of the SQL toolkit, which called DLLs that NI had licensed from Intersolv/Merant. I recall that LabVIEW in its recent versions, by default, creates something like four threads per execution system/priority combo. Though I also seem to recall that there are limitations on the UI execution system, that would tend to work in your favor if you're trying to ensure that GetLastError() reflects the WinAPI call you just made in the UI. Enough rambling - back to work. Dave

You're welcome, although I don't know that I provided any answers. You definitely need the dummy dataflow to at least make sure the two API calls happen in the specified order, though! I hadn't realized this was missing in your code, I'm sorry, I admit I hadn't downloaded your attachment. If you're not already aware, you should read up on LV's platform-independent features for comma vs. decimal-point localization. This can be found in the format specifiers help for Scan From String and Format Into String, you can programmatically specify the localization or let LV use the system defaults. You can also apply physical units to LV floating-point numeric controls and indicators, and with the recent enhancements to LV, you can control these programmatically at runtime as well. Best wishes, Dave

Been there, done that, never got the T-shirt ;-) At one point, I did a lot of LV coding around the Windows API using the Call Library Node. In fact, much of it centered around the Windows locale functions. At the time, I was using the old SQL toolkit which manipulated database date/time values using an unavoidable interim conversion to string - and I was trying to avoid parsing failures if the user changed their date/time 'picture' to some alternative format. Is this close to what you're pursuing? Anyway, I coded my CLNs with followup calls to the 'GetLastError' function, enforcing execution order with little single-frame-sequences, etc. I also experimented with whether or not the CLNs were marked threadsafe - you know, the orange vs. yellow thing - all in an effort to make the two calls happen more or less atomically, and (this is crucial) execute in the same thread . Bottom line, after LV 6i, I think, or maybe it was 6.1, it seemed that the threading mechanism of LV changed, and I could never guarantee the results would be as desired, short of changing the INI file entries that control LV thread usage and seriously hobbling the application's efficiency. The thread-management change was plainly observable when I wrote some VIs to determine thread- and-process-specific times (I was looking for a foolproof way for a LV subsystem to be able to determine what its CPU utilization was between elapsed calls to a VI which calculated thread times). I started getting inconsistent results and realized LV was calling the same code, on successive iterations, on different threads. Hope sombody else has a better answer to this - I'd love to hear how they worked it out. Best regards, Dave

Didier, Are you sure you're not leaning on the <ctrl> key at the same time? If I hold down shift and type a '#', I get a '#' character (if typing in a free-text box on the BD). The shortcut <ctrl><shift># generates the prompt you're seeing. Is your <ctrl> key physically or logically stuck? Dave

Norm, you crack me up. :laugh: Now everyone knows the REAL reason why I locked the BD on the tunnel wiring tool... You call THAT messy...? ('Course, judging by some clues, you already know what's lurking back there...) Dave

They look like two separate multiframe structures to me. I had created them awhile back (under 7.0) and they appeared to work correctly, though context-clicking on them back then was a bit dicey (the editor would sometimes crash). The 'Conditional Disable', at least under 7.1, allows selections of Windows, FPGA, PalmOS, RT Engine, Mac, Unix, and PocketPC. The 'Diagram Disable' allows multiple 'Disabled' subdiagrams, and no more than one 'Enabled' subdiagram. The 'acid test' for me was sending a VI to Scott Hannahs (the handy LV-on-a-Mac test subject) that did some WinAPI DLL calls in the Windows case, and returned a timestamp through the case border. For the Mac and Default cases, I just wired a constant timestamp (they were grayed out on my Windows machine). Scott reported that his LV editor did try to search for the DLL file when he loaded the VI, but when it gave up, the VI wasn't broken. They certainly APPEAR ready for prime time... Just gotta 'Wait for Eight' . Best regards, Dave

My, you've been busy I can't find this in the 'bag of tricks'. You can get a reference to a 'Case Selector', and it has properties and methods to get references to its subdiagrams, add/duplicate/delete cases, get/set the default case, and GETTING the array of selector strings, but I see nothing that allows one to set the selector values. So, another one that probably has to 'wait for eight' . Best regards, Dave

Hmmm, curiouser and curiouser... (LV7.1) Calling the 'New VI ' primitive with the 'vi type' input set to 'Polymorphic VI' (so far, this seems like what we want to do, right?) generates an error and no valid VI ref. Not ready for prime time. OK, let's try this: Create a new polyVI (using the conventional approach). Save it with a .vit extension. NOW call the 'New VI' primitive, specifying the path to the .vit file as the 'template' input, but specify the 'vi type' as a standard VI. When I run this, I get a history dialog asking me to add a comment (I have this option turned on in my prefs, YMMV). The save operation is on a VI named: <long-random-digits>.tmp When done, I have a valid VI reference. If I do FP.Open on this ref, I have an 'Untitled' polyVI that says it's never been saved (no path to disk). That's all for now... more testing needs to be done. Like, where is there a scripting method to add a VI to a polyVI's list of instances...? I think this is a dead end for the moment. Best regards, Dave

Yes, it appeared a version or two ago as an undocumented INI entry. It's now (LV 7.1) documented as the entry that corresponds to the options dialog setting 'Place front panel terminals as icons' (English version). Edit: I just noticed you're using LV6.1. For you, it's undocumented, but it works. [Opinion] Unfortunately, it defaults to TRUE now, and those terminals ARE pretty, but take up too much precious diagram space. [/Opinion] Best regards, Dave

North of Atlanta, Georgia... In the 6+ years I've been here (Respironics), I've used LV for production testing of sleep diagnostic recorders, infant apnea monitors, CPAP (Continuous Positive Airway Pressure - for people whose airways occlude during sleep), and medical oxygen concentrators, plus all sorts of little 'quickie' lab tests. Prior to that, I used LV (4.0.1 - 4.1 days) to test secure telephone equipment and other government/military voice/data crypto gear at L-3. If I had been smart, I would've started using it back in '92-'93 when it was first demo'ed to me. I was one of those obstinate types who thought it could never do what I needed it to do.... I was a C programmer, y'know... ah well... Dave

I posted this to Info-LabVIEW a week or so ago, I'll post it here as well. This has been confirmed by NI, and appears to have been introduced in LV6i or 6.1 (so it's hardly 7.1-specific): To produce the bug, wire 2 2-D arrays of double to the X and Y inputs of a 'Max & Min' primitive (you know, the one with the measuring cups, found on the Comparisons palette). Leave the node configured to its default mode of 'Compare Elements'. Regardless of what you enter into the arrays, the 'Max(x,y)' output terminal will return the contents of the wire attached to 'X'. The 'Min(x,y)' output is correct. This problem appears to exist for all numeric datatypes of 2-D and higher order. Others have pointed out that BD constant arrays are not subject to the buggy behavior. Also, if the 'X' input is coerced at the node (say, because it's been changed to integer or single-precision), the behavior is OK. It appears to be some sort of buffer reuse problem. Thanks to Jesse 'Chip' Jones for the workaround suggestion of using two nodes, and inverting the inputs and outputs of the second node to use its 'Min' output for the 'Max'. Dave

Norm, You should have this link stashed away: http://labview.brianrenken.com/INI/ Brian Renken did the most exhaustive mapping of INI entries. Though with a few new releases of LV, plus expansion of RT targets, etc., already it's somewhat dated. Seems like we should all pitch in and get it back up to date. I haven't seen any recent activity around it. Michael, do you think Brian would be willing to have it moved to LAVA's pages for preservation/maintenance? For that matter, would you want it? Dave

Leopold, If you could provide more information about the datatype expected by the call into the SQLAnywhere code, that would be helpful. Until then, I have attached a VI (saved in LV7.0) which demonstrates conversion from the LV timestamp into an OLE Variant (used by ActiveX-based database tools, such as NI's Database Connectivity Toolkit). The VI also converts the OLE Variant back to the LV datatype. It may or may not be relevant as an example, depending upon your call interface. Hope this is useful to you. If not, describe your code in greater detail and perhaps someone on the user group can determine what needs to happen. Best regards, Dave Download File:post-195-1093285147.vi

Lucas, If I understand what you want, I don't think it's quite possible. The 'grid' of lines can be repainted any color you like (through the control editor), but if you've set background colors of cells (using the example I gave you), there will always be a perceptible line between adjacent cells painted different colors. If you change the FOREground colors of cells (meaning the text), and leave all the BACKgrounds the same, and paint the grid the same color as the background, then the grid lines will 'appear to disappear'. Did that make sense to anyone but me?? Dave