Jump to content


  • Posts

  • Joined

  • Last visited

Profile Information

  • Gender
    Not Telling

LabVIEW Information

  • Version
    LabVIEW 2019
  • Since

MikeC3's Achievements


Newbie (1/14)



  1. Update on this (with pictures!). Have now replicated this issue in our lab environment. It takes between 7 and 8 days to show up, and affects both system and classic enums. A possibly related issue that happens at the same time is the font size my screen title changes (seemingly spontaneously) from 91 to 4. Normal (taken after a system restart) Smaller: JKSH - The user's computer have only one screen, and this application takes up the full screen.
  2. Having a very strange issue. Running an executable application under LabVIEW Runtime 2014 SP1 (patch f3, I think) on Windows 7 SP1. The application has a few typedeffed system enums on the front panel. After some amount of time (between 1 to 15 days is as precise a report as I have so far), the text of the drop down menu (not the main control) reduces font size to the point of being unreadable. I can still select each item in the enum and the correct action results, so it appears to be just a cosmetic change. I'm not even sure how I would intentionally do this, let alone why it appears to happen spontaneously. If I exit and restart the application, everything goes back to normal. Anyone seen anything like this?
  3. OK, so let's say I have a .NET assembly that I use frequently throughout my application. I call the constructor in my initialization code, use the same object to do whatever function throughout the code, and I close the reference in my shutdown code. Sound good so far? Reading seems pretty straightforward, as I can just close the .NET object that I get from the property/invoke node after I'm done turning it into a cluster. So then I want to write a cluster/struct to that .NET assembly using a property or invoke node. Is it better to construct->populate->write->close this struct object every time I need to do this, or to keep re-using one struct object every time I write (which can be as often as 100-200ms, depending on state), constructing and closing it at the same time as the main .NET assembly? Finally, some strange behavior (at least to me) seems to happen when calling a .NET method that takes a "ref" argument. This appears in LV as an invoke node with both an input and output terminal for the same argument. I would expect this to return the same reference to the .NET object on the output terminal as was passed to it on the input terminal, but this is not what happens. Instead you appear get a new copy of the reference (with a new refnum value if you probe it) on the output terminal. So you need to close both the reference you passed into the invoke node, and the reference that was returned. Has anyone else encountered this? Is this expected? Another thought on this: does it make a difference whether I use a get/set invoke node or just access the property directly?
  4. Thanks, ned. That is what I have been doing up to this point. I was just hoping there was a way I could put more of the .NET object construction and manipulation inside my C# code. I'm fighting some nasty memory leaks in this code right now. When I run it completely in C#, memory usage is flat. When I run it in LabVIEW with C# .NET assemblies, I see an increase. I have sprinkled close reference vi's throughout the code, wherever it doesn't break things, and it seems to help, but still gaining memory. Is there a recommended way/time to close .NET references that are used as structs?
  5. I was writing a long summary of what I was trying to do, when I realized it might be best to start off with a simple question: Is it possible to pass a LabVIEW cluster to/from a .NET invoke node? I have complete control over both the .NET and LV code, but I have not been able to find a way to do this.
  6. Mark, Awesome job! So great to have these available to those of us not fortunate enough to attend. Mike
  7. Same here, the ? glyph thingy instead of quotes or apostrophes. Using chrome 36.
  8. Had to install the right software to the cRIO, then enable it via MAX (Time Settings tab, under Time Synchronization). Then some tweaks to the configuration so that we had a consistent master, in order to avoid a situation where on every power cycle, a different clock in our network became master (which caused the time to jump around a lot more than we wanted). Also using cRIO-9024 and 9025s.
  9. What cRIO version (OS) were you using when the rebooting when adjusting system clock happened? We have some systems using 1588 to sync clocks, haven't noticed any problems with that under VxWorks.
  10. I've never been on the contractor side, but I have worked on the customer side as part of a large corporation who contracted out software work. I vastly preferred working with "purchased service" vs "purchased product" contractors, mostly because the projects were always much more complicated than we realized at the outset, and it was just a much "easier" relationship. There wasn't all the contention of whether the software met the requirements or not (like in too many buyoff reviews), and the contractor would get paid by the month based on billable hours. Also, I (as the customer) would usually end up owning the source code at the end of the project, which could be good or bad depending on your perspective. And the relationship was easily scalable, either by extending the term or adding additional internal or external resources. Granted I never had to get much into the legal, contract, or financial ramifications. And I never had to consider terminating a contract and the inherent uncertainty that causes.
  11. Ah, the old anti-virus vs LabVIEW battle strikes again. I once had to run around the lab from machine to machine, unplugging each from the network. An automatic definition update was marking LabVIEW DSC as malicious and deleting it. I managed to save at least one system and could use it as a source for the missing files. Make sure you resolve the issue in the anti-virus (add the file to the white list or something similar) before trying to restore. Otherwise it will keep deleting it.
  12. How are you exchanging references? If the only place to get a reference is through the mediator, the mediator can force all references to point back to it, and then relay the message to the proper client. That way the different parts only know about the mediator and don't have any reference to any other client. Some more info on architecture might help. Ditto this. It can be useful to know about these from a debugging point of view, but for final product, I ignore at the replier level.
  13. Back on the SCM side for a sec, I haven't tried it, but I have read in documentation about a "repair file rename" feature that will make things happy on the SCM side if the files are renamed in your IDE. I'll have to try that next time...
  14. I've only done this once, but I was able to do a rename of a class and some VIs and keep things consistent with SCM (non-integrated SVN) and LabVIEW. It does involve repeating yourself and doing a few things that don't feel... right, but the end result seems to be good. YMMV. First, with LabVIEW closed (and blisfully unaware) make a copy of the files with their new name in your SCM (thus preserving history). Commit this change, so you now have two copies of the file in your SCM: oldName.lvclass and newName.lvclass. Then, in your working copy (NOT repository) delete the newName.lvclass (and any other files that were copied). Do not commit this change. Next, open LabVIEW and load the oldName.lvclass into your project. Everything should be fine, because LabVIEW only sees what is in the working copy. Now rename (in LabVIEW) oldName.lvclass to newName.lvclass. You should now see modified versions of newName.lvclass in your working copy. Commit your changes. This should commit the deletion of the oldName.lvclass (done when LabVIEW renamed it) and the modifications to newName.lvclass (whatever LabVIEW did to make it happy). You now should have newName.lvclass, with full history, and a happy LabVIEW. Again, YMMV as I've only done this once (in recent memory) because I didn't want to have to redo a day's worth of work over a name. In normal situations, I stick to Darren's law of never renaming (especially once the file is in SCM).
  15. I've been doing LabVIEW almost exclusively for the past two years, after coming from a C++/Perl based development team (with a smattering of other languages thrown in there too, including LabVIEW). And coding in LabVIEW just feels different from coding in a text based language. I don't think that coding on either side really feels like work, but LabVIEW feels more like a game to me. Maybe it's all the mousing, since I tend to like mouse heavy strategy games. Just line up your functional armies and march towards the tunnel . I consider this a huge benefit, since it helps me like my job, but I can see how others have a hard time seeing it as a "serious" language, when it's all pretty pictures with lots of colors. "Programming by cartoon" as my perl and python co-workers called it. Another part of the difference for me is just how different the sound of coding is. Intense bursts of keyboarding vs click-drag-release. Also, my co-worker has a USB hamster wheel that is supposed to spin faster as you type faster. Just doesn't do much in LabVIEW.
  • Create New...

Important Information

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