ShaunR

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

And our rep-point winner is! Nope. None. And I tried all bits on (almost) every object

Mainly load balancing and performance. The performance is dictated by the computers resources rather than the dispatcher. With the filtered method you have a congestion point that affects ALL "Topics" and gets worse by a factor of subscribers x topics as you add more topics. Lets say (for example) you are sending 100MB of data on 1 topic which takes (say 10 ms) to transmit to 1 subscriber (we'll ignore filtering overhead). The Dispatcher is able to service all subscribers to that topic every 10ms. If we now add a subscriber to that topic. The time to service all subscribers is now 20 ms. 3 subscribers...30 and so-on. Now we add another topic that also takes 10ms to tx 100MB of data to 3 more subscribers (keep the maths easy). The time now required to service all 6 subscribers on both topics is now 60 ms. 3 Topics, 90ms....... However. with the service handler, each service handler is only handling 3 subscribers so in our theoretical example, each handler is servicing all 3 of the subscribers every 30 ms still. Increasing the number of topics doesn't change the time to service all clients. So whereas before the time to service all subscribers was a compound of the number of subscribers AND topics. Now it is only the number of subscribers. Additionally, whilst the dispatcher is servicing the clients, it is effectively "deaf" to incoming connections which also gets worse as you increase topics and subscribers. Having the dispatcher only handle connections means that this "deaf" time is not dependent on the number of subs/pubs. You can use a queue as, I have, and build a list of connection request but you then have to consider the trade off between handling data or handling a connection request. With significant network lag you can get halts in the data whilst the dispatcher is creating a connection. In my example, the Dispatcher only handles connections (its very responsive to connection requests). Therefore the dispatcher can take as long as is necessary without interrupting the data streams.

Yes you are right. Apart from adding the "Dispose" I also removed the conversion from an image to an array (and visa versa) as I indicated in my previous post. Although I don't think it will solve your problem (but we can hope )

Sweet. I'll take a look! Indeed. That's where the "Disp Service Handler.vi" comes in. This dispatcher uses a similar method to a web server where each incoming connection is negotiated to a different port and a process is spawned to handle that client. However. This spawning only happens for the Publishers. If you look in the Registration part of the Dispatcher you will see I dynamically launch the service handler (whos front panel is hidden). The publisher writes to the service handler, not the clients and the handler deals out the data to the clients. There is a service handler for each publisher and when a subscriber wishes to connect, the Dispatcher sends a new subscriber list to the handler for that service.

Indeed. Also If you cut and then paste back again, it will reveal the terminals. 'twas just an idle moment whilst rummaging around the script stuff. But in doing so I did find also that using this "feature" I could remove the thick border around terminals and variables which was one of requests from the idea exchange.

It's difficult to say why. But as NI have reported this as a bug in 8.5 for loading vi's saved to a previous version then its likely to be the case. As you were able to load it the first time.I would suggest you over-write the vi from the zip. Then reboot to make sure memory is clean, and open the VIs again. You should now be in the same position as when you downloaded the file originally (hopefully). If you are able to load the VI again, save it to a different location so that it is not a "converted" vi. Hopefully by doing this whatever the issue is with loading converted VIs will be removed. I have also posted the VIs diagrams below (they aren't difficult). It would only take a few minutes to re-write them.

x86 32-bit or 64-bit? I have both installed under win7 64-bit. It takes about 15seconds just to launch 32-bit LV. About 5 seconds to launch 64-bit LV. Disk IO is particularly sluggish using WOW 64

You running LV x32 on a Win x64?

Sweet. Those old USB drivers should be taken off the NI site. I've just noticed I forgot to "Dispose" the IMAQ image reference. Not a big deal in this case but this is how memory leaks start.

I think you'll find that a way of handling Events was being called for for quite some time. Not necessarily an event structure but a way of handling UI events as all the other visual languages could.

Were a bit off topic. But I'm going to steam ahead anyway since I don't think it'll last long otherwise I would have started a new thread. We must have the same customers . Its pretty much what I get (initially). Only my approach is for me to write the spec over a series of sit-downs (hand-holding). That way I can include stuff in the spec that perhaps they hadn't considered, but important to their operational situation (back-up and data storage is a common one they overlook). It also means I get a very good picture of the customers "minds-eye" of what they expect the system to be like. I usually also try and get one of their technical people to be actively assigned to the project then you get out of a lot of the "status reporting" 'cos thats his job Your thoughts about what constitutes a change (and therforre the customer incurrsa cost) is identical to mine. However, you sneakily said "correctly working software", which, is normally the bit that starts arguments. And it needs to be extremely well defined right at the start of the project what and how testing will be done by both parties to ascertain its "correctness". I would go 1 further and say "correctly working system! I take the (some may think draconian) view if its not working "correctly" then its not completed and therefore not released to the customer (expecting customers to do alpha and beta testing is a cop-out). V1.0 is the first time a customer will get the system and Its very rare you will find an up-issue that is a bug-fix release in either software, hardware or mechanics.

Make sure that your camera is working properly in Measurement and automation explorer. It should auto-detect your camera and In the main window area you can press "Grab" to make sure you get an image. Use this for capture instead (I've saved a version in LV 9.0 and 8.5) This I can test an works fine (no flashing, fast frame-rate @ 640x480)