ShaunR

QUOTE (angel_22 @ May 22 2009, 02:51 AM) Sorry. I don't have DSC installed and I havn't used it for a quite a while. Someone else will have to help you with this. QUOTE (jcarmody @ May 22 2009, 07:56 PM) This reminds me of my Senior year in High School when my Electronics lab partner told me to "hurry up and fix it, I want to get this done." lol. He was obviously a manager in the making

1. Is the PIC on an evaluation board or have you built the board yourself? (I hope its the former!!!!) 2. Has your PIC got software in it? (You have to program a PIC to use its USART and there are plenty of examples of this on the net) 3. If you are using an evaluation board, have you successfully downloaded a program/example with the tools that came with the board.? If you are at No.3 then (and only then) you can start thinking about Labview. You will then be able to use VISA to open the Com port and write/read the command strings/data using the settings from the example and you should be good to go.

You can also write headers and footers in one hit.

QUOTE (rahul @ May 21 2009, 05:56 AM) We had a lot of problems with firewire (including what you are seeing as well as cards not allowing windows to boot and having to use a hack to get more than 100Mb/s which only worked sometimes between boots). So much so that we now use GigE (much better) It's only some windows installations that are problematic and (I'm afraid) we did not find any solutions.

I've got one of these that I wrote before we had the spreadsheet vi's. You don't need that many. Just pre-process with a for loop (to give the page and you can check the dimensions to bypass) and use the build array just before you save to to append/prepend a header and footer (your description can be part of the header or footer or you can have a separate one). Then just wrap that as a poly vi for your different types. You can also do things like checking that the file exists and only writing the header if its a new one and appending instead of overwriting so you can use it as a logger (don't forget an override switch though . I actually prefer to save different "pages" to separate files as you can load each one up as a separate sheet and it makes graphing and things easier.

Subpanels. Example in the usual place.

QUOTE (SLearner85 @ May 20 2009, 05:52 AM) No...... But your hard disk can. There is an "examples" directory and if you have vision installed there will be examples in there.

QUOTE (angel_22 @ May 19 2009, 07:51 PM) \LabVIEW 8.6\examples\general\templates\Dialog using events\Login Dialog.llb

QUOTE (angel_22 @ May 19 2009, 02:46 PM) lol.Some of us have to work for a living! As Asbo said. there's an example. Your UI is comming along nicely. You obviously have an artistic flair which I severely lack. Is this software actually going to control anything? Or is it a proof of concept?

QUOTE (Gavin Burnell @ May 19 2009, 04:57 PM) This is exactly what I was trying (rather failing) to describe on the "Exterfaces" thread.

You could do all that, but it might be easier to use use the "Overlay" functions in the "Vision Utilities" library.

QUOTE (keat007 @ May 18 2009, 01:14 AM) Indeed. The USART is just a communications interface to the microcontroller to talk to other devices like a bluetooth or PC. Nearly all modern microcontrollers come with at least 1 (usually used for programming it) and many come with 2 or 3. With a USART (which has digital voltage levels) , you can wire directly to other comms chips to provide your microcontroller with virtually nay interface you desire (bluetooth, USB, RS485, RS232, WIFI etc). The "Stamp" is just another flavour of microcontroller (from what I can tell) like a PIC or ARM. The only problem with the Stamp is it only has digital IO and you need to measure an analogue signal. You can (as you pointed out) add additional hardware to convert the analogue signal into a digital one, but I see that as doing it the hard way As my Toothpic is on its way I decided to look at the software for programming it. You can download a free toolset but I think what will be of more interest to you is that they have existing firmware for acquisition. I think if your looking to get up and running quickly and not too bothered if you use Labview or not, then it might be worth reading this. Looks like the server is in the bluetooth device (ike a webserver) so data can be viewed on anything from a PC to a mobile phone. http://www.flexipanel.com/Docs/DARC-II%20DS382.pdf' rel='nofollow' target="_blank">DARC II Oh. they ship to Singapore from that link I gave you

QUOTE (Tubi @ May 17 2009, 10:25 PM) This time, it's because you don't have enough samples to begin with to do the measurement. When you run at 20Hz, you generate enough data for about 2 cycles. With the limits set tightly, this is just enough threshold transitions to do the measurement. At 3Hz you are only generating about 1/4 cycle to begin with. So no matter what you set the thresholds to be, you will never have enough transitions to make the analysis. I have adjusted your signals to give enough data for the measurement @ 3Hz. See attached. http://lavag.org/old_files/post-15232-1242599891.vi'>Download File:post-15232-1242599891.vi

QUOTE (keat007 @ May 17 2009, 02:25 PM) There are examples of acquiring via bluetooth in the Labview examples.

Just hunting around on google (wonderful tool) and found this. Tooth PIC It would be ideal for your app and cheaper than bolting together all the different components your intending to use. You only have a short time to develop. So I would suggest not faffing around trying to get different modules to work together and go for a one-box solution.

QUOTE (keat007 @ May 17 2009, 06:14 AM) Not quite sure what your asking here. You need to get your voltage measurement into a form that can be output to your bluetooth module.. For that you will need an analogue input of some description and an interface to your bluetooth module - A U(S)ART. I've just been looking up the "StampII" and it seems it doesn't have an analogue input. It seems that these "Stamps" have a UART already so you can connect it to your bluetooth directly anyway. (people seem to be using them a lot for Boebots and controlling them using PDA's etc). But I'm afraid, if it doesn't have an analogue input, you cannot measure a voltage (easily). You can have an RC circuit and measure pules to try and make a rudimentry A2D converter, but I wouldn't recommend it for a medical application. So your issue doesn't seem to be Labview. Its that your hardware can't measure voltage. This is what others say about measuring voltages with a "Stamp" and they basically say that you need something else (like a PIC). http://www.zonerocket.com/Voltage-checker-for-Basic-Stamp-II-robot-project-article5144--2.htm' rel='nofollow' target="_blank">Voltage Checker For Basic Stamp

It's very easy to use bluetooth with Labview. There are a few examples in the examples directory. I would suggest a PIC to aquire the data and interface via its UART to your Bluetooth transmitter and you can use Labview to receive and chart/graph/analyse the data on a PC with your dongle.. A PIC is small, and cheap but requires C knowledge (probably cost you about £5-£10 to build) but have UARTS, and several analogue and digital inputs - more than enough for your task. It would also be very portable and could be battery powered (matchbox size?). If you go for labview for the acquisition then you will require another PC to run the labview run-time with some sort of compatible acquisition device, or something like cRIO, fieldpoint etc which can run labview (which are really overkill and expensive).

QUOTE (crelf @ May 16 2009, 07:16 PM) I don't see them in the main top level pallets either . But if you access them through the 7.x, they are in the main pallets there.

Another method which is very effective is to look at a line of pixels (line profile) and look at the rate of change at edges. If you are in-focus and looking at series of lines and spaces you will get sharp peaks which become much flatter and rounded as you go out of focus. A simple d/dx will give you the rate of change.

QUOTE (Daklu @ May 15 2009, 08:45 PM) Theres also one in the examples directory It just confused me at first because I expected everything you have under exterfaces for the agilent to be in the same place as the Device drivers. And a "thin" wrapper under the exterfaces like the others. But looking closer, your ACE and BAM ect are really simulators???? QUOTE (Daklu @ May 15 2009, 08:45 PM) Yes, but that is typically just a matter of downloading and installing them. No coding required. Hmmm. Wasn't the case for the agilent. I think even if it was an active X component you would still have to write some wrappers. Be nice if it was like that though. Download and install just like a video driver in windows etc. QUOTE (Daklu @ May 15 2009, 08:45 PM) Yeah, if I had to derive 20 child classes containing essentially the same code every three months exterfaces would get old really quick--regardless of how thin and light they are. I'm really curious what kind of testing you're doing that contains so many instruments used for such a short time. It sounds like a fairly chaotic environment. I also think it would be interesting if you did a white paper and sample project. Share the knowledge so we're not all reinventing the same thing. I think I referred to the current one on the Q's thread. If your really interested I'll take some pictures of it on Monday and PM them to you. Generally they are production inspection/test machines that have all sorts of measurements for inspecting things like turbo bushes, gudgeon pins, train brake valves. So they can have bowl feeders, motors, measurement probes, micrometers, laser distance meters, cameras and all sorts. We might get an order for a couple at most, but they are custom built to spec for specific production lines of our customers. Don't mind sharing, but write a paper? I wouldn't know where to start QUOTE (Daklu @ May 15 2009, 08:45 PM) Question: As Shoneill pointed out, exterfaces and polyconfigurism are different solutions for slightly different problems. Is there a way to combine them and gain the advantages of both? Off the top of my head I think it would just unnecessarily complicate things, but maybe you can think of something. Well. this is why I'm still in the thread. I think it can be done. Although I'm still looking for the elegant angle and a way to slowly introduce it rather than throw everything out the window and start again since time constraints would make this impossible (if its not broke....don't fix it). The way I'm looking at it is this. At the "mid" layer we both arrive at the same point, where the functional abstraction is realised and the underlying interfacing mechanics is transparent (although via different means). I'm loath to switch to classes because I can see a lot of work in maintaining the abstraction from project to project which I currently don't have. But. The sorts of tests/inspections are pretty much constant (once you've measured one tubular piece of metals' diameter the method works for all tubular pieces of metal which is basically what a gudgeon pin or turbo bush is). Its only the hardware that changes (bigger/smaller/more motors, more/less accurate micrometers electrical instead of air etc). So my "Top" is fairly constant" but my "bottom" is fat fluid. Your "Top" is fluid, but your "bottom" is constant. But in the middle (where your exterfaces sit as I see it). We have the same goal. What I do have from project to project at present is a constantly changing "mid" layer where the glue between top and bottom could be a lot better and I haven't so far found an elegant solution for this. QUOTE (Daklu @ May 15 2009, 08:45 PM) LUT? Look Up Table. ------------------------------ P.S. If your going to use the word "Polyconfigurism" then i'm going to call your "exterfaces" "Midglue"

Well. You don't have much for us to go on. In your temp vi, you don't really need 2 loops but it a long, long way from being able to manage a greenhouse. Did you take a look at the example in the examples directory. I think your lecturer might be looking for something like that for a remote monitoring system. In your other VI its not really defined what you want to do? Is there a temperature and humidity control for each crop? Or will it tell the greengrocer how much the seeds are.

QUOTE (Daklu @ May 15 2009, 02:20 AM) Well. If it's a dll driver we won't use it as its not cross platform, so it wouldn't be considered at the Systems Design Stage. The NI one is interesting, I haven't come across that before and at a first glance I'd say it is in the 10% area. QUOTE (Daklu @ May 15 2009, 02:20 AM) I also still don't understand how you have one read function work for different instruments. Suppose (for example) you're measuring peak-to-peak voltages on an oscilloscope. What if one scope returns the value in volts and another returns the value as the number of divisions and requires you to calculate the voltage? Haven't come accross one of those in a long time. The table I was describing can have a formatting string for the read and write. But I havn't had to use that feature in along while and I'm not even sure I can remember the syntax off hand QUOTE (Daklu @ May 15 2009, 02:20 AM) Sort of. Your interface definition defines the higher level functions. The exterface implements the higher level functions for each instrument that you want to use for those higher level functions. So you do have to wrap more than one piece of code... unless all your instruments use string based commands, then you can probably use polyconfigurism and a single vi. Woohooo. Thats what I was thinking. QUOTE (Daklu @ May 15 2009, 02:20 AM) I'm not sure we're on the same page here yet. The 34401 code I added is an exterface, not a device driver. You would still need the 34401 device driver from agilent to get the exterface to work. That IS the device driver from Agilent. You don't need anything else. QUOTE (Daklu @ May 15 2009, 02:20 AM) Except since my interface definitions are on the project level, it's no big deal to add "Personal Servant.vi" to what I already have. I don't have to worry about coding for exceptions that may occur in future applications or maintaining compatibility with previously deployed applications that use the interface. I just have to worry about making it work in this application. And adding the drivers I think I get the picture. You have a small set of instruments that don't change much (might be adding one every six months maybe). Whereas once you have your 3 instruments, you are pretty much done with the drivers and everything else is just using them or building on what you have already I have the difficulty that I may have 20 instruments on that project and will never see those instruments again, and there will be another 20 different ones in 3 months time on the next project. Like I think you pointed out. Its the difference between engineering tools and product.

QUOTE (shoneill @ May 15 2009, 08:20 AM) Not quite. We use DIO and AIO, but they sit on the RS485 or TCPIP bus. I suppose its the difference between being able to spec the instruments and just being handed them and have to deal with it. But they will be from different manufactures and have different command sets from project to project. And were not just talking 1 or 2 instruments per project here. Were talking between 10 and 30. QUOTE (shoneill @ May 15 2009, 08:20 AM) Exactly. One implementation is INDEPENDENT of the protocols used with the instrument(s) whereas the other is not. Ummmm . as far as I can tell they are both independent. There still has to be a way of explaining to the instruments what you want them to do in their own language regardless if it is a class or not. In OOP you create a class based around the common functions in the drivers, and that class (the Agilent, ACE or BAM Class for example) has the specifics for that instrument with a unified set of properties and methods (Configure, Read, Write set this, set that for example). You may have "inherited" and overridden a base class of "instrument", but the commands sets still have to be implemented for every instrument and function that you support. It's not until you abstract the function (like Configure) that every "Driver" has in its methods list that you get the independence. The file example does it a little bit differently but the upper layers of the software are the same as your describing. It doesn't care what the instrument is, or what functions the instrument supports. It's a scripting utility that (almost) blindly reads the file and squirts out the contents over an interface. And that interface can be any hardware platform you choose to support. The file defines what is and isn't sent , what the protocol/command set is and (as you've probably seen by the filenames) the target device(s). At the upper levels of the software, you have your configure, read and write as you would in classes, but you don't have to worry about creating the Agilent, BAM and ACE classes and exposing all the properties and methods. Just a file. This means if I replace the BAM, ACE or Agilient with a Keithly,, I just add a file to configure it and no software changes. Choosing which file, switches from one to another (on the fly if necessary). But his isn't about my "old" file thingy. this is about exterfaces. The merit I see in Daklus implementation (which I think we agree on) is not at the driver level, its at the function level where we both sit, files and classes alike. QUOTE (shoneill @ May 15 2009, 08:20 AM) With LVOOP ALL protocol-specific information and code is encapsulated within the class. With LVOOP I can release plug-in modules which will work seamlessly with the parent VI without having to change a bit of code in the parent VI. This is post-release flexibility which can be pretty cool. Shane. Ditto. Only I don't have to change the plugin either See above.

QUOTE (Tubi @ May 15 2009, 01:49 PM) Well the latest example you supplied seems to work fine. I changed the variables on the front panel and it didn't complain. Are you saying that it works in simulation but not on the hardware? If this is the case. It might be useful to capture the data from the machine to a file and run that through the simulation. Then w can all see and investigate the differences.

Sorry Shoneil. We must have been posting simultaneously and I didn't see your post. QUOTE (shoneill @ May 14 2009, 09:32 AM) Actually, its instrument independent. And "hopefully" your instruments have a pre-defined protocol otherwise it really shouldn't be on the market. The idea is not to replace Daklus approach. It's a way I've used over and over again on many projects with many comapnies with many different instruments to alleviate the "Driver Wrapping" which I always see as the ball-ache of not only classes, but programming in general around instruments. It's just a very quick way of incorporating an instrument and configuring it with a minimal amount of coding and total re-use. QUOTE (shoneill @ May 14 2009, 09:32 AM) I have also realised a LVOOP driver for a spectrometer which, while it has a LVOOP Backend running in a parallel process provides an interface via User Events. A spectrometer is pretty much like any other so defining the classes was not too hard. In order to incorporate a new Spectrometer I simply create a new class and feed this into my background process (which thanks to LVOOP runs with the new class without any code changes). Daklu's Idea takes this a step further. If I have understood correctly, you do something similar but then provide a way for broadcasting which Interfaces are available for a device. So I could have my Spectrometer servicing both a Spectrometer and a Colorimeter and a Temperature sensor interface. Is that correct? Is that the idea behind the examples posted? I have to confess I've read the document but not tried out the code. In addition I could jerry-rig a filter wheel (RS-232), a monochromator (GPIB) and a Photomultiplier (DAQ) together to create an Interface for a Spectrometer using three different devices witht hree different protocols. My top-level software doesn't care, it just calls the "Get Spectrum" method and (after a little while for a scanning spectrometer) delivers the data. This is what I see too. The abstraction can be a functional abstraction of the task rather than abstraction of the devices.