Jump to content

psychomanu

Members
  • Posts

    27
  • Joined

  • Last visited

    Never

Posts posted by psychomanu

  1. QUOTE (Michael Aivaliotis @ Apr 3 2009, 05:11 PM)

    The design I included was just to illustrate the principle. I'm aware of how to use error terminals to control dataflow. I disagree that stacked sequences are per definition bad practice. There are situations where I prefer a stacked sequence over a bunch of daisy-chained subVI's, especially when dealing with code that I prefer not to be in subVI's, like property nodes of front panel items or so.

    QUOTE (psychomanu @ Apr 3 2009, 11:54 AM)

    QUOTE (Michael Aivaliotis @ Apr 3 2009, 05:11 PM)

    Exactly. This is why you don't use sequence structures.

    With my suggestion this argument against stacked sequences no longer applies, making them perfectly good practice, just like any other stacked structure like a case structure or event structure. Anyway, it was not my intention to start endless discussions, I guess this comes down to personal taste. Thanks for all reactions.

  2. I would love to see a shift register in a sequence structure, to propagate an error cluster for example. Now you need sequence locals for each step, and if you need to insert a step later on you need to rewire things. I use local variables to propagate the error cluster, but that's 'bad practice'.

    Not so with this type of structure (this was made with Paint, just not to confuse anyone, it does not exist in LabView as far as I know):

    shiftregister3.png

    Looking forward to reactions,

    Manu

  3. Hi,

    We use intensity plots to display relatively large images (2Kx2K), which are quite noisy in some parts, and less in other parts. The problem is that the apparent average intensity in the noisy regions is too high. It is a display problem, because if you zoom in it dissappears.

    Just have a look at the included picture that displays noisy data (randoms between 0 and 1). As long as the number of pixels is low (relative to the number of pixels on the screen) there is no problem (left image). When displaying larger arrays you expect to see about the average value (0,5). Instead it prefers to display the brighter values. This is wrong behaviour IMHO. When an array has to be downsampled to be displayed on screen, it should happen in an unbiassed way, not preferring higher or lower vvalues. The IMAQ intensity plot behaves correctly, as does any image processing software I tested.

    Any comments or solutions?

    Thanks,

    Manu

    screendump.png

  4. Thanks for this elaborate answer.

    We realise we are at the edge, but we had hoped to be able to use at least the 2 GB. With a /3GB flag in your boot.ini you can tell Windows to allow a single application to grab up to 3 GB (we use a third party program that actually does this), but with LabVIEW we still get stuck around 1 GB.

    I guess we'll have to work in chunks of about 700 MB. That said, their is a function described in the code interface reference manual, called DSMaxMem (and AZMaxMem) that is supposed to return "the largest contiguous block of memory allocatable". However, it always returns a zero (we made no error in datatype or something). Do you happen to know why, or maybe another way of finding the largest possible memory block (without resorting to virtual memory which is way too slow for what we are doing)?

    Thanks again,

    Manu.

  5. Hi,

    we have an application that needs an extremely large array of singles in memory (array sizes up to 1.6 GB, preferably more, size varies)

    With LabVIEW we can fill the memory only up to 1 GB (appr. 750 MB array, rest = OS) even though 4 GB RAM is present.

    With C we can go up to the Windows defined limit of 2 GB (appr. 1.8 GB array, rest = OS), so RAM fragmentation is not the cause of the 1 GB limit.

    Question 1 : does anyone know why the 1 GB limit exists in LabVIEW?

    Question 2 : does anyone know a way around this

    Question 3 : could we do the allocation in C and then let LabVIEW access this memory space?

    Thanks in advance,

    Manu.

  6. Thanks for the info. I contacted NI Belgium and this is indeed an example of functionality that cannot be used in an executable since the new default values cannot be saved to the vi because it is embedded in the exe. I have to do it using a configuration file (an ini-file).

    Don't you think the application builder should give a warning in such cases?

    Greetings,

    Manu.

  7. Hi all,

    I use the VI server to call the VI method 'make current values default' to store some control values for the next time the vi is launched. This works fine, but when I build an executable I get "Error 1044 occurred at Invoke Node in...." and the possible reason "VI is locked".

    Of course there is no vi anymore. Is there more functionality that cannot be compiled to an executable? Is there a workaraound in my particular case besides the obvious configuration file or ini file?

    Thanks.

×
×
  • Create New...

Important Information

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