Jump to content

LAVA 1.0 Content

Members
  • Posts

    2,739
  • Joined

  • Last visited

  • Days Won

    1

Posts posted by LAVA 1.0 Content

  1. CITATION(Jim Kring @ Apr 3 2007, 04:13 AM)

    Also, if your end deliverable is an EXE, it's best to create your build rule early and try to make sure that your application is always working in both source and EXE form. This is a lesson that most learn the hard way.

    I second Jim in this recommendation ! I am part of those who learn this the hard way :(

    There are lots of tools & materials that will help you developping code that works the same both in source and EXE ; time spent to learn about these tools will be well-invested ;)

  2. QUOTE(utaharrow @ Apr 2 2007, 04:29 PM)

    Hello,

    I am trying to send the following command packet:

    I have tried sending the packet as it is...but my servo does not respond. Am i missing something? Do i have to use some converter in LabVIEW to send the packet?

    I would be grateful for any input.

    Thanks.

    If you attach what yo have tried that would make it much easier to help you. With the information you have provided my best guess is that you are writing the ASCII representation of the HEX values. Right click on the string control or constant that is feeding the VISA write (or Serial) and select hex display then enter your hex value.

    http://forums.lavag.org/index.php?act=attach&type=post&id=5385

  3. QUOTE(Tomi Maila @ Apr 2 2007, 10:42 AM)

    Wish You Many Happy Returns of the day,Mike. :)

    Well, thanks to Tomi's trigger, I've become a premium member. This is a toast to Mike, for giving the community such a wonderful platform to share knowledge and have fun... :worship:

  4. LOL!! :book:

    Hey Ben,

    Don't you write scripts to implement LV code like the rest of us???

    Or are you "old school" with those crazy little iconz... :wacko:

    wait... Commander Clerf is calling...

    Wireless: using invisible wires :D

  5. As I understand it, queues will dynamically allocate memory, but free memory only when destroyed. The online help states:

    Note max queue size only limits the number of elements in the queue. It does not preallocate memory. Enqueue the maximum number of elements and flush the queue to preallocate the queue. The queue reserves more memory as its size increases and releases that memory only when you destroy the queue.
    I almost always create my queues as part of my application startup using a fixed size, immediately populate them with dummy data (to reserve the memory) and then flush the queue.

    I think allowing a queue grow to unbounded is "asking for trouble".

  6. QUOTE(Michael_Aivaliotis @ Mar 29 2007, 11:15 PM)

    I use FF and have the same problem. I get following error...

    http://forums.lavag.org/index.php?act=attach&type=post&id=5356

    EDIT: The Problem occours only if there is no new post in the "View New Post"...

    So afther the day changes all all post disapper from the "View New Post" and there is no post to display till the first one write a new post...

    http://forums.lavag.org/index.php?act=attach&type=post&id=5357

  7. CITATION(Eugen Graf @ Mar 29 2007, 09:27 PM)

    Hello all,

    if I see an unlimited queue size, I think LV must realloc the memory every operation with this queue. Now I ask me, its only if the size is unlimited or the memory will be reallocate if the size is definied?

    If the memory will be reallocate, its more more slower as the "normally" queue in other programming languages.

    Eugen

    Good question... If I was at work I would test it on different computers to see if the Q size is actually unlimited !

    I am interested in the answer and the reasons... :book:

  8. CITATION(Ben @ Mar 27 2007, 07:33 PM)

    I should have remebered I was talking to a second generation Wire-Worker.

    Back in the old days....

    Music was recorded on a vinyl disk by modulating the depth of cut of a spiral groove with the information that is to be recorded. The vinyl disks were called "records".

    Very often the the records would get scratched or broken resulting in the probe ( a needle) following the crack or scratch rather the the spiral groove. When this happened the same inforamation would be read reapeatedly. It was common "back in the old days" to refer to someone that was repeating the same thing over and over again as a "broken record".

    :shifty: You should have told me "scratched DVD" to avoid any potential confusion !

    I guess I was to focused on my issue and it slowed down my understanding routine :D

  9. QUOTE(ned @ Mar 27 2007, 08:53 AM)

    The "Flatten to String" is irrelevant here,

    Flatten to string is required to transfer the data via TCP Write and TCP Read. If you're not convinced, wire any enum to TCP Write and note that you will get a broken wire ;) .

    I was simply expanding on sachsm's happy observation that enums can be easily manipulated with string functions. Its more efficient and deterministic transmission wise to flatten the enum to a string than to format as a string and send 'broccoli' when 0x0002 can be used...

  10. CITATION(alukindo @ Mar 27 2007, 06:16 PM)

    TiT:

    I recreated your database in MS SQL Server and I was able to duplicate the memory leak. I got exactly 4 kb of memory leak for each database call from the database VI. I also determined that the fix I suggested previously did not fix the problem.

    However, when I opened the connection just once and left it open in a shift register, the memory leak problem went away. I am attaching your code modified to leave the connection open until DB operations are done. I tested this on my MS SQL Server and it looks OK now.

    I hope this helps

    Anthony Lukindo

    Thanks a lot for the time you spent doing this ! I really appriciate this. :worship:

    When I started the project, I was thinking it would be better to open/write/close each time because I only write at 0.2Hz in the DB. Now I'll code a single open, a single close and a "check if ref is still ok" for when I want to write.

    Someone suggested this before, I guess I should have picked the advice at once. :oops:

  11. Thanks a lot for your post Anthony, I will upgrade the ADO (I currently have 2.7) and do some more testing.

    Just to keep everyone involved in this thread updated, I tested my "write to DB" VIs on a new computer first with MS SQL server 2000 and then with 2005 ; in both cases the memory used by the LabVIEW exe keeps increasing of about 4bytes at each write.

    The code I tested is a very small exe (see source attached), as you can see at each loop iteration, I :

    - open connection to DB using a *.udl file

    - write a couple data (floats)

    - close the connection to DB

    I have an NI car number : 521 262

    As I said earlier I can't spend much time on this issue so I'll send this back to NI and demand an example that works without sucking up all the memory.

    Many thanks to everyone involved in this thread.

×
×
  • Create New...

Important Information

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