Syd Chasm

Yep, I'd do the same. Create an instance of a class for each valve, with methods for valve open and valve close, and properties of "valve open" and "valve closed". I've done a similar thing before - the only added complication being that some of my valves were normally open and some were normally closed, so I had to have a different class for each valve type. My valves had limit switches, so I could easily tell when they were open and when they were closed, and a transition time of about 2 seconds to go from one state to another so I could build in a time-out error in the method so that if it took longer than 4 secs from commanding a change of state to the limit switch confirming the action, I could report an error. If you have gauges downstream of each valve, you may be able to use a change in pressure to detect valve failure (I'm guessing that there is a venturi downstream of each valve, and a gauge measuring the vac pressure?). Syd

Hmm. My girlfriend of the moment is a vegemite devouring Aussie-chic. I now feel compelled to check her chest for hersuiteness (is that a real word?). A long exposure to living in the UK has, I confess, left me with occassional marmite cravings and I have found myself reduced to raiding Sally's vegemite pot for midnight feasts and I got to say that the Aussie version lacks the sophisticated tang of that from England's Green and Pleasant Land. But at least you chaps have evolved enough to have a taste for yeast-extract derived products with the texture of Meconium, which is more than can be said for our cousins across the pond. Tally Ho, gallant knights, I'm mincing off for a spot of tea. Syd

Hi Phil. I started out interfacing Labview to PLC's when the Bridgeview package was still around - all this really was was labview with an OPC interface added to the toolbox. With Labview 8's OPC interface, you can access data from your PLC without any additional toolboxes provided that you have an OPC client running somewhere on your network (for example, RSLinx if you're using A-B PLC's) - the only real additional benefit that you'll get from using DSC/Lookout are some animated graphics of pumps and vessels and some pre-written alarm management vi's (which were not very good quality in the days of Bridgeview, I have not opted for DSC for a long while now so I don't know how much added functionality there is). Having said all of that, my view is that Labview beats the pants off of SCADA packages like Wonderware and Intellution FIX DMACS in terms of programmability and flexibility, and I would certainly go for a Labview development environment to interface to a PLC everytime. It may well be worth looking into using Fieldpoint real time rather than a PLC depending upon your application. If there is a strong safety critical element, then a PLC is still the better option because you can opt for multiple redundancy, SIL ratings and even ATEX-ratings if needed. The fact that Fieldpoint Real Time gives you an OS independant of windows has gone a long way towards making it a competitive technology with PLC's, but as the market stands today a properly engineered PLC system will still have a much lower failure rate than what you can achieve with a PAC. That said, I have found applications where Fieldpoint real time was a batter option because I could code some high bandwidth multi-variable controllers in Labview real time that would have simply been impossible with a PLC - it comes down to the sophistication of G against the languages available to PLC programmers, as well as the instrumentation heritage of NI products in terms of fast data acquistion. I guess that your optimal choice of technology is strongly dependant upon your application - if it's a simple SCADA with a couple of screens of operator GUI and a simple alarm handler, then I'd say use FIX or Wonderware as this is well within their limited functionality. If you're looking to do some clever supervisory or statistical control with calculations & data passing between the client PLC's, or if you're looking to interact with a database using SQL, or automatically populate Word or Excel reports, then Labview will pay for itself very quickly. Would be interested to hear if other developers share my views on this! Good Luck, Syd (ps - you can also use third party drivers to talk to your PLC's - e.g. http://www.softwaretoolbox.com have some decent products. Also, beware of using serial comms as the update time via OPC can be very slow. Ethercat, Fieldbus or DH+ will give you faster updates).

Bonjour, mon ami! I have had the same issue in the past where I needed some fast sampling for some channels, and slower rates for other channels. I was using 6020E series cards, which have only 1 on-board timer. In my case, I needed to sample 80 odd channels at 1Khz, and another 50 at .5 Hz continuously for test runs of 90 minutes duration. I got around it by using separate cards for the high speed and low speed acquisitions - you can alternatively use a card that has one timer per channel, that allow you to sample each channel at a different rate simultaneously, but these are expensive. In your case, given that one of your rates is EXTREMELY slow (1/10 mins), I would be tempted to use a while loop to count the 10 minutes and execute a single multi-channel read every 10 minutes, during which time you would suspend the triggered DAQ task. I'm assuming that it doesn't matter too much if the samples are taken at 10 minutes plus or minus a few seconds? It's not very elegant to use the windows timer to control your sampling rate, but for such a slow rate you should be OK. I hope this is clear - if you're really stuck I could put together some sample code to show you what I mean? Au revoir et Bonne Chance, Syd

Hi Guys & Gals, I've joined the forum today, and thought I'd say "Hi". It looks from the map that I'm the only member from Dubai - this is not very surprising as the only Labview users out here are the college where I lecture and another University in Sharjah! If there is anyone else out there developing in Labview in the Arabian Gulf, it'd be great to hear from you! I'm a Mechatronic Engineer, and served my time mainly in the UK developing some pretty huge test systems for the automotive & aerospace industries - the most exciting being a suite of facilities for the McLaren Formula 1 team that included a wind tunnel, a dynamometer and a gearbox test facility. Very fast sampling rates, and VERY high bandwidth control algorithms (my first experience of using labview real-time). I've been in Dubai for 2 years now, teaching Mechatronics at the Higher Colleges of Technology (Note - if there are any of you out there with a masters or doctorate in Mechanical/Electrical/Electronic engineering with some teaching experience, we are struggling to find faculty out here!! Drop me a message if you're interested!). I teach programming to our undergrads, and we use Labview quite extensively for project work. Currently, I'm running projects on alternative energy (a solar distillation system with a Labview DAQ system) and a Mini-Baja that we're entering into the Society of Automotive Engineer's competition in Pretoria next year (we're instrumenting that, too, and using Labview/MATLAB to optimise our design). I'm looking forward to keeping up with the latest developments in the Test & Measurement industry - I'm looking to return to working in the Industry and relocate somewhere with a better developed hi-tech industry at the end of the next semester. I'd be grateful for any leads! See all you lava lounge lizards soon! Syd Chasm