Leaderboard

Hi all, I went to my customer today to do some tests and guess what ... problem solved Solution: ------------ - pc had errors in the eventviewer: Event Type: Error // Event Source: crypt32 // Event Category: None // Event ID: 8 // Description: Failed auto update retrieval of third-party root list sequence number from: <http://www.download.windowsupdate.com/msdownload/update/v3/static/trustedr/en/authrootseq.txt> with error: This network connection does not exist. For more information, see Help and Support Center at http://go.microsoft....ink/events.asp. The admin was available so he did an update of this. But after logging in as the operator, the problem was still the same. Then we found a solution here. We made the operators local admin and disabled the auto update of the root certificate for XP. (local admin was needed because of the campanies security policy) Startup time after this: 15seconds Thank you all for the info and hints to solve the problem. Maybe this solution can help some of you. Regards, Wim

My thoughts: I haven't frequently had classes with duplicate names in the same project--although it has happened in some of my projects and probably will happen more often--so on the rare occasion when I have seen this I don't mind just looking at the Path. Nonetheless, I agree it would be easier to see this information in the tree view. It's worth noting that classes can only have the same name if they are in different namespaces (e.g., they are in different .lvlib files) so maybe the browser could arrange the classes by .lvlib namespace first? (I don't really know if that will work, but I think it might work pretty well.) [Edit: Ah! I see that jg-code already suggested this as part of the posted idea.] Or perhaps there could be a check box to show or not show the fully qualified namespace in the tree view. (Which do we want? Both! Yeah, that would definitely make AQ's life more difficult.) Anyway, I haven't encountered the situation much so that's all I've got.

Sounds like Battle Chess (and this bit include the Python reference): <object height="385" width="480"><param name="movie" value=" name="allowFullScreen" value="true"><param name="allowscriptaccess" value="always"><embed src=" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" height="385" width="480"></object>

That takes me back to my undergrad thesis. We had to document that, even though all they needed was a PC, a PLC was also needed on the shipboard test system so that the Captain didn't turn off the six-month test the first time the system gurgled. Tim

Here's a VI that sometimes will show what I mean. Hit the 'Fire' event that fires a user event and a value signalling event (in that specific order) In those events I read the current iteration number of the while loop. If the events are in order the First Iteration should be smaller than SecondIteration Sometimes however that is not always the case. I cannot get a resolution like I expected (it seems like the resolution is 1 ms) so I uses a different timer than the Get Ms. Ton EventOrder.vi

One of the main differences is that there are very few support VIs needed (as compared to other by ref patterns) when you are using DVR LVOOP (namely you'll want a constructor and destructor for each class, including descendants). Also, prior to DVR LOOP, most patterns used LVOOP as a wrapper around a reference (e.g. Queue) to data. With DVR LVOOP, this gets flipped on its head -- you have a reference wrapper around an LVOOP object. This is the first thing that really strikes you as different and unintuitive, but once you start using it you'll see that it makes a lot of sense (and, of course, you see some areas where things still need to be further improved). Dynamic dispatch only works on by value methods, not by reference methods. It would be nice if you could pass a reference into a by value method and LabVIEW would dereference and rereference behind the scenes. So, you'll find some duplication is required if you want users of your by reference class to call into by reference methods. You'll need to decide whether you want your users to 1) dereference/rereference the data themselves and then call your class' by value methods or 2) have a by reference method in your base class that calls the by value method. Also, it would be nice if you could wire a DVR LVOOP object into a Bundle by Name and Unbundle by Name and have LabVIEW automagically dereference/rereference the data behind the scenes. Right now, when you want to just get a value of an element of a DVR LVOOP object, you have to use an Unbundle by Name inside an In Place Element Structure. This is too much work for the programmer and makes the code look unnecessarily sloppy. The programmer's tendency will be to create a non-locking Get/Preview data method, but this isn't a great idea, because it makes a complete copy of the data -- by using an IPE Structure with an Unbundle by Name inside, you only copy the element. Those are the main things I've noticed. The bottom line is that if you do by ref LVOOP this way, you're going with the grain and you'll find things to be much easier now and in the future as more native features and usability improvements get added to DVR+LVOOP. Oh, one more thing that I noticed is that edit-time performance seems much better, which is probably due to a combination of: performance improvements in the LabVIEW IDE, WRT projects/classes/etc. fewer support VIs in the by ref classes

QUOTE (neB @ Oct 10 2008, 09:22 AM) Matlab has a function that will tell you the size of the largest 10 contiguous blocks of free memory. You cannot have a single variable that is larger than your largest contiguous memory block. I assume it must be getting this memory from some Windows DLL call (although I don't know which one). If you could duplicate these system calls in LV, you might be able to get what you need.