Jump to content

shoneill

Members
  • Posts

    867
  • Joined

  • Last visited

  • Days Won

    26

Everything posted by shoneill

  1. QUOTE (Graeme @ Sep 16 2008, 08:57 PM) I also thought that a couple of times. Also the ability to have multiple selectors for input clusters or whatnot. But to be honest, I'd recently be happier of NI spent more time debugging and introducing a LTS (Long Time Support) verison of LabVIEW so that all those known but annoying bugs in non-current versions could get squashed. I've heard through the grapevine that NI may be considering this option as a course of action. Whoever wants it should make themselves heard..... Shane.
  2. QUOTE (torekp @ Sep 16 2008, 03:31 PM) Not at all. Has happened to us all, right guys? Guys? Oh. Well it's happened to me anyway... Shane.
  3. After exiting the lower loop, simply wire a constant to a local variable for "State" to reset it to a value which won't cause the observed problem. BTW, I'm also of the opinion that the pre-set value of "State" is your problem..... Shane.
  4. shoneill

    Alfa String

    QUOTE (alfa @ Sep 16 2008, 09:41 AM) In all fairness, the computer will say whatever the model you tell it to calculate will produce. The poor computer can't help itself, it's your model which gives you the 98%. Science and maths are just tools, it's what you do with them thats important.... How do you make lots of money when God doesn't exist for 98% of the population? That's a relatively small market isn't it? Shane.
  5. shoneill

    Alfa String

    QUOTE (rolfk @ Sep 5 2008, 03:48 PM) I agree, not only unanswerable but totally illogical. I will stop as I fear of sparking off one of those intolerable "origin" discussions. Shane.
  6. shoneill

    Alfa String

    QUOTE (rolfk @ Sep 5 2008, 02:17 PM) But that's just silly. It's confusing the metaphysical with the religious and with the physical. So the question remains: who created the 2%? Shane.
  7. QUOTE (Poom-Thailand @ Sep 5 2008, 12:59 PM) Just in case there's any confusion.... Is the camera a monochrome camera or a color camera? Most of the Basler cameras I know are monochrome. There is no "true color" in that case. Please re-post if I misunderstood. Shane.
  8. shoneill

    Alfa String

    Alfa, if you have a theory, does it fit the following definition of theory within a scientific sense? Or is it just conjuncture and speculation? QUOTE (Wikipedia) A scientific theory must be falsifiable. There must be a defined set of circumstances which could be practically used to prove a theory false or true. What would this look like in your case? On a different level your comment QUOTE low level people were created by God confuses me. Who made the other 2% of the population? Shane.
  9. QUOTE (pikro @ Sep 5 2008, 12:28 PM) When you get the path of a VI from within an EXE, the name of the EXE is treated as a folder. The EXE is basically just a glorified LLB. You need to strip one extra level from the "this VI's Path" to get the containing folder after making an EXE. Pain in the rear I know, but once you know about it, you'll know in future. Shane.
  10. QUOTE (menghuihantang @ Aug 21 2008, 11:53 PM) I was just dealing with this topic yesterday and today. The driver is designed for use with only a single camera. If you look under "Known Issues" http://zone.ni.com/devzone/cda/epd/p/id/5030' target="_blank">here then you'll see that. It might be that the selection is offered as an option, but not implemented. Shane.
  11. QUOTE (jgcode @ Aug 21 2008, 07:46 AM) Or use the OpenG versions with error inputs and outputs. You DO wire the erros terminaly, right? It's a better solution than sequence structure and needs less space on the diagram..... Shane.
  12. You can't cast a parent as a child unless the true class type of the object is in fact a child (having been previously up-casted). Your solution is to implement the code in the parent and then call it within the child, so logically the opposite to what you're questioning. Inheritance works in one way only. Why not remove the data from the children and simply use the parent implementation (Call parent method)? Shane.
  13. QUOTE (mross @ Aug 11 2008, 09:12 PM) I meant "most people" in a more general sense i.e. not just LV programmers..... I think in a pencil-and-paper scenario, more people would draw a horizontal line than a vertical line. Shane.
  14. QUOTE (eaolson @ Aug 11 2008, 07:50 PM) Differentiation between internals and the API is a topic unto itself of course. I think most people might also illustrate a 1-D structure in the horizontal rather than the vertical so it might be some innate preference hard-wired into our brains. Shane.
  15. QUOTE (eaolson @ Aug 11 2008, 04:39 PM) You may talk about them that way, but they're not stored that way. Even the old BMP format stores a collection of rows to generate a 2D picture. Try to imagine the old CRT with horizontal and vertical frequencies..... Shane.
  16. Sylvain, LabVIEW isn't re-ordering anything, you are. The graphs look more or less correct for what you're showing. What do you think the graph SHOULD look like? Shane.
  17. QUOTE (Yair @ Jul 15 2008, 05:14 PM) I would agree with the bug nomenclature.... The port should be settable regardless as to whether the server is active or not. Shane.
  18. QUOTE (Darren @ Jul 14 2008, 06:18 AM) I don't "get" any specific "chicken" reference, but it's funny nonetheless. Shane.
  19. QUOTE (Yair @ Jul 11 2008, 11:58 AM) Ah that makes sense. I did notice the concatenation "feature" before. That would of course be a perfect explanation, even if the result was slightly confusing.... Shane
  20. Yair, you kinda threw me by quoting yourself within your own post. I was trying to find the hidden reference somewhere....... Shane.
  21. QUOTE (Eugen Graf @ Jul 10 2008, 06:29 PM) It's clear that there is some functionality which is NOT given with UEs. When I look at the code for registering / broadcasting and so on, I still think UEs are a good choice for any multicast type of functionality. Would it not be effectively less code to have a small unit (single VI to run in parallel to the main VI) on each recipient's side with an event case registering for the event in question and sticking them into a local queue to add the required functionality? So this would be like using the UE for distribution, but a local queue for storage..... Disclaimer: I'vce often thought about something like this, but never actually implemented it. As such there may be some glaring disadvantage in my suggestion. Shane.
  22. Assuming all the code is on one machine, why not use user events with multiple subscribers registering for the event? In effect it's similar to a notifier but with the ability to work via an event case instead of a function. Once you register more than once, the event gets passed to EACH of the registrees (is that a real word?). It gives you essentially a 1..n link, albeit without the Queue (backlog) part. Sample VI Attached (LV 8.2.1). Shane. PS I just realised I forgot to destroy the two user events when the program finishes.... Oops
  23. QUOTE (Aristos Queue @ Jul 8 2008, 04:06 PM) Well I have to confess that I don't know what the official meaning of an "active object" is..... Google says http://en.wikipedia.org/wiki/Active_Object' rel='nofollow' target="_blank">this. (DOH! Ben got there first.....) All the same I'd imagine (in LV context) it's an object which has a background process as Ben describes. It could perhaps also be tied in with Events so that it comes into play whenever certain criteria are met. Queues would be another logical interface choice. I'm working on such a beast right now. I've recently "discovered" user events and am using them to implement an interface to a process spawned in parallel which then feeds back into the original program via Events. All asynchronous. Of course items defined by their interface are perhaps better called "components" than "objects" but maybe we should leave that discussion for another time.... Edit: I also see nothing in the Wikipedia definition which dictates the use of OOP at all. However, given the name, I'm sure it is meant to apply to OOP classes with a suitable interface and scheduler. I still like the idea of getting values back via Event structure. Having VIs for getting the values back requires either polling or restrictions in the concurrency of the solution, no? Either way, a nice method is required for making requests from the "active Object". Queues are the natural choice. Are there any other realistic possibilities? User Events could also be used here.... Any performance difference to be expected between queues and user events? Advantages disadvantages? Shane.
  24. QUOTE (JFM @ Jul 8 2008, 10:41 AM) I personally find this new feature a lazy way out which complicates things unnecessarily. I would have actually preferred an Iteration link to the stop condition of a while loop than a stop terminal in a for loop. Seems to make more sense to me as a while loop has already a non-determinate number of iterations whereas a for loop is fixed. An option on a while loop (Stop if Auto-index limit reached) would have been a better choice to implement what is basically the same idea. It's just a different visualisation. Shane.
  25. QUOTE (Yair @ Jun 27 2008, 01:33 PM) Seeing as the descriptors can be very long and complicated, it's very useful sometimes to know how to easily skip to the next item in the descriptor. Hence the first value. Of course one could deduce the next offset based on the data available, but I'd rather take the 0.25 Bytes (on average) cost of the second length value for faster response time in LabVIEW. Isn't this all derived from the general and pretty much global method of defining type descriptors? Such type descriptors for Controls can get pretty involved. Shane. Ps I see your point regarding the value of 18 instead of 20. I think this might also be a result of a global method of handling type descriptors IIRC. I think the descriptor for a PStr lists the total length as the total length of the DATA and thus excludes the two bytes for the size information. It will thus always be 2 Bytes short of a multiple of 4.
×
×
  • Create New...

Important Information

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