PeterB

I am running 7.1.1, if you have got it working then maybe v 8.0.1 doesn't require the offset to be simultaneously set as Biren suggests. Anyway, I updated the examples and they now run for me under v7.1.1 but with some interesting behaviour as noted in the reply here . regards Peter

This suggestion doesn't work because once a (timed) while loop is finished executing, the only way you can get it to run again is to place it within another while or for loop (as i2dx suggested). regards Peter

Hmmm.... well adding the offset in gets me a step closer, but I must say that I could find NO evidence of needing to do this in any example (could you list the specific example Biren?) nor in any of the LV Help literature. Moving on however, when I did add the mode on the RHS datanode (see attachment Timed Loop Test v0.1.2.vi), and select a new mode, the loop dt goes from 1000ms to 0mS ! i.e. it iterates VERY fast, and because timed loops are high priority, the vi takes a while to recognise any stop buttons on the FP. OK admittedly I have no code in the timed loop to actually consume additional CPU clock cycles, but this behaviour is rather weird. So while adding in the offset did answer my original question, it highlights a new unexplained behaviour. Moving on to a more real life example, check out the next vi "Timed_Loop_Test_v0.2.1.vi". The delay being called inside this timed loop is programmed to finish late every 4th iteration. Now run it, then simply change the "Subsequent Mode" from 'No Change" to "Process missed periods, maintain original phase" and the Expected Start and End times drop down to 0 and 500ms respectively ! Rather weird. regards Peter Download File:post-1272-1142469841.vi Download File:post-1272-1142469854.vi

Hi there, while running a timed loop I would like to change its mode by wiring a mode enum control into the RHS data node of the Timed Loop. The Timed Loop does not seem to change its behaviour (let alone report the new mode) when I do this. Any ideas why? thanks Peter Badcock Product Development ResMed Ltd. Download File:post-1272-1142390859.vi Download File:post-1272-1142390871.vi

Hi folks, a colleague of mine at work (Vito) has recently risen to the challenge of becoming a wire worker. He is applying his new found skills to a medium sized LV project. During his exposure to charts and graphs in LabVIEW, he decided that he liked some features of the XY graph, but quickly became aware of the performance hit for a large number of points (1000) and/or a fast update rate (50Hz). Being unable to find any definitive figures showing the (relatively slower) performance of graphs compared to charts, he decided to perform the testing himself. To this end, I am uploading the details of his testing and results. A screen shot of the MS word document is attached (showing one of the BDs used), along with the example vis used. Timing details were measured using the VI profiler built into LabVIEW. regards Peter Download File:post-1272-1139468483.vi Download File:post-1272-1139468497.vi Download File:post-1272-1139468510.vi

G'day Chris, New Year's day in Sydney reached 44.2degC (111.6degF) , and today is predicted to be 36degC where I live in the north west of Sydney. Sydney Temperatures for Jan 2006 Apparently 2005 was the 'hottest' year on record in Sydney (since official records began). The good thing is that despite the hotter weather, we've been having a lot more of the needed rain to break the drought in eastern OZ and fill up our dams. cheers Peter

Hi Didier, thanks for your observations. I was able to fix it up by opening the control editor, selecting 'Show parts window' and changing the X-axis properties as shown in the attached screen shot (so that Left=113 and Width=462). I do remember a while ago that I had this chart opened in the control editor, and it is possible that I resized the plot area without resizing the x-scale. So thanks for your vote of confidence in my experience, but I think I'll put this one down to a silly mistake on my part. FWIW, without the parts window, it is impossible to resize this x-axis using the "Set Width and Height..." toolbar button on the FP regards Peter

Hi there fellow wireworkers, I have had this problem for a while with a few of my charts and I don't know how it happens, let alone how to fix it. The attached picture and exaple vi front panel should say it all, but just in case, look at the x-axis. The far L.H.S. tick mark at time=201.319 should be aligned with the y-axis. Charts do not save default data, so the attached vi will open up with LHS tick time=0.0. I am using LV v7.1.1 under W2K. regards Peter Download File:post-1272-1136790980.vi

Please refer to the following post on Info-LabVIEW for the discussion thread Title : "RE: LabVIEW is very slow to find my VISA (DAQmx) channel resource" Posted: 2nd November 2005 at 4:52PM (AEDST) http://messages.info-labview.org/2005/11/02/14.html thankyou regards Peter Badcock Certified LabVIEW Developer Product Development ResMed Ltd. Download File:post-1272-1130909877.vi

G'day fellow wire workers, where I work, we own a few of these nifty Breathing Simulators: http://www.ingmarmed.com/asl5000.htm In the process of customising their operation I will be integrating some external feedback modelling previously developed in a language called VisSim. VisSim does have a rather archaic and clunky user interface, but at the time the lung models were written, LabVIEW really only had the GSim toolit to offer (GSim could do the job, but this kind of modelling was VisSim's forte and plus the person involved probably didn't look too hard into the GSim option at the time). After much discussion, my proposal was to write a LabVIEW ActiveX server which could be called up from VisSim thus allowing easier upgrade paths for the lung models, while also retaining the existing look and feel of the VisSim GUIs. This post is to share a learning experience with you in the world of ActiveX servers, just in case you ever have to take a similar journey and plus, I simply could not find any worked examples on any of my usual LabVIEW search sites (Searchview, ni.com etc). It's also possible that by reading the LabVIEW user manuals (which I surely did!), others may say "well that was obvious", but to me it wasn't - so here goes. I assumed that the ActiveX server would allocate memory for its output parameters, however it is necessary to reserve space on the input side at the client level. It took me about 2 days to nut this one out. As reiterated recently on Info-LabVIEW, a Picture/LabVIEW diagram is worth 1000 words so I'll let you look at it and see if it's how you would have done it. Maybe I could forego all the variant conversions, but at least I got rid of all the coercion dots. If anyone can show me where the manual mentions having to reserve memory please let me know (without referring to all the VB , .NET or Visual C examples, 'cause I'm a LV diehard!!) One other thing I wanted to try was to see which method is faster for transferring data "Call2" or {setcontrolvalue,run,Getcontrolvalue}. I'll post back my results after testing the relative speeds. Anyway, knowing that this now works for me in principle, it should hopefully be easy to call an ActiveX server I write in LV from VisSim. regards Peter Badcock Validation Engineer Certified LabVIEW Developer Product Development ResMed Ltd.

I had to find a solution to this problem a few months ago, I can't remember where I got the idea from , although someone may recognise it (apologies for not giving due credit). The solution attached uses one event structure and works even when the mouse is released and not over the control. The particular solution allows you to read the control value as it is changing, and latch it when the mouse is released. When the user puts the mouse down on the control, you dynamically register a mouse up event for any further 'mouse ups' on that vi. As the user slides the value around, the control value changes, but not until they release the mouse does the final value get propogated (to another indicator etc.) regards Peter Badcock Download File:post-1272-1108693723.llb