Jump to content

KFadgen

Members
  • Posts

    14
  • Joined

  • Last visited

Posts posted by KFadgen

  1. Anyone out there using IBM Rational Team Concert for SCC?  I have to explore this as an option since it conforms to my company's software policy.  My team's current tool is subversion which has been working fine for the last several years.  I'd prefer to not have to manage our own servers at this point which means we may have to migrate to something our IT group is more comfortable with.

     

    https://jazz.net/products/rational-team-concert/

  2. Hello All,

     

    I've found a bug related to the "Generate User-Defined Trace Event" (GTE) which will crash LabVIEW routinely.  The bug has been submitted to NI and they've verified it.  For those of you watching from home, the CAR number is 412912.  I'm using LabVIEW 2012 SP1.  The crash did not exist for me in the 2011 version.

     

    The crash occurs when you have a string control wired to GTE and that string control is connected to the connector pane of your VI.  If the string control contains text and the Desktop Execution Trace Toolkit (DETT) is listening than we get a crash.  If string is empty or DETT is not listening, then we're all set.  When used only with a numeric control, the GTE does not seem to crash.  The workaround  from NI is to use a property node to read the value of the string control and pass that onto GTE.

     

    I've attached a sample project which demonstrates the crash and I've included the png of just the workaround below.

     

    -Keith

     

    post-689-0-41865700-1371153944_thumb.png

     

    GTE Crash.zip

    • Like 1
  3. The "Conditional disable" has pre-defined conditions for different OSs (bitness is one of them).

    I tried the conditional disable structure and I'm not getting the behavior I was expecting. I'm running LabVIEW 2010 SP1 (32bit) on my laptop which has Window7 Pro 64bit installed on it. I setup the conditional disable as suggested in a test VI. If I execute the VI, it is always selecting the 32 bit code in the structure. Is there something obvious I'm doing wrong or missing?

    post-689-0-31920200-1300666060_thumb.png

  4. I'm trying to determine if my application is running on a 32 or 64bit version of Windows. The application is going to be calling some external code (.exe) which has two separate versions depending on which OS they're running on. There is a very nice .NET method available which would work perfectly:

    http://msdn.microsof...8VS.100%29.aspx

    but it's only supported in .NET 4.0 which as of LabVIEW 2010 SP1 we don't have access to. I could try to write an external dll to do the check for me, but I wanted to see if anyone out there had an idea of how to do this from within LabVIEW.

    Thanks,

    Keith

  5. We've been playing with dotNet Processes of late to interact with command line applications, unfortunately it's windows specific. I've attached a very crude proof of principal we used to see if it would work for us. We're in the process of trying to make a generic OOP class around this which we can apply to a couple different command line apps. To date, we've only used the output stream reader. There is one for input as well as error that should work without a problem. We have played around with the pipes library as well but figured since we're platform specific already why not try the dotNet routines first.

    -Keith

    post-689-0-15450300-1292884190_thumb.png

  6. Hello All,

    I'm looking for some advice. I'd like to duplicate the attached file search dialog in LabVIEW. My guess is to start to use the system tree control for the directory browsing portion (right hand tree view). I've played around with adding symbols for each level of directory but the built in folder representations are not that great. Does anyone have a source (freeware or at least minimal cost) for nice looking color icons for the folder representation? In the tree view in labview I see a dashed grey line connecting the parents/children. Can that be disabled so it looks like my attached image? I am planning on wrapping most of the controls into an XControl to make things a bit easier to handle.

    Thanks for the help,

    Keith

  7. I'm not receiving any updates for info-labview anymore. Is anyone else out there getting info-labview mailings since the first of the year? I'm not sure if my IT department decided to block that address or if there is something wrong with the server. I went to the info-labview home page but there was no mention there of any downtime.

    Thanks,

    Keith

  8. James,

    I tried your file and it works. Your Main.vi in it's current format only allows for one copy of the template to be loaded at a time. For my app I'm planning on having separate instances of the template running at the same time. I modifed your version to open several copies, keeping track of the references in the parent. This worked as well. For the app I have I will be setting up Ques for comms between the caller and each .vit instance. I'll try coding in an exit routine which will tell the parent to close the reference when the child window wants to exit. This should minimize the memory footprint over time.

    Thanks for this, it definatley points me in the right direction for this app.

    -Keith

    Keith,

    See how this VI works for you.

    I'm a fan of disposing of references manually. I like to see it being done vs. thinking it's being handled for me.

    The draw back is that the VI probably stays loaded into memory.

    -James

  9. Hello All,

    I have an application which uses an XControl as part of a dynamically loaded vi template (.vit). In the development environment everything works fine. When I build it into an application I get a program crash whenever I close one of the dynamically loaded vis with the xcontrol on it. I've built up a simple example and included it in the .zip archive. If I remove the XControl everything runs fine.

    I'm running WinXP and LabVIEW 8.20. This "feature" has been confirmed also with 8.0.1 on WinXP. I've emailed support at NI and got the following response:

    Thank you for contacting National Instruments, and for alerting us of this

    issue. I was able to reproduce the crash, and have reported this to our

    R&D department for further investigation. This will probably be addressed

    in a future release of LabVIEW. However, in the mean while, I beleive

    there is a different way you can go about resolving this issue, without

    having to use the .vit method.

    It is possible to open multiple instances of an executable by adding the

    line allowmultipleinstances=True to the ini file of the executable. With

    that in mind, I suggest you workaround this issue by creating an executable

    of the test template, and call it in the main VI using the system exec.vi,

    located in the Connectivity palette. I tried it with an already created

    Xcontrol (from the example finder), and it worked as expected.

    The workaround seems like it will function, but not the solution I would have preferred.

    -Keith Fadgen

    Download File:post-689-1156204554.zip

  10. Hello,

    Long time reader, first time poster...

    I have any xy-chart implementation I would like some comments on. As we're all well aware of, LabVIEW doesn't have a true native XY-Chart graph. I recently required one for a DAQ system that was communicating with several serial devices. Each device would send data back at different intervals. I wanted to plot each point as it was received into a standard strip chart style graph. I hunted and started looking into the buffer style xy-graph, but wasn't pleased with it entirely. It did work, but not as well as a standard strip chart. I came across a post in the NI user groups that got me thinking about the implementation in the vi. I wrote up this dummy vi to test it out and everything seems to be working as I would hope. I would love to hear from people if they think this won't work well. The code is in 7.0.

    Thanks,

    Keith

    Download File:post-689-1095347916.vi

×
×
  • Create New...

Important Information

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