Götz Becker

QUOTE(neB @ Nov 17 2007, 04:34 PM) I usually try this http://www.sinn-frei.com/zensiert/loituma.swf' target="_blank">classic to replace these kind of songs/sounds. Btw. is there an english expression for the german word "Ohrwurm"? Good luck with it

QUOTE(paololt @ Nov 17 2007, 06:09 PM) Hi, out of curiosity, how do you communicate between your PCs? ICMP, TCP or UDP and what kind of link layer is involved in your setup? I am just wondering if you can find any biterrors using standard hardware. As I recall correctly, there might be several CRC-checks present (TCP for sure and I guess Ethernet frames too) when using standard hw and network stacks.

QUOTE(DaveKielpinski @ Nov 14 2007, 10:35 AM) As far as I know (last time I touched LV-FPGA was in 7.1.1), compiling subVIs of a FPGA-MainVI doesn´t help. Since the result of a subvi compiled separatly would always output a bitstream for the whole FPGA. The same intermediate HDL-Code from the subvi will normally end up different, when its implicitly compiled as part of the mainVI to a bitstream, due to timing and size constraints require other/more optimizations at low level. I don´t think there is a way to incrementally compile HDL-code below http://en.wikipedia.org/wiki/Register_transfer_level' target="_blank">RTL Feel free to correct me

Hi all, I just had a very strange LV (8.5) crash. I was loading 2 main VIs out of 2 seperate LVprjs. During the load of the second VI LV hanged. After killing LV and trying to restart LV I got the error that the VI-Server port 3363 was in use. No other LV was running at the time. The VIs have several .dlls which are also doing TCPIP on port 31415. These ports kept open too, after killing LV. A quick netstat /a /b showed: Proto Lokale Adresse Remoteadresse Status PID TCP gnomeregan:3363 gnomeregan.xxxx.de:0 ABHÖREN 3052 [System] TCP gnomeregan:31415 gnomeregan.xxxx.de:3451 SCHLIESSEN_WARTEN 3052 [System] TCP gnomeregan:31415 gnomeregan.xxxx.de:3456 SCHLIESSEN_WARTEN 3052 [System] TCP gnomeregan:31415 gnomeregan.xxxx.de:3455 SCHLIESSEN_WARTEN 3052 [System] TCP gnomeregan:31415 gnomeregan.xxxx.de:3450 SCHLIESSEN_WARTEN 3052 [System] TCP gnomeregan:31415 gnomeregan.xxxx.de:3452 SCHLIESSEN_WARTEN 3052 [System] The strange thing was, that I couldn´t find the PID 3052 (checked with taskmgr and ProcessExplorer). Anyone seen such lost resources with no valid PID? The only fix I had was to reboot Windows (XP Pro, SP2). Any ideas how this could have happened or where to start searching for a reason?

QUOTE(crelf @ Nov 7 2007, 11:16 PM) Would you then want the 'requiredness' attribute propagate into two inputs of the parent VI, if the input into child is calculated out of those, as well? I hope this sentence makes any sense!?! This is the first time I try to philosophize in english

I would not want such a behavior. The LV 8.5 option to make connector required by default is really good, but my guess is that teaching this new thing to the compiler and the users, exactly when this should happen would induce more problems than it might solve. 2 usecases I came up with:

QUOTE(siva @ Sep 12 2007, 05:24 AM) Hi Siva, thanks for sharing your work and I guess that took some time to fiddle through the bytearrays. I have just two hints (I hope you don´t see them as nagging) after looking at the code. I my eyes every cluster and enums should be typedefs (always). Using normal "Divide" by 2 for array lengths may have unwanted sideeffects for different odd length-arrays (due to DBL->Intger Rounding). I normally have more confidence in the "Quotient Remainder" function for this. just my 2 cents and thanks again for sharing your code!

Hi all, I confess, I am mainly a lurker As a daily reader of the various topics, I discuss many of it with a colleague. Some things just for fun, others like the discussions about the various LVOOP issues are for my personal education in a subject area which I believe is crucial for my future as a LV-developer. greetings from Munich G. Becker

Yes, this is one place I guessed that there would be a buffer allocation, but the result is OK.

Hi all wireworkers, I am working on my first LV 8.5 project and of cause I want to try the some new features of it. One feature I am learning to love is the conditionial For Loop. When dealing with nested array of cluster this is a big time and BD-space saver. The other thing is the new inplace structur. In the screenshot I am working on a large cluster with many nested cluster/array of clusters and at least the "show buffer allocation" indicates that really LV isn´t doing many allocations in this VI. I expected much more of them :thumbup:

Many thanks to both of you! :worship: The VI Analyzer showed the problem. Next time I´ll start with it when bug-hunting. Greetings Götz

Hi all wireworkers, I recently had a hard time finding a nasty bug. Clearly bad programming since the "dbl 1" output is not wired. Is it possible to enable warnings for this type of thing, like the warnings for unwired front panel objects? Any ideas how to automatic search these kind of problems? The VI is saved as LV8.5 Download File:post-1037-1190284217.vi greetings from a sunny Munich with just a few days left before Oktoberfest

This is basically what I did. While moving the mouse in the controls menu LV crashed. :thumbdown:

Thanks for the input. I just can´t get this thing working. Tried the custom probe which resulted in LV crashing. The DAQmx task I create with wired scale name as input (which I can even see with highligthing on) just produce an error the first time I want to write out a value. Enough trial and error for me today, I wrote a "Table Scaling"-VI myself and will stay away from DAQmx scales. Greetings from a rainy and _gray_ Munich :-) Edit: The subVI I used to create my scale: http://forums.lavag.org/index.php?act=attach&type=post&id=5873

I just tried to update my personal profile information at http://forums.lavag.org/edit-profile-info.html but I can´t save the changes because I always get the error : "You entered an illegal date for your birthday. You may have chosen 30th February, for example." I didn´t changed the default "--" entries at birth date.

Hi all, can someone explain me please what "grey" probes stand for? http://forums.lavag.org/index.php?act=attach&type=post&id=5869 Probe 9 in the attached picture doesn´t update, but with highligthing on or a connected indicator I see the correct value. I am trying to get started with DAQmx custom scales but when I try to write using the task handle, it fails because the scale with name xxx is not found. Greetings

QUOTE(Jeffrey Habets @ Apr 4 2007, 04:03 PM) Great... works like a charm! I guessed that scripting is the way to go but I didn´t know where to start. :thumbup:

Hi, I have the "pleasure" to try to check and document a set of .dll-wrapper VIs. My main problem is that I need to check the call setups. Is it possible to programmatically get the "Function Prototype" string displayed in the configure window of a Call Library Function Node? I tried to print the VI documentation but I only get a picture of the BD. Using an invoke node with the VI-ref, I also only get access to the BD image. I have seen the new display option in the 8.2 Version for names in the connector. But the project is in 8.0.1 :-( . And even with the name display I don´t see the exact call setup like how strings are passed. Any ideas or hints? Thx in advance

The feedback node concept is nice, but I wonder why I see a warning sign. I always have warnings on by default. Strange thing in this case is, that the error/warning dialog shows a warning for the VI but no details about it given. http://forums.lavag.org/index.php?act=attach&type=post&id=5333

Problem solved. The C-Programmer of the .dll changed the new memory parts to some static allocation.

Hi, how can I define the stack size for a RT App? The problem is that we have a LVRT 8.0 application that mainly does .dll calls. Everthing is working fine when we test the .dll it on WinXP. The .dll is checked to not use unavailable functions on the RTSys. In fact the .dll worked for about a year but we had to change some memory management related parts and now it needs more stackmem. Now it just crashes the RT-PXI-controller with a kernel error when the new code is executed. Any ideas? Greetings from a warm and sunny Munich/Germany

Are the two inputs the indices for that 2D Array? Then a simple "Index Array" is what you need. The function expands the index inputs depending on the dimension of the wired array input. But i guess i didn

"build array" and "enqueue element" are adding memory... control those and you should be fine. My common mistake or bad programming habit is to use "build array" in a loop to gather values. With small test data all works well, when running with real data things often get large and slow. Another thing hit me once when using queues. I split some work in two threads with a queue in between, classic producer/consumer. classic mistake i made... consumer was much slower and the producer kept enqueueing stuff (it worked for a night until windows rejected to allocate more memory) . Now I always double check if I set a value for the maximum amount of elements when creating stuff with queues and that the producer waits if queue is full. Another thing I had to learn the hard way, is to often use the "Show Buffer Allocations"-Tool. Perhaps you could give a little more detail what the program does. Hope this helps (and feel to correct me if something is wrong)

I wouldn