ShaunR

That's a bit like saying you shouldn't use the GetTickCount because it does not have error terminals. The main two arguments behind global variables is that they make debugging difficult and cause race conditions across vi boundaries as well as within a vi. The use of an error cluster or not is irrelevant (I think). If you mean a choice between a global variable or shared variables. Then in-line with the ant-globalisation (lol) posse then neither should be used since they are both global variables and this is a sin I agree. Ooops. No I don't Or maybe I do I agree I am never going to use a NPSV in a time critical loop (and by time critical I mean on a real-time NI system). And I agree (on a real-time NI system) I am "probably" going to use the SPSV. But I am not going to use either in normal LV unless I want easy network comms (well. not even then ....).

Yep. Mine runs on coffee

Reminds me of the Al Gore "hocky stick" graph. Are we also responsible for increased global warming since 2000?

I think you are all missing the point. The OP was questioning the difference between global variables and shared variables in a single process system. In fact. The argument against global variables is exactly the same for SV's (SV's are "SUPER global variables). SV's have a network feature and that is the only reason people (should?) use them (but they have limitations that make them unusable in some applications.). They were designed for real-time targets but moved over to mainstream labvVew as an "easy" network comms.

If you save it as a single precision float you will save 50%, you won't have to do integer scaling and you will have a much better approximation. Depends how much disk space is important. Apart from that I'm not really sure what you are asking here. The answer "show it on a graph" seems too simplistic.

All You Need To Know

+1 My bookmark points straight to the last 24hrs

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?