JDave

QUOTE(Michael_Aivaliotis @ May 4 2007, 01:15 AM) I agree that RTFIFOs are the best options for the determinism that has been discussed. Regarding the other methods discussed here to implement a lossy queue, I want to hear why it is necessary to have a proxy. I ran some benchmarks on my machine to see how long it took to enqueue an element in the producer loop, with the following results. 'Lossy enqueue' refers to the code seen in the proxy loop of Michael's code -- Enqueue, Dequeue if full, Enqueue. Enqueue to proxy queue with no size limit -- 1 microsecond Lossy enqueue with no subVI (queue full) -- 15 microseconds Lossy enqueue with no subVI (queue not full) -- 1 microsecond Lossy enqueue with subVI (queue full) -- 18 microseconds Lossy enqueue with subVI (queue not full) -- 2 microseconds The lossy enqueue method with no subVI suffers from problems if you have multiple writers to the same queue, see here. It seems to me that if you are having problems handling a jitter of 15 microseconds then you have a high speed application that could benefit from the determinism of an RT system and RTFIFOs. But for the majority of applications wanting a lossy queue, why go through the bother of having a proxy? Just make a subVI that does a lossy enqueue and use it directly in the producer loop, like my post above. David

QUOTE(hagemaru @ May 8 2007, 02:59 PM) It should be easy to point you in the right direction if you post your code showing what you have tried.

QUOTE(Eugen Graf @ May 8 2007, 12:43 AM) I don't know of any examples for publish-subscribe except for DataSocket -- search for 'subscribe' in the Example finder and only one comes up. There are several ways of accomplishing this, and Michael suggested a good one. Variants would make it flexible. Some different ways of doing publish-subscribe are DataSocket, programmatic -- this is lossy, but gives you programmatic control over who is publishing and subscribing and when DataSocket, front panel -- also lossy, can bind a control to a datasocket or shared variable without any code Queues -- not lossy, must create separate queue for each subscriber Functional Global -- probably lossy, no intrinsic way of notifying subscribers that new data is available User Events -- not lossy, can notify many subscribers with one event, must individually 'register' for event in each subscriber. I like this one because once you set up the registration, you just fire one event to publish. That surely isn't all of the available methods, but you can look for examples in any of those areas. For User Events I would look at the examples "Dynamically Monitor Vi's.vi", "Dynamically Register for Events.vi", and "Programmatically Fire Events.vi" David

QUOTE(Tomi Maila @ May 3 2007, 10:25 AM) I am not questioning the need for lossy queues. I am questioning the need to have some separate messaging mechanism to do a "lossy enqueue". Why signal someone else to do the logic of check if queue is full dequeue if full enqueue when you can just do it in a subvi. The subvi is only blocking to multiple writers. How often do you have multiple writers to a single data queue? If this is the case, then you are right -- some messaging mechanism is necessary to decouple it. However there is no need to lock the reading of the queue. This would be a standard read function so you maintain determinisim. http://forums.lavag.org/index.php?act=attach&type=post&id=5715 QUOTE(eaolson @ May 3 2007, 10:32 AM) I think the problem becomes that, if you have multiple threads enqueueing, it is possible that they will conflict. See Aristos Queue's post http://forums.lavag.org/index.php?showtopic=3406&st=15#' target="_blank">here. AQ is talking about multiple writers accessing the same *native* enqueue function which is non-blocking. What I am suggesting is very similar to what Tomi suggested later in that same thread, but he mentioned wrapping all the queue functions into a sub-vi. This would block the read and the write, and cause the problems he was referring to (above quote). David

QUOTE(eaolson @ May 3 2007, 09:28 AM) Thinking about it that way, do you need to protect it at all? If you have a non-reentrant wrapper around your enqueue function then you already have a sort of semaphore on the writing of the queue. If you want to protect read and write then make it a functional global wrapper. Then use the same logic, if you go to enqueue and it is full, dequeue one. If you don't protect the read then the worst case is you have a race condition as to which queue entry you drop -- but it is a lossy queue so it doesn't matter which one you drop. Or am I missing something here?

QUOTE(EJW @ May 2 2007, 12:03 PM) It seems that you are asking about more than just Nyquist theory and your data requirements. If so then what is *fast* and/or *intensive* depends on what you are doing with it. Are you just monitoring a data stream for certain conditions, streaming to disk, massaging the data, displaying the data, taking 'many channels in parallel, etc. (which begs the question, how many is 'many') And as you mentioned "High Speed data acquisition" is relative to the hardware capability. Better hardware means that high speed gets higher and higher. So ignoring data requirements, the question would be relative to the software task and the hardware capabilities.

So if I am in debt, does that mean that I need to send Michael three PM messages to make it all even? http://forums.lavag.org/index.php?act=attach&type=post&id=5694

QUOTE(crelf @ Apr 28 2007, 08:25 PM) I thought I would comment that the presence of HHs is not entirely a bad thing. It shows that not only LAVA, but LabVIEW is becoming main-stream and is featured in academic settings. As more curricula use LabVIEW, more students will come to the internet looking for knowledge, insight, and occasionally someone to do their homework for them. I really like the recent addition of wiki articles for many reasons. But a good benefit along the lines of this thread is that it can provide a 'standard' way of answering simple questions that are covered in wiki articles, as well as politely remind newcomers of what is expected. It also allows people to another way to give to the community. As a newcomer myself (I give much less than I receive) I appreciate help that I have received from the LAVA community. But I must acknowledge that I hesitate at times to ask questions because I wonder whether they will be advanced enough or appropriate enough. David

QUOTE(alnaimi @ Apr 29 2007, 02:26 PM) Do you mean to have your program check Windows login priviliges? Or just have various levels of priviliges to your own program based on your own login system?

QUOTE(Nullllll @ Apr 27 2007, 11:06 AM) It is very true that respect and decorum are very necessary on a forum, especially an internet forum where intonation, inflection, and humor are often lost or misinterpreted. And this forum is certainly meant to help people. Apologies were certainly helpful. It is also true that this forum has the stated intent (from its very name) as well as a history of having more advanced topics discussed. This has been true for my brief time here, and I have appreciated it. When I have a basic question, I cross over to the 'dark side' at forums.ni.com. It seems that I almost always find my answers to such questions by simply searching the forums there. While basic questions are OK, they need to be specific and it would be really nice to include code showing what direction has been taken. From my limited experience, this forum LOVES to help and give advice (and even code) to specific questions. This forum also tends to loudly protest when it seems that not enough effort is being done on the part of the person asking the question. Sometimes, we may protest too much. Perhaps there are some who are just trying to determine what the correct feedback parameters are to maintain a reasonable SNR level.

QUOTE(Sally @ Apr 26 2007, 12:56 PM) From all those dollar signs, it seems like you are asking for bids. The type of help you are asking usually is done by consulting businesses.

QUOTE(AdamRofer @ Apr 12 2007, 02:01 PM) I will try this out. Thanks!!

mballa's post on the property page reminded me of something I was trying to do a while back, which is to invoke the icon editor programmatically. Has anyone looked into calling the built in icon editor programmatically? I was working on an Icon Editor and I couldn't figure out how to call the built in editor. If I used a custom icon editor for LV 8+ which replaces the built-in editor, I also had a problem figuring out which VI had invoked the icon editor. I was trying to use the VI name to auto-generate some text for the icon, but I could not get the name or reference of the VI that called the Icon Editor. I tried the front-most property, but the icon editor was already frontmost from the get go. I tried some scripting properties like "Active VI" and "MenuLaunchVI" but also to no avail. Is this a purposeful roadblock or what? David

Just a stab in the dark, since I haven't tried it (and can't since my LV machine is temporarily elsewhere :thumbdown: ). Have you tried simulating the keypress (Ctrl-I) to bring up the properties page? The correct VI would have to have focus, I suppose, and I don't think you could force it to open to the Documentation tab. It does go to the last used tab, if I remember correctly. Not clean, and perhaps Windows only, but I haven't found much when looking in similar areas. David

I am an equal opportunity eater. Everything has a fair shot. “I am not a vegetarian because I love animals; I am a vegetarian because I hate plants.”A. Whitney Brown

QUOTE(Aristos Queue @ Mar 18 2007, 12:30 PM) It is also my experience that the left-most destination is the fake. I haven't noticed anything specific for other destinations. The game needs to clarify if a destination is 'invalid' or not. There is nothing there to indicate on way or the other, except trial and error. QUOTE(Darren @ Mar 18 2007, 06:42 PM) I've only made it to level 14, and I noticed that the left-most pipe seems to be the "fake" one. I only determined this by losing, then clicking "retry" after losing, since the "retry" lets you start over on the same level you just lost (unfortunately, your score is reset). -D P.S. - As for having "waaaaay too much time for playing games in the arcade", I'm currently in the middle of 5 weeks of paternity leave, and my older kids (not the newborn) *love* to watch me play [wiki]LAVA[/wiki] arcade games. Plus, it's a good time-killer when trying to rock a baby to sleep... I have been waiting to get that PM that says my Plumber score was surpassed.... Congratulations on the new baby!!

QUOTE(alfa @ Mar 16 2007, 04:41 AM) To be more helpful, you really need to give some examples. Which trips did you enjoy the most? Were they the 1-dimensional trips? Or do you prefer the 3-dimensional trips? Also it would be good to know if you required special preparations for certain values of n.

QUOTE(sertol @ Mar 7 2007, 10:48 AM) It would be easiest to point out how to fix the problem if you posted the code or at least a picture of where you are having to select the configuration file in the code. The short answer is to wire in a path constant containing the path of the config file rather than leaving it unwired or using a file dialog. David

QUOTE(Steve Weidman @ Mar 7 2007, 05:37 AM) Judging by this statement it seems that you are using the "Latch When Pressed" or "Latch When Released" action. These actions cause the boolean to revert back to false after LabVIEW reads the boolean in the program. If you use the "Switch" actions, then the boolean stays true even after LabVIEW reads the switch. David

QUOTE(Steve Weidman @ Mar 6 2007, 12:33 PM) This latching behavior is found in the "Mechanical Action" submenu that is available upon right-clicking on the boolean. The correct behavior depends on how you want to reset it. If you want to reset it programmatically, then you would choose either "Switch When Pressed" or "Switch When Released". This would change the boolean state and leave it in the new state. Then you would change it back in your code. If you want to have the boolean change as soon as you press it, and then 'reset' when you let go, then choose "Switch Until Released". I hope that helps. If you are talking purely holding or latching a value in your code, then look into shift registers. David

QUOTE(Val Brown @ Mar 1 2007, 07:27 PM) I had some problems trying to back-save from 8.2 to 8.0 a while ago. I seem to remember specifically having an issue with the new SPACE constant in the String palette. There might be other problems. What is the exact error message? David

QUOTE(Tomi Maila @ Mar 1 2007, 08:16 AM) So have the event case in the main VI that is holding on to your FGs. Have that event case then clean up the FGs before ending the event case.

QUOTE(Ben @ Mar 1 2007, 05:32 AM) Considering that the LV 8.2 release came soon after the troublesome 8.0 release, and little if any code is being maintained in an 8.0 version, I would like to see an option in 8.2.1 to back-save directly to 7.1. Why install 8.0 just to get back saving? And Tomi, weren't the majority of those bugs related to developing LVOOP code? David

QUOTE(Jim Kring @ Feb 22 2007, 09:43 AM) I sometimes forget that Open Source is like that. Makes me appreciate all that work so much more :worship: . In all seriousness I think that the efforts of JKI and OpenG greatly benefit the LabVIEW community and show NI that there are professional LabVIEW programmers who want -- and provide -- professional tools. And those come at a cost. I retract my selfish plea. Creating my own packages has just been something that I tried unsuccessfully to do (though I didn't spend a lot of time on it). QUOTE(Jim Kring @ Feb 22 2007, 09:43 AM) Since the release of VIPM 1.0 in January 2007 (just over two months ago), the rate of OpenG library usage has increased by (20x). That is quite impressive.

QUOTE(Michael_Aivaliotis @ Feb 22 2007, 01:04 AM) Package creation is an important concern, if not the problem here. I remember looking at the Package Builder a while ago and it was lacking in documentation and help. With VIPM looking and working so beautifully, hopefully there will be a parallel effort on the utility to create packages that are installed with VIPM (bundled up with VIPM, naturally :thumbup: ). Just don't limit it to the Professional version. :thumbdown: If all these features that are being tossed around about VIPM are implemented, it will truly be the http://forums.lavag.org/index.php?s=&showtopic=3644&view=findpost&p=14700' target="_blank">next must-have app.