Jump to content

shoneill

Members
  • Content Count

    864
  • Joined

  • Last visited

  • Days Won

    25

Everything posted by shoneill

  1. QUOTE(george seifert @ Dec 10 2007, 08:30 PM) Funky artifacts? The only funky artifacts I see is the picture getting larger or smaller......... In both methods I listed? Shane.
  2. QUOTE(george seifert @ Dec 10 2007, 04:42 PM) Have you tried the "Zoom (Single)" item on the property node for the display? Setting a value of 0.66 will reduce the size by 1/3, setting 0.1 will reduce the size by factor 10. This is useful if you only want the displöay scaled, but leave the actual image untouched. To rescale the image itself, you can use the "IMAQ Resample" under the "Image Manipulation" palette. Shane.
  3. The fact that something used a certain subset of a typical programming technique doesn't automatically make it compatible. There ARE different techniques to OOP out there people. OOP has become such a sprawling, multi-interpretation term that it has become almost meaningless. One person interprets OOP as meaning this, others as that, others again as something completely different. A technique using encapsulation and abstraction but without inheritance per se (although it certainly is optional) is Component-based programming. I think this description fits much better than Object-oriented as the missing inheritance (almost universally thought of as being a key factor of object-oriented programming) is not required. Just my 2c. Shane.
  4. QUOTE(Aristos Queue @ Dec 9 2007, 08:37 AM) I really have to side with Aristos on this one. Encapsulation is one aspect of object-oriented programming, but simply using encapsulation doesn't make something object-oriented. I've been using encapsulation for years, but that is still a long way from proper OOP. Shane.
  5. QUOTE(Val Brown @ Aug 27 2007, 09:53 PM) It's phrasing is unfortunately referring to a piece of history which is disliked (pretty unanimously). It's quite insensitive to citizens of the respective country to bring this kind of thing into a post with the innuendo that it's representative of a bad thing. This aside: I've recently implemented a set of LVOOP VIs for an instrument family. I initially didn't get it at all, and have previously been a sceptic of LVOOP (indeed OOP in general). But the penny has dropped. I find it an elegant way to achieve things which were otherwise only very difficult to achieve previously. I now have the ability to address instruments with significantly different hardware implementation / interface / protocols as a general family of units bound by their base class definition. It also makes it MUCH easier to add new devices in future if need be. I don't quite get the discussion over by reference of by value. I understand the differences, but I personally prefer the by value concept because it's closer to what LV does in other instances. I like LVOOP, and I'll be looking for ways to use it in future too, but by no means to the exclusion of "standard" LabVIEW. Shane.
  6. QUOTE(tcplomp @ Nov 14 2007, 04:50 PM) Well, I generally follow links from the front page of LAVA listing the most recent posts. As such, it wasn't obvious to me at the time that the post was in the Code Repository Support forum. That would explain things. Thanks. I'll pay a bit more attention in future Shane.
  7. QUOTE(tcplomp @ Nov 14 2007, 10:32 AM) ????? I don't understand either question or answer......
  8. I second that with one small addition..... I've often wondered why I need so much screen space when programming ActiveX. I'd love to have an ActiveX text structure which accepts some ActiveX reference as input and from that point allows me to address the objects and methods in text mode. Just imagine how much easier this would make ActiveX programming in LV....... Of course, method and property prompting would be required based on the objects in use. I'd very much welcome something likt this in general. Like an advanced Formula node..... Shane.
  9. QUOTE(Jeffrey Habets @ Nov 8 2007, 12:55 PM) Yup, sounds like good idea with solid reasoning. I look forward to this in future versions...... Thanks Shane.
  10. QUOTE(Norm Kirchner @ Nov 8 2007, 05:46 AM) You have Issues? To me sounds like you have KIDS!!! Shane.
  11. QUOTE(ttkx @ Nov 2 2007, 02:16 AM) ttkx, Perfect! This is eactly what I was looking for. I'll be able to use this as a proper starting point to find out how the USB commands as described in the USB spec are to be handled within LabVIEW. Judging by the values you're feeding to the "VISA USB Control in", I have clearly misunderstood some of the parameters within the USB spec..... Shane.
  12. QUOTE(Tom Limerkens @ Nov 1 2007, 03:03 PM) Thanks Tom, but I've already done that. The articles are very superficial at best. What I need is a SINGLE wired-up example of a standard USB CONTROL communication (i.e. GET DEVICE DESCRIPTOR). The example you linked is only for BULK transfer. I need CONTROL transfers to know how to wire up the "VISA USB Control in" and out functions....... Shane.
  13. I've been trying to get some basic USB communication working under LV 8.2.1. I've created and installed the custom system driver generated by the driver wizard, and everything seems to be OK there. I've also downloaded and read up on the USB specification a bit. I thought I'd try communicating with the device by performing a "GET_DEVICE_DESCRIPTOR" request, which according to USB specification, the instrument must at all times respond to. I have wired up the functions "VISA USB Cpontrol out" and "VISA USB Control in" as I think they should be wired, but it's not working, plain and simple. I'm getting "Invalid buffer mask" errors for the settings I thought were correct for the communication. Using a USB sniffer, I see that I am able to provoke the communication, but I'm not able to get any data back. I'm also getting some unexpected error messages. I've already posted here on the NI forum. Could anyone here please help me out with what surely can't be too difficult a task. I AM a total beginner with USB communication so please go easy on me Shane.
  14. QUOTE(Justin Goeres @ Oct 17 2007, 06:08 AM) How 'bout LabVIEW 6.1 for FREE. At least foe Mac or Linux. If you can find a copy of 6.1 which was included on the cover DVD of a certain C't magazine (Germany) you can have windows too. Register here. Shane
  15. QUOTE(eaolson @ Sep 26 2007, 09:40 PM) Aaargh, there's some strange enscriptions there. I know they mean something...... Just... Can't... Figure... it.... out..... Seriously, it's certainly a difference if the size of each iteration is different...... Good catch. Shane.
  16. QUOTE(Justin Goeres @ Sep 26 2007, 02:57 AM) Yup, I'd have to agree with that one. I mentioned it because the Moxa series "should" be really good, but I had some problems with them. They have since released a new line, so perhaps they work better, I dunno. If it would be of interest to you, I could try out a sample transmission on one of my adapters (Code?)........ I'd be interested as to how it holds up. I also have a MOXA unit available, so a comparison may be interesting. Shane.
  17. QUOTE(Justin Goeres @ Sep 25 2007, 04:58 PM) It seems that your adapter does no hardware buffering at all. I know there are quite a lot of adapters out there which have a few bytes of buffer on-board. Not much, just enough to stop things like this happening. If you keep the Baud high, but lower the frequency of the data transmission (you're doing a simulation, right?), do you receive everything OK? If you reduce the packet size to 8 Bytes, do you receive everything OK? I don't think software buffers are going to help, because it sounds like the bytes are being overwitten on the Hardware judging by the error message..... http://www.exsys.ch/deutsch/produkte/ex_1334.html' target="_blank">Here's a link to the adapter I usually use, I'm pretty happy until now. I tried some Moxa (good reputation) but they bombed on me - on multiple occasions. They apparently don't support software flushing of their buffers! 64 Bytes of buffer. Really not much. I've tried to search for the 19Qi, but I've yet to find anything of use (like Specs). Maybe it's missing the HW buffer...... Shane.
  18. QUOTE(Justin Goeres @ Sep 25 2007, 03:54 PM) 20 Bytes at 500 Hz is indeed 10 KBps, but Serial transmission is normally lsited as Kbps (note small and large "b"). This, your 10 kBps becomes 80kbps without adding stop bits, parity and so on. Adding a stop bit and a parity bit moves this to 100kbps. This should still be below your 112500 kbps serial speed, but maybe it's just too close to the theoretical limit. Can you slow down the tranmission to only 250Hz and see if the problem goes away? edit: I see you tried this already. Perhaps it's a simple flow control problem? Check a different com port. I have good experience with Exsys USB-RS-232 controllers (prolific Chipset). Cheap and fully-featured. Shane.
  19. QUOTE(rolfk @ Sep 23 2007, 08:38 PM) I have to say my first reaction was quite similar to Rolf's. However, if the possibility exists to train the system externally, and simply use the speech recognition as input, the complexity should stay within more or less acceptable bounds. That said, all the caveats Rolf has mentioned still apply. But if it's needed, then make sure the training and fine-tuning can be done seperately to the LV program itself, otherwise it'll most likely get ugly. Just my 2c Shane.
  20. shoneill

    It's a girl

    Congrats dad! Tank up on sleep while you can Shane.
  21. QUOTE(tcplomp @ Sep 12 2007, 08:05 PM) In fairness, the NI forums didn't create the problem, it only highlighted it. I had some email communication with ben about a year ago on this subject. If anyone knows of a method to get the array size of an array via reference, please let us know. My preferred method is casting the "VALUE" to an array of variants, and using the "Array size" on this...... Or using the OpenG version of stripping it from the variant VALUE string itself..... Shane.
  22. QUOTE(Eugen Graf @ Aug 29 2007, 11:09 AM) You sure this isn't just an auto-wiring problem? If you move the property node up until it aligns with the wire, it should exit to the right..... Shane.
  23. QUOTE(Justin Goeres @ Aug 23 2007, 05:40 PM) Using THAT as a touchscreen would be a great workout! Shane.
  24. QUOTE(blueshrimp @ Aug 21 2007, 11:26 AM) I don't know why your 2D array isn't working, but..... why don't you try passing it as a 1D array (re-shape the array to a 1D array). Since your array is square, you can re-shape the array within the DLL quite quickly back to a 2D array. You also can have a check to see if the size of the array really is a square number (1,4,9,16,25,36 and so on). I might be wrong, but I think the re-allocation of an array from 2D to 1D where the overall number of elements remains constant is a trivial operation in LV, requiring no re-assignment of the data, just the Type descriptor. Again, amybe I'm way off here, but that's my take. Shane.
  25. QUOTE(Eugen Graf @ Aug 16 2007, 11:18 PM) Yeah, I understand. You don't need a full Path to open a reference to a VI in memory. Once you have the reference open, you can get the path there. I reckon the path is part of your problem. http://forums.lavag.org/index.php?act=attach&type=post&id=6656''>http://forums.lavag.org/index.php?act=attach&type=post&id=6656'>http://forums.lavag.org/index.php?act=attach&type=post&id=6656 Any reason why this shouldn't do what your original code wanted to do (Differences in output handling excepted)? It works on my 8.2.1 in development mode. How you get the single control is entirely a different story of course. Shane.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.