ShaunR

Here Ya Go. This'll put am sms into your unread box. You just need to send it then. This site is useful for common commands

We have Guidelines? Wow. Now having read them I thought it might be an idea to explain the "Rep System" under "Spread the Love".

I'm not over-enthusiastic about notifiers (after my initial enthusiasm in seeing the potential). They could have been fantastic for my everyday use but for one caveat. You actually have to be waiting for it to register the notification. You can't (for example) send a notification and when the wait executes, it continues and removes it from the notifier. It will just wait. This behaviour is no good for asynchronous systems since you cannot guarantee that a notifier will be waiting when you send the message. Wait with history doesn't cut it either since the wait will execute multiple times. So you end up synchronising the systems manually to ensure the wait is always executed first, which defeats the object.

Knarly one. You don't get this problem if you acquire a reference before waiting by the way.

Fat chance. I'm afraid of scripting remember

I feel your pain. But why limit it to classes?. Why not also be able to apply it to a load of VIs in a virtual folder. Or be able to select multiple VIs that you want to apply it too.

Talk to your sales rep or contact the regional office National Instruments Asean

That's what we're here for

What is it? What does it do and what is it for?

Well. You've already run into one on the major problems (race conditions) otherwise you wouldn't have had to use semaphores. You wouldn't need to do that if you'd used (say) a functional global. Another issue is that global variables significantly complicate debugging especially for people not as familiar with the code as you are. You, as the developer, know every inch of your code and can probably tell by the symptoms where bug is probably hiding. I, as someone not as familiar, just see a sea of globals in many sub VIs (could be hundreds). Where do I put my probes? I cannot probe the global itself (Unlike a functional global). The original argument for globals being bad practice was that they break the data-flow paradigm of labVew. Now that LabVvew is being promoted as an OOP language, this is a bit moot. But it isn't just labvVew where it is perceived as bad practice. Most languages suggest that local variable scope is the preferable solution. However. I can think of 1 or 2 situations where I would go against the flow and use a global variable. I'm sure others will chime in with their thoughts, but I would guess they are not supportive of global variables.

Labview can easily write to serial devices. You don't need anything other than Labview itself. The product you are interested in also has Labview drivers (and examples) which are downloadable here from the manufacturer.

Sweet. Press the green plus "+" on the right of my post. As you are using TCPIP to transmit your data. You might want to take a look at dispatcher.

No (or is it yes?). You are correct. It's not functionally identical. But the OP was struggling with some very basic concepts and I didn't want to cloud the issue when his next step was to remove it anyway (he never got that far ). I also wanted to give some credit where credit was due. Indeed. But an on/off controler doesn't do that in response to how near or far away from the setpoint we are. Its a bit like having On/Off brakes in your car. It doesn't make for a very smooth journey. An averaging PWM output (where we are trying to simulate a voltage level) typically runs at about 20-40 KHz. The lower the frequency the "choppier" the output. Why 20-40KHz? Because that is higher than the frequency response of most analogue inputs to give a stable reading (read DVMs which is about 20Hz-20 Khz) . And that is due to the input filtering of the analogue device . But we didn''t have the hardware to do that and we cannot run our loop fast enough (or accurately enough) to do it in software (without a real-time OS). But do we really need to? Well. for long lag systems no. A long lag system may have a frequency response anywhere between 0.1 or and 0.0001 HZ. That we can achieve in software. We can run our PWM at very low frequencies. And it works very well. So the answer to your "then what?" is A. "you turn on the output for 30s, turn it off for 30s, then run the PID again". In the example you will only get reasonable control if the response of the system is more than 10 mins (preferably more). But it will be far superior to the an on/off controller. Now the interesting part is that when you characterise a system to find the PID parameters. Because it is a closed loops system, Your control method becomes part of the system (regardless if its digital or analogue). So the PID algorithm is not only trying to predict the behaviour of the target system, but the target system AND the control. This is why I was taking you to task on your statement that PID is for analogue devices. It isn't. It's a predictive algorithm. Nothing more. We could use (and I have used) a bi-section algorithm just as easily.

Indeed. It confirms my suspicion that I'm really not as stupid as I look Can't argue with that. Readability over elegance (no performance hit). But in contrast to your previous statement. computers definitely don't think like me.

Yes. That is because it is in fact a single reference (something I always hated about the vision stuff but I guess a necessary evil). So we really need to use something that makes a copy of the image and transmits that rather than the reference But we cannot use the conversion to an array because you cannot open it (is that right?) Try changing the standard flatten to string to the IMAQ one.

Yup. that's my solution too. Except I just used the value d92 instead of a cast

Do people still use that?

OK. so really we are just talking performance here. So with this as the seed. What's the execution time?

2009. I just get a hyperlink. But I'm beyond caring now .

And how do I do that?.

upload it then

Well.The intention of IVI was to do exactly what you are describing transparently, but you've found the weakness in the plan Its a good idea (note I say idea because I'm all for interchangeable drivers) as long as your all manufacturers do it (which they don't). But the real killer is you can only create them in CVI (that I'm aware of). So the "proper answer" is to take your current drivers and turn them into IVI drivers. But that's no good to real people. I would take a look at Transport.lvlib (you will need to unlock the library to see the guts). It won't help directly, but it will show how I resolved the same problem for for TCPIP, UDP, Bluetooth refs. You will be able to use the same technique to transparently switch between the two systems..(But the age old addage applies....."If it ain't broke, don't fix it!" ) Yes.]

Thanks I'll look into it. I noticed I didn't address your other observation. I expect you read the note in the diagram of the FG. I too am not happy with it (apart from just being a mess ). Mainly because It currently is not only used for storage, but also to relay disconnects and close connections. This needs to change so as to separate the roles (its a legacy from a previous incarnation). I have to come back to it for the addition of other features and I'm still deciding on the best approach at the moment.

Interesting. What version of LV and OS are you using? .It was tested on 3 machines using LV 32 & 64 on win7 and vista (I don't have XP or a linux licence). And everything seemed fine. But as it HAS happened, I'll include your suggestion with the next release. Thanks for persevering