Mellroth

QUOTE (Val Brown @ Aug 28 2008, 04:15 AM) I second that. The main reason for this is that I like to manage error dialogs my self. /J

QUOTE (Harshvardhan @ Aug 27 2008, 02:07 PM) Hi, If you want to run the application before any user is logged in, or for all users, you can create a NT-service of your application. A NT service runs without front panel and in the background. To communicate with the NT service you'll have to use VI-Server or UDP or TCP/IP etc. Check out the link http://zone.ni.com/devzone/cda/tut/p/id/3185 to learn how to do this. /J

I always use the way Ben mentioned, but on machines with multiple network cards, I first set the Str2IP primitive to return multiple. This way I can get IP addresses of all my cards. /J

QUOTE (maybe @ Aug 20 2008, 09:52 AM) I would say that this is a bug. Since NI is allowing us to set a background picture, that background should also be present when we capture the FP picture. Workaround? Do you really have to put the picture as background? If not, then just paste the picture on the FP (becomes a decoration) and send it to the back. Now the FP picture should include the picture, since it is included as a decoration on the FP. You might also want to consider locking the picture on the FP, so that you don't move it around by mistake. /J

QUOTE (normandinf @ Aug 13 2008, 02:38 PM) I don't think this was possible in LabVIEW 7.1 (assuming goran is using 7.1)? QUOTE (goran @ Aug 13 2008, 10:49 AM) ...How can I do this?... So to implement this in LabVIEW 7.1, you would either have to create your own drag'n'drop; using mouse down events, copying data, tracking where mouse was released etc., or go for another solution If you only have an ActiveX component as the target for the drag and drop (i.e. only one target), you could probably use double-click in the listbox instead as a trigger to copy data from the listbox to the ActiveX component. /J PS. I decided to make a small VI for you that makes a quick and dirty drag-n-drop possible in LabVIEW7.1. It also shows how to use double-click instead. Download File:post-5958-1218635787.vi

QUOTE (Omar Mussa @ Jul 8 2008, 06:58 PM) I agree, this feature is really handy. I was just trying to point out that I have seen strange bugs, because people don't use the output iteration correctly, and thought this was a good place to stress this difference from an ordinary FOR loop. /J

I really like the conditional terminal of FOR loops, but I have seen a number of implementations where the programmer uses auto indexing outputs just as on an ordinary FOR loop. Causing all kind of strange errors in the program, errors that can be quite hard to find. Using conditional terminal; Length of the indexing input is not necessary equal to the Length of the indexing output, unless all iterations are completed. Not using conditional terminal; Length of the indexing input is equal to the Length of the indexing output. /J

QUOTE (blueguard @ Jul 8 2008, 01:42 AM) QUOTE (Aristos Queue @ Jul 8 2008, 02:08 AM) Those are part of the LabVIEW DSC package, not part of LabVIEW itself. As Aristos said, these specific controls are part of an add-on package, but you can change the appearance of existing LabVIEW controls as well; * If you only need to change the looks of a control, use the control editor. * If you need to change the behaviour, e.g. to use specific formatting depending on the value, use Xcontrols. /J

QUOTE (prads @ May 28 2008, 05:31 AM) Hi prads, it is always easier to get good answers if you can post a picture, or a piece of code, to show us what you have done. If you want the bits to be written on the next row, add a newline '\n' at the end of the timestamp. Appending data to a file does not require the Set Write Position to explicitly tell LabVIEW to append the data at each write operation, it is only necessary to do this before you start writing data to the file. Hope this helps /J

QUOTE (prads @ May 16 2008, 09:03 PM) Prads, When you say you don't use any packaging, do you mean that you only want to; 1. read the contents of a file (raw format, i.e. byte by byte) 2. transfer the content to another computer (e.g. using TCP/IP) 3. write content to a new file (basically making a file copy over the network) You will probably get more/faster help if you could show us what you have done so far, and perhaps also show the contents of the file. /J

QUOTE (prads @ May 16 2008, 01:19 AM) You will have to create most of the ASN.1 support by yourself, at least that was the case last time we used it. 1. Specific ASN.1 support for sending/reading data? No, but you can use the TCP/IP or UDP support fort the actual transfer, but formatting according to ASN.1 has to be created. 2. No, Encoder/Decoder for ASN.1 does not exist in standard LabVIEW as far as I know. 3. again, as there is no native support for ASN.1, you'll have to come up with a clever solution. Using the primitives as you have done so far is a good start. This file you mention, does it contain packed data (ASN.1 encoded), or is it a description of the protocol? QUOTE (tcplomp @ May 16 2008, 05:21 AM) For instance what is ASN.1? ASN.1 is a way to describe packaging of data in communications. http://en.wikipedia.org/wiki/Abstract_Syntax_Notation_One /J

QUOTE (cheekychops @ Apr 30 2008, 04:43 PM) Maybe like this 1. A = your array 2. Check A greater than t, where t is a threshold value (i.e. use A > t), gives you a boolean result array B. 3. Search B for value of TRUE, this gives you the index of the leading edge. 4. Use the leading edge index as start index and search B for a value of FALSE, gives you the trailing edge index. /J

QUOTE (minority @ Apr 23 2008, 08:51 AM) One thing that comes to mind, is to check the build specification, so that VISA is included in the build. Other than that, I think you'd have to post some code for us to look at to get more help. /J

QUOTE (crelf @ Apr 14 2008, 02:21 PM) Yep, I'm happy my ears are still in place... /J

Put on some headphones and goto [/url] to get a virtual haircut./J

QUOTE (souske @ Apr 14 2008, 09:40 AM) It might depend on the type of cRIO you are using, we had a cRIO-9012 controller where we used us timing without any problem (the actual resultion in the timed loop was more like 50~80us). To enable MHz support, have a look at these links on NI.com: http://digital.ni.com/public.nsf/allkb/0C0...6256F6700061790 http://digital.ni.com/public.nsf/allkb/5B1...13?OpenDocument Please note that enabling MHz support will also take a lot more CPU, and that is the reason that it is not enabled by default on some RT targets. /J

QUOTE (souske @ Apr 10 2008, 03:18 PM) If you enable us support on the cRIO you can probably get closer to the 1ms target, by using the RT specific "Wait until next multiple" with 1000us as input. /J

QUOTE (rolfk @ Apr 10 2008, 08:22 AM) Throttling does not seem to be the goal here, but to run each iteration as fast as possible (a calculation loop maybe?). If the loop would only perform an action when the RT FIFO was set, then I would also go for the event, but in this case the RT FIFO is used to check a STOP condition. /J

QUOTE (crelf @ Apr 9 2008, 03:38 PM) Nothing like a hijacked thread before first cup of coffee... I agree with you, in the end it is up to the user to understand how to use the tools. QUOTE (orko @ Apr 9 2008, 04:19 PM) Personally, I think the above behavior is evil. Sorry, but I don't care if it makes sense that it happens procedurally... can someone tell me why in Pete's sake I would ever want to select "no" in this situation...? What really bugs me is that there is no information that you might loose your block diagram if you select no. The choice of Yes or No is like to ask if you want to keep your orange or get an apple, but there is no information telling you that if you select the orange the only thing you'll get left is the peel. /J

QUOTE (rpodsim @ Apr 9 2008, 10:14 PM) I would suggest that you actually benchmark the code (run the code N times and check duration) to see which piece of code is faster, but I guess you are looking for general remarks. First, I don't understand what you are getting at with these screen shots, the only difference as far as I can see (before my first cup of coffee) is that you have wired the default values in B? Are you actually asking whether or not to wire default values to all inputs? There is another thread here on LAVA that discusses the benefits of wiring all inputs to a sub VI call, check that thread to see if that might help. Second, in the lower part of the RT FIFO init, you can select mode of operation, polling or blocking for both read and write operations. Polling, which is default, is faster as long as you have the CPU power, on lower end machines (e.g. cRIO) the blocking can actually be faster. ryan QUOTE (Eugen Graf @ Apr 9 2008, 11:10 PM) ...And I think to use "0"-timeout is not really good. I preffer "-1" as timeout value... Most times I would agree with you, but in this case where Ryan is trying to minimize overhead using RT FIFOs, timeout 0 is OK (and preferable). The reason is that with timeout = 0, the read operations just polls the buffer instead of waiting for an event. /J

QUOTE (Aristos Queue @ Apr 8 2008, 11:07 PM) QUOTE (Justin Goeres @ Apr 8 2008, 11:49 PM) May I suggest a version control system? We actually filed a bug report about this a while back (2003?), but found out that it was the way some users used ClearCase that caused the removal of the block diagrams (on VIs as well as controls/typedefs). In our case some users had a lot of code opened in LabVIEW, then when a VI was modified they tried to save the VI, but to do so they had to first CheckOut the VI in ClearCase. The CheckOut could then in some cases (e.g. if the cs-file was changed after the VI was loaded, so that a later version was selected), cause the change on disk AQ is mentioning. My point is that even with a Version Control system, you have to be careful. You could still lose a BlockDiagram and be forced to do the work all over again. /J

QUOTE (scls19fr @ Apr 7 2008, 10:28 PM) You'll have to create a way to signal that a sequence is aborted, so that the main VI sets a running state and the subVIs just reads the status to see if another step should be taken. This can be done using a number of different primitives/patterns; * using notifiers/queues/occurrences, using these primitives means that you'll have to feed every "sequence runner" with the queue/notifier reference. * using a functional global, i.e. a VI with an uninitialized shiftregister that stores the status information you need. * ... /J

QUOTE (alexadmin @ Apr 7 2008, 02:50 PM) If you write data in larger chunks I don't think there is a problem, maybe you can buffer data instead of writing the file byte by byte? As a test I generated 5MB of data and wrote that to the file in one shot, then the code completed in a few seconds. /J

We experienced a decrease in speed using VIs with subroutine priority in two different timed loops (on a dual core machine). Removing the subroutine priority got us back on track. If I remember correctly, some of the VIs were reentrant, which makes it much harder to understand why the subroutine priority affected performance. /J

QUOTE (Götz Becker @ Apr 1 2008, 09:26 AM) Hi, I think that one of the reasons your memory grows is that you start filling the Queue with elements of length 1,2,3,4 etc. this means that the queue element only allocates this amount of memory. At some point the queue element that was once initialized with a size of 1, will get a larger buffer written to it, and will therefore keep this new larger buffer in memory. This will continue for all your queue elements. In the end, all your queue elements will have a allocated size of 4999*8 bytes. This could then explain an increase in memory of about 4999*8*500 ~ 20MB. To test this, add some code right after the InitQueue primitive that adds 4999 dbl values to all buffer elements, and then removes all elements (thus pre-initializing the amount of memory the queue will use). /J