Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by shoneill

  1. QUOTE(tcplomp @ Nov 14 2007, 10:32 AM) ????? I don't understand either question or answer......
  2. 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.
  3. 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.
  4. QUOTE(Norm Kirchner @ Nov 8 2007, 05:46 AM) You have Issues? To me sounds like you have KIDS!!! Shane.
  5. 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.
  6. 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.
  7. 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.
  8. 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
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. 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.
  14. shoneill

    It's a girl

    Congrats dad! Tank up on sleep while you can Shane.
  15. 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.
  16. 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.
  17. QUOTE(Justin Goeres @ Aug 23 2007, 05:40 PM) Using THAT as a touchscreen would be a great workout! Shane.
  18. 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.
  19. 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.
  20. QUOTE(Eugen Graf @ Aug 16 2007, 10:25 PM) On a side note, AFAIK, if the VIs are in memory (which they'll have to be to be front-most ) you don't need a full path for the "open" command. Just a string of the VI name will do. Why shouldn't this work while programming? I think it should. Ah. You're building the paths from your "App" instance. While programming, this is LabVIEW itself I believe. In an EXE it's your build program. I think you need to switch paths depending on whether you're running a built program or within the development environment. Or you can just get "All VIs in memory" passing only these strings to the "open" command and forget the path altogether. Shane.
  21. QUOTE(Dan Press @ Aug 15 2007, 05:37 PM) Dan, I do something similar, but I have seperate loops for Event handling (one UI loop), one or more "main" loops, sometimes one loop per instrument and an additional "cosmetics" UI loop. I like being able to define cosmetic states of the FP in a seperate structure. I also don't like property nodes stealing valuable screen space in my main loop. I also make a lot of my programs have optional UIs (mostly reacting to whether they're called as a sub-VI or a main VI). These cosmetic changes can then be really easily switched off when the code is running as a sub-VI. BTW, I love the "For-Loop" coloured labels. Gives a really nice effect. Consider your style copied from now on! Shane.
  22. QUOTE(Ben @ Aug 15 2007, 02:49 PM) OK, I see what u mean now.... I suppose each software architecture, when pushed far enough, will develop some cracks. I wasn't sure you were referring to a single self-feeding loop. I wasn't even aware the term "Queued state machine" referred to this. I remember implementing something like this back in 1997 or 1998 before I even knew it had a name... Seemed like a good way to save time back then. Still, I had maybe 10 or 20 states, most of them quite simple. I actually (I don't know why) try to avoid self-feeding loops. It can be useful in some cases, but as a general rule I avoid them. On a side note, am I the only one who uses a seperate UI loop (hiding controls, scaling charts and so on) for their code? I guess I'm trying to prevent my main loop from switching to the UI thread for hiding and showing controls, but I don't know if it's overkill or not..... Shane.
  23. QUOTE(Ben @ Aug 14 2007, 10:12 PM) As others have already mentioned... Depends on what you mean with QSM. I use event-driven queued state machines quite a lot, especially in connection with UIs (otherwise events don't make so much sense) and I find it really useful, so I certainly won't be abandoning it any time soon. I also don't quite understand the problem with QSM and multi-threading. It's quite possible to have a well multi-threaded QSM if you use the right structure. Of course, I'm takling about an architecture with more than just 1 producer and 1 consumer. Goes more towards component programming than anything else, but it's core is still a QSM. There are cases where Statemachines are simply not neccessary of course. Ben, what do you think they should be replaced with? I await your answer eagerly! Shane.
  24. QUOTE(Aristos Queue @ Aug 13 2007, 10:52 PM) I agree with you 100%. If you refer back to my nugget, you'll see that it's the combination of UI and dynamic dispatch which I was looking for. In the end, I employed an ugly open-end system (based on variants) because I didn't see any other way of doing it. What I would like is somewhere between that and the current system. LVOOP would be perfect if we could place class data directly on the FP for user interaction, but we can't. Hence the idea of having a list of "registered" typedefs for a kind of dynamic dispatching (A Typedefed Control CAN be on the FP). I appreciate that the ability of the compiler to detect wrong data types at compile time is very important, and I'd be delighted to have this functionality. I also tried creating a polymorphic VI with different Typedefed (sp?) inputs, but although no error was created with several polymorphic instances with (essentially) the same datatype but different Typedefs, no polymorphism resulted. At the moment, "With the dynamic dispatching of classes, I can view the class hierarchy and know whether or not a given class has a given functionality. With arbitrary overloading, I become less sure at every turn whether that "add" primitive that I see on the diagram is actually an add." I find it difficult to fully appreciate the real difference between the two cases you're mentioning here. Maybe when I get more familiar with LVOOP things will clear up for me. But I think your example of overloading the "add" primitive is overshooting the mark a tad. The original idea was (when you get down to the bare bones) a convenient way of working with known data structures. I was also trying to demonstrate function overloading, not operator overloading (i.e. Pi() and Pi(2)). In reality, I was actually coming closer to a sort of polymorphism with an extended definition of "Data type". Upon reflection, I have come to realise that the ability to define polymorphic VIs based on their ENTIRE TD would be the right way to go about this. Certainly a long way from arbitrary overloading. To quote one of my posts in my nugget thread (spelling mistakes retained for authenticity ) "I've jsut started working my way into classes, and I love "Dynamic dispatch". I'd also love exactly the same thing for Typedefs. I want a control I can place on a Front panel, wire up to a function and to have the function automatically execute a method "registered" for that exact typedef (such as entering that value into a pre-defined cluster). Replace the control with another Typedef, and the code called updates..... How and where the "registration" takes place, I dunno. Maybe even statically within the VI being called, thus providing strict limits to accepted typedefs." I think the usage of Variants and the admittedly open-ended implementation of my code has actually distracted from what I actually was trying to create. "Registration" is the key here, otherwise you don't get compile-time error checking. So we're agreed on that at least. Shane.
  25. On a slightly unrelated topic, I wish there was the ability to perform "Dynamic dispatching" based on Data type, or even just on Strict Typedefs....... This wouldn't be a "one size fit all" approach, as there need to be a finite number of defined end states, but I think it'd still go a long way to allow some more advanced features. especially when tied to a producer/consumer design. My original post (NI Forum) is here. This, in my opinion, would make some issues in UI programming a LOT more versatile indeed. Haven't tried Xnodes though. Will do shortly. Shane.
  • Create New...

Important Information

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