Jump to content

ShaunR

Members
  • Posts

    4,530
  • Joined

  • Days Won

    252

ShaunR last won the day on August 1

ShaunR had the most liked content!

Profile Information

  • Gender
    Male

LabVIEW Information

  • Version
    LabVIEW 2009
  • Since
    1994

Recent Profile Visitors

26,450 profile views

ShaunR's Achievements

  1. You know NXG has been discontinued, right? Then Bitman is what you want. The native LabVIEW image tools can be very cumbersome but Vugies toolkit allows layering, advanced processing and filtering (if you want to try it) Then you are almost there by the sounds of it. As I have said in many other threads, I have dispensed with LabVIEW UI's completely in favour of HTML/Javascript. I use a proper web browser (not the LabVIEW UI or embedded browser widget) and use LabVIEW as a back-end linked with websockets.
  2. Oooh. Is that NXG? I don't think there is a lot off-the-shelf. You can interface to GIMP via TCP or ImageMagick as command line but that's probably just as much hassle as writing a simple one of your own and probably too restrictive except for the standard things of cropping and resizing for on-the-fly. It looks like you use ROI's so maybe the NI Vision toolkit would be the best option (if it works with NXG) By the looks of it, you don't really have that much functionality to implement. I, personally, would bite the bullet and implement it either as LabVIEW code (probably using Vision Toolkit or Bitman) or as HTML/Javascript (there are quite a few Canvas drawing API's and toolkits). For .NET there is also a few examples for simple editors and drawing on Winforms. You could call the same functions from LabVIEW nodes to draw on an image control in the FP .NET container. All of that is not what you really want to hear though. If you listed the requirements for your image editor, you may get really lucky and someone might write one just for giggles. But it's unlikely to be in .NET unless they are really a glutton for punishment as few of us use it.
  3. It's a skill we are born with over here. Along with back-handed compliments and damning with faint praise.
  4. You know as well as I do that marketing speak isn't supposed to be intelligible. It's purpose is to say absolutely nothing in a veneer of condescension.
  5. Ah. sorry. Looks like they renamed it. LabVIEW <version>\examples\Object-Oriented Programming\Reference Object
  6. I think this reveals the answer... NI were concentrating on their systems' solutions like Systemlink, NI System Configuration and that other obese LabVIEW thing I never used.
  7. That is a typical symptom of a race condition. I would suggest taking a look at "LabVIEW <version>\examples\lvoop\SingletonPattern". It is much simpler and easier to understand than GOOP examples which have a lot of infrastructure included.
  8. We will see. I've crystalised one interpretation so it up the the OP to refine the question and provide an example of what he has.
  9. I disagree. A FGV is a number of methods around some sort of global variable. An AE is usually (but not exclusively) an extension of that around some sort of global resource which may or may not be a global variable. A LVPOOP class is a number methods around a local variable (the class cluster). Therefore I think the question in this context is "how do I make a class with a number of methods around a global variable/resource"? (A.K.A Singleton Pattern)
  10. That's not good at all. With some fiddling you might get 4-5Gb/s but that's what you expect from a low-end laptop. Are you sure it's Gb/s and not GB/s? You are hoping for at least 20Gb/s+.
  11. Running both client and server on localhost, the CPU usage is about 30% across all cores with one of the cores maxing at about 70%. I would suggest you try the same and see if you still get 100%. Doing this will isolate the network layers from the software. I suspect you will find that your 2GB limit is also present on localhost.
  12. I'll let you fight your argument in court. Until then, I'll just offer anyone who wants the code a zip file of my build.
  13. You are also required to supply the source and compile environments of the vanilla LGPL code even when just dynamic linking and that can be quite big in size. While one may argue it's merely a maintenance overhead, never-the-less, it is an overhead keeping track of (and version control of) other peoples source AND the specific compilation environment one used.
  14. Any strong copy left licence. It's not so much about that. For most open source licences it is primarily about someone taking your software, claiming it as their own, then sticking a new licence on it. You can get into a situation where someone that copies it, claims they wrote it and then comes after you for copyright infringement when you wrote the stuff. I had something like this on the NI forum where someone removed all the copyrights and proffered the toolkit as theirs. NI wouldn't remove it until I pointed out that it violated the licence which stated that all copyright had to remain intact and showed them the original toolkit (which had the licence text). Secondary to that, it enables good faith actors to know exactly how to distribute the software and comply with your wishes.
  15. Not at all. With zero debug information you identified 2 problems when most people couldn't have found the first. When it all goes to hell again, you can smile and say "come back and moan when you resolve that spurious system you refused to do anything about - and bring biscuits"
×
×
  • Create New...

Important Information

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