Dan Press

I thought I noticed something very strange. I now have two cases of the creepy slowdown. In once case, there was an OpenG Read INI Cluster happening while a digital I/O task with change detection was running. I actually theorized that it was something to do with the change detect that was causing the slow down. I switched to a polling scheme and it actually helped! Today, one of our developers saw the slow down during Read INI Cluster without any DAQ tasks running. Increasing the priority of the calling VI seems to help for now. This is a nasty one!

I got the following email from the AE. It doesn't look like there's much hope for this one. Not the end of the world, but it would have been nice to get out what the user put in to MAX. Dan - Thank you for contacting National Instruments. Unfortunately, there is not an easy solution to find out the accessory of a SCXI module. We currently do not offer a VI or property node that will output the accessory type. The closed function available is the Property Node -- Chassis:Module Device Names Property which gives the names of the modules in the chassis (not the accessories). One possible solution, like you mentioned, is parsing through the configuration file to find the accessory connected to the module. If you export your configuration wizard as a tab Delimited text file, can you parse through to the file to determine the accessory connected to the file. To save NI-DAQmx config file, select File

I've called NI Support (#7136887) on this one, but I am not sure how much hope I should have. The application is a data acquisition system with lots of options for calculations and the ability to make use of various pieces of measurement hardware. The customer would like to use SCXI-1102 modules in several different ways. Some 1102 modules will be cabled up to TC-2095 thermocouple input terminal blocks. Other 1102 modules will have SCXI-1300 or SCXI-1303 terminal blocks on them and will be used for either general purpose transducer inputs or thermistor / RTD inputs. For the sake of simplifying the setup of the system and making use of configuration tools already provided to us by Uncle NI, I would like to read the Accessory selection that the user made in MAX. I can enumerate the SCXI modules with no problem. Once I know which modules are there and where they are, I can set up my scan lists and acquire away. However, I want to be able to tell which modules have thermocouples (the ones with the TC-2095) and which ones have other stuff (the ones with SCXI-1300 or SCXI-1303 terminal blocks). I know the accessory information is stored in MAX's configuration file once the user specifies it. MAX does remember the selections just fine. However, I do not see a DAQmx property that lets me see the selection in LabVIEW. My current hope is for one of two things. 1. A parser written in LabVIEW that can let me check out the accessory selections. 2. An automation interface (ActiveX or other API) to MAX. I know the Community has asked for #2 for years, and I thought I heard something about it recently. Anyway, I'll keep you posted if I hear something from support. If any of you have something to add or suggest, please post it here. Thanks!

I'll try to answer those... 1 Are dll calls to the IMAQ dll's re-entrant? (probably not?) A: They are thread-safe. You can tell because the call library node is yellow (as opposed to orange). Thread-safe = Reentrant in the call library node configuration. However, I noticed that many of the image processing VIs (such as IMAQ Threshold) are not reentrant themselves. That doesn't seem right. Actually I have a parallel-ized IMAQ application, and I never checked that part before. I'll be opening up a service request on that one. 2 Can these dll calls be made re-entrant? Would it make a difference? A: They already are. It is possible! 3 Any way to set two different instances of the same re-entrant VI on the diagram on DIFFERENT threads? A: I believe so, just make sure those two different instances are not inside a loop. Doing that would cause a thread swap for at least one of them every time it is called. 4 Any otther ways to improve performance? A: You can eek out some extra cycles by using UDP instead of TCP. Just make sure you build in some way to detect errors. For a reasonably short network hop, there is usually no big issue with packet loss.

So far you seem to be on the right track. I'm just responding to your suggestions for how to change the behavior of queues. It looks to me like we already have all the tools to define how our queues behave. The options for handling how the queue acts when full are all available to you at the Enqueue function. There is nothing wrong with using the timeouts and reacting to them. You've already written one example of how to customize the Enqueue behavior. Just select that inner part of your diagram and Create SubVI! You can even add the other options to give that subVI a more general applicability. Perhaps wire up an enumerated type with your choices of Ignore Oldest, Ignore Newest, Wait, etc. Similarly, you could create your own Dequeue subVI that reports the number of elements in the queue and/or the "fullness %" on which you could then perform some math to determine a period for a timed loop. I could see a use case where you would want to employ the Ignore Newest or Oldest in some parts of your code, but not in others. For example, you could have multiple message types that travel on the same queue. Some message types could be of a higher priority than others and would therefore be given the authority to bump off the oldest elements on the queue. Other lower priority messages would have to wait until there is space. As an aside, you're using TCP so I would be very surprised of you experience data loss due to the network. TCP is a "guaranteed delivery" protocol. If you switch to UDP, you can achieve higher throughput while perhaps risking data loss due to the lack of error checking and such. It sounds like you've got a cool project. We worked on something that had similar requirements and queues turned out to be just the thing.

I recently had one of those "why didn't I think of that" moments. It didn't really surprise me however, since the code I was perusing at the time was written by a preeminent member of the LabVIEW R&D team. Yesterday, I gave a quick talk at a local LabVIEW User Group meeting on the new lvOOP stuff in 8.20. Since it is such a compelling example, I decided to flash up a few block diagrams from Christina Rogers' Getting Started window. As I was explaining (rather quickly) how dynamic dispatching is used to fire the proper handler VI to react to a click on a link, I noticed something very cool. When the Mouse Down event fires on one of the links, there is an event case to catch it (of course). That case handles the Mouse Down for all the clickable text links. The object data for the clicked link is obtained by using the clicked control's Label.Text property to Get a Variant Attribute. The value of the Attribute is the link's object data (custom wire)! After thinking for a bit, it occurs to me that we have a wonderful implementation of a linked list or lookup table. There's even a comment in Christina's code that says "Store the name/value pairs in a variant's attributes for faster look up than an array." Perhaps many of you LAVA folks out there already use that pattern in your projects. I do not believe that this is anything new, although its application to lvOOP certianly is. A big Thank You goes out to Christina Rogers and the rest of the LabVIEW R&D team. LabVIEW 8.20 is a most welcome addition to the family tree!

In LabVIEW 8 (OK I only checked 8.20) the cursor properties have been improved such that you can directly relate the mouse cursor position to a plot location. You should now be able to achieve the same effect you have there without using the invisible slider. That said, I like your custom control. This could be a good use case for an X Control too! Another thought I had was to keep the invisible slider and have that positioned on top of an array of verticle fill bars. You could manipulate the values of the verticle sliders based on the position of the horizontal one. By adding two sliders on each verticle fill bar, you can set two fill colors. The limitation is that your resolution would be fixed at range in values divided by the number of verticle sliders. The advantage is less use of property nodes. Good job!

I can confirm that LabVIEW 8.20 behaves the same way. There is no Mouse Leave event fired when the cursor enters the toolbar or menu bar area, however there is a Mouse Leave when you go past the menu bar and into the title bar. The menu and toolbar areas are "special" and have their own behaviors. I guess we developer-users do not have the ability to mess with stuff up there.

There's a decent NI example that can be found here.

To highlight a tree item, just write the item's Tag value to the Tree. You can use the dreaded Value property, wire it directly to the tree (if it's an indicator), or use a local variable. Note that it is a Filter event and the right-click is discarded. That will prevent the run-time pop-up menu from ruining your day. Rock on, Dan Press PrimeTest Automation

It's up there right now. I'm not sure how the license / activation stuff works since we have one of those wonderful Alliance Member software leases, but the Vision Development Module 8.20 is available for download. Vision 8.20 - Dan

We recently experienced a similar issue, or I should say a set of issues that acted something like that. The first and easiest thing to check is what you have installed on the RT side. If you have NI-IMAQ and NI-IMAQ-1394 installed at the same time, there could be a hang at bootup. That is a known issue, although I have not seen any fix for it. The workaround is to only have one or the other installed... or neither if you do not need image acquisition. If you do not have IMAQ or IMAQ-1394, the problem could be VISA. There has been a rash of new VISA versions lately, and you could make sure you're on the latest and greatest. Our current RT fire is burning on a generic desktop target. We have had to send the complete system to NI three times so that the R&D folks could fix driver and OS-level problems. We currently have an experimental build of the RTOS with slightly hacked Ethernet drivers. However, on a PXI controller, the step should not be necessary. What version of everything are you using now? Empathizing, Dan Press PrimeTest Automation

I've got a nasty one. I have attached a VI that should generate a 2D array of booleans with a pattern defined inside a case structure and double For loops. I initialize an array of FALSE booleans 8 elements long and then use the Replace Array Subset function to flip some elements TRUE. The first time I run the VI I see a strange pattern effecting one of my cases. In that case, when I try to flip a single element TRUE, the elements before it turn TRUE as well. The second time I run the VI, all elements turn true regarless of what is wired to the Index input of the Replace function! This happens under 8.0 and 8.0.1 but NOT under 7.1. The AEs have it under request numner 7108423. Download File:post-123-1142877375.vi Dan Press PrimeTest Automation

Jack, You got confused by the waveform attribute function. That is designed to let you add custom data to your waveform wire. By specifying t0, you just created a new attribute named "t0". The waveform's t0 is not what you're editing. To do that, you use the Build Waveform primitive. It works just like the Bundle by Name. This would be a good one for the old OC LVUG. I miss those! Take care, Dan Press Certified LabVIEW Architect PrimeTest Corporation Download File:post-123-1112652875.vi

Well, the 12.txt is at the top since it has no text before the number. I could switch the enum to have Text before Number and everything would come out the way you expect, although I thought that people usually like numbers sorted before text in general. If we define the sort order as follows... 1-9, A-Z, a-z ... then 12.txt should come before AB 10.txt. However, I agree that the 10.2.txt comming before 10.txt is odd. Its just that the "2" is before the "t" in the sort order. I could add some code to handle the decimal points differently perhaps, but even then there could be a problem. - Dan

Check this out. I was experimenting with the error behavior of the Scan from String function. This VI will sort an array of strings by treating any characters that are numeric as actual numbers. That way, you avoid the old 1, 10, 2 ordering. It's something I just whipped up, so there may be a bug or two in there. Attachment is a LabVIEW 7.1 VI. Download File:post-123-1102017466.vi Daniel L. Press PrimeTest Corp. www.primetest.com