shoneill

Who KNOWS anything in this regard. It's mostly personal feeling and second-guessing I think. That's what makes it so hard. Shane.

Slimey? That I don't understand. I'd rather you discussed more rather than slip out, but it's your call. Please don't confuse my candid opinions with aggression or intolerance. I'm just looking for other people's takes on something which belongs to the ultimate question whose answer is 42. Shane.

I appreciate the response, even though I won't yet claim to have understood everything yet.... I would argue, however, that even the origin of virtue space is actually an individual trait. Everyone's virtue system is slightly different. There are no absolute scales for virtue. So it in in reality a bit more complicated because a position x,y,z in one person't virtue space will not neccessarily co-exist with position x,y,z of another person's space. I also find the combination of "measuring" virtue and human behaviour to be a mix which leads ultimately to some contradictory situations. Being guided largely (although not exclusively) by emotions and desires, our unwillingness to "slip down the scale" of virtue leads us to concoct some really abstract and illogical situations where something which is not inherently virtuous is deemd as being something "good" simply because of its neccessity. This can lead to a severely skewed and ultimately misleading grading of a person's actions. Waging war is an example. I think it's clear to everybody that war is essentially inevitable (although the arguments about when, why, how and where are endless). But does this make it virtuous? Is it a virtue to engage in extreme violent conduct in the name of one's country? In the name of anything? In any other setting it would be condemned but the neccessity for such actions (being human as we are) makes us spin a web of virtue around something which is not inherently virtuous. This is a big problem I have with any aattempts to prescribe an absolute virtue space. Due to the inevitable nature of war and the unwillingness to "slip down the scale", society moves to declare by consensus that war shouldn't be put on the negative virtue list because that would interfere with out way of doing things. This is moral relativity in it's worst form because it actually pretends to be absolute. Now, before I get flamed, I'm not saying that I'm totally anti-war. I believe it IS neccessary in certain conditions and is almost certainly largely unaviodable but I also believe it a folly to dress it up as being an act to be celebrated in any way. We should call it what it is. By relating to where a person "should" be you are automatically creating such a construct as I have outlined above where the person actually strives to climb the ladder and (being human) ends up misusing the value system to serve their own needs in an innocently selfish way. Kind of like a white lie. Personally, I tend to avoid absolute moral compasses. This was perhaps accelerated by coming from Ireland where the Catholic church WAS the absolute moral compass and has been involved in a serious and continuous stream of child abuse claims for the last 20 years or so. Some moral compass there. Even the current pope Mr. Ratzinger is being directly linked to the systematic cover-up which was performed by the church over the years. Or perhaps the ultimate christian moral compass, the decalogue, is also often conveniently ignored or bent to one's will when required. "Thou shalt not kill" seems fine, but what if someone is threatening my family's life? If I kill someone to protect my family is that a good or a bad act? For me and my family it's probably good but for the dead person it's almost certainly bad. No absolute compass to be found here. It simply does not apply in all situations. We all possess an inner sense of what is right and what is wrong in any given situation. This is independent of our background (although some can blend it out more than others) and is often very different in people who otherwise claim to share the same beliefs or absolute moral compass. To summarise, I think an moral compass can help in some situations to offer guidelines as to how to behave (and the bible offers some good examples but also some absolutely terrible examples) but regarding a sense of "absolute" good and bad, it simply does not exist and to think it does is simply fooling ourselves. So while you and I most likely share a very large part of our beliefs of what is right and wrong, I think we might very well give very different reasons as to WHY they might be right or wrong. I'd better start working otherwise my boss will point my moral compass to a state of unemployment..... Shane.

I'd agree with this completely with a pedantic difference that I'm not at all convinced there's anywhere we SHOULD be. We just are. But our responsibility to decide is (even being pedantic) correct. Shane. Without wanting to get into a nasty argument I would wager that the above statement for any other subject other than "God" would lead you to the idea that the idea at hand is flawed and most likely to be incorrect. Shane.

Ben, your analogy falls hard when taking into account that "God" is supposed to be all-knowing and did actually (according to scripture) create us. As such it would be more analagous to the robot dog part than the "real" dog because the "real" dog would suggest that we contain unknowns and therefore could not have beenmade by "God", a theory I could wholeheartily support BTW. Shane. I've yet to befriend a plant or a mineral. As such all my friends are animals. Shane. PS Except for the numerous electronic gadgets I can't live with but who sometimes unexpectedly don't return my calls..... No please don't. It'd be like taking away Pete Doherty from us parents. This post serves as a shining example of how NOT to engage in internet forums the same way that Pete Doherty serves as a shining example to our kids of what happens when you take copious amounts of drugs. Shane.

I'm currently working together with a customer to get a new vision analysis system up and running. Having used VBAI 2009 for testing his processing we came up with the idea to implement the entire thing in VBAI. Things got a little more difficult when we started talking about motionc ontrol, buffered breakpoints and bufferd images but we reckoned we could handle all of these. Where things got really interesting was trying to implement a custom step in VBAI to launch a program to do the acquisition in the background and still allow us access to a set of images buffered within the application. After much blood sweat and tears I got it working. There seem to be many caveats about memory sharing in VBAI custom steps which (to me) seemed non-obvious. Are there any more detailed sources of information than the VBAI development manual installed with the toolkit? Shane.

Without more code to go by this is just a guesstimate: Do you have a "num" field in both the parent and child? Could it be that you're setting the parent value and reading the child value or vise versa? Shane.

I think I understand why my example doesn't retain the array order. Seems logical once you've tortured your brain with it. Here's an example where it might work better. I'm creating an array of single-element queues instead of one large queue to pass the data to the parallel for loop. That way the array order is maintained. The OTHER queue (single large queue) is there only to be able to monitor the number of elements yet to be processed. It has no influence on the functionality of the VI, simply for visualisation of the enqueuing / dequeuing process (as is the bottom While-loop in its entirety). Shane. Parallel for loop.vi

Here's an example to play with. Try changing the number of cores. Ideally the graph ont he right should show two identical lines shifted by 1 (and the array should be all 1.000) but contrary to what I expected, the array order is NOT being retained. For some reason, the order seems to get mixed up exiting the parallel for loop.... I thought this was supposed to retain the array order (Not the processing order) of the data. I think the problem is the asynchronous access via the Queue. Seems like you need to definitely incorporate some ordering information into your data so that you can reconstruct the array order afterwards. Shane. Parallel for loop.vi

Your picture included a single Queue which was being filled and emptied by three parallel loops. As said before, each entry int he queue will go to ONE of the THREE loops, but you don't know which one. I'm assuming that you will re-gather the results of these loops somewhere later in the program. My code basically does the same thing, but uses a parallel for-loop to do the same thing. It only deals with the processing part of your problem, not the filling of the first queue. The For-Loop can be set (programatically) to a certain number of parallel tasks, each of which waits for an entry int he Queue. Each entry will be read by one and only one process, this is due to the atomic nature of the reads and writes to a queue. The clue is that the parallel for-loop actually spawns "P" processes in the background which all perform the same task. Each of the "P" processes can dequeue an image and work on it independent of the others. Due to the atomic nature of Queue reads and writes, you already know that any entry to the first queue will go to one and only one recipient. This way you can have "P" process working concurrently ont he problem, processing the images as fast as your multi-code PC will allow. Tis continues until all of the expected images have been rpocessed "N". In order to be able to collate the results after processing, you need some kind of output scheme. I have used a queue. You could theoretically place the "Enqueue" INSIDE the for-loop but this requires the user to re-order manually. By placing it outside the For-Loop, the compiler ensures the ordering for you and you just need to enqueue them. Since we're dealing with IMAQ references (4 Bytes only)e memory overhead is small. Shane.

Wow. Where DO you get this information?? Shane

What about this type of approach assuming you either have all your data ready at once OR know how many data packets you will have. Parallel for-loops are new in LV 2009. Shane.

Same thing happens with XControls also. See HERE. Look past the queueing issues and it the Event queue gets all mixed up in execution order. Shane.

If I was using Queues for communication I'd use the QSM. Since I tend to use events, I have an event-driven State Machine. I've said nowt about the merits of state machines, only the queue-driven ones. Shane.

For What it's worth I don't like queue-driven SM at all. I use Events far more than Queues, although I must admit Queues have their place too. Shane.

What you say about calling the code in the runtime is of course correct. Reading the site it seems that they simply do a web crawl and assign the number of hits to the number of users somehow. Not terribly reliable but it's at least SOME kind of indicator I suppose. I've never used NXT so I'm not aware of the differences. I was led to believe it was more or less LabVIEW (or at the very least based heavily on LabVIEW). I suppose exposing kids to inherent parallelism might not lead to much joy on Christmas morning.... Shane.

I always thought this was an old Myth regarding LV. There is NO intermediate C++ code AFAIK. Most of the primitives have direct machine-code representatives. The IDE is written in C++ (and more and more of it is actually written in G itself). Shane.

While the IDEs may be radically different, are you so sure that the language "behind the scenes" is so different to warrant calling it a separate language to G? Shane.

NXT-G (Mindstorms version of LabVIEW?) is listed at # 35 (0.237 %), one place above LabWindows CVI (#36 - 0.226%) whereas LabVIEW is at #48 with 0.162%. This would place the Language G at a total of (0.237% + 0.162% = 0.399%) which would place it at #26, one place ahead of FORTRAN. Aren't NXT-G and LabVIEW actually the same Language (G) ? Shane.

Ah, OK. I thought they would constitute copies. My bad. Shane.

Michael, I'd love to hear NI's official stance on exactly what you're suggesting. My interpretation of it was that each VM (whether it's emulating the same hardware or not) is a seperate installation in the eyes of NI. Shane.

I've had trouble getting USB to work (on windows hosts) but having said that I haven't tried any of the recent versions. Shane.

I think NIs argument is that a VM IS a computer (an emulated one, but a computer nonetheless). Their problem may stem from a fear that a LV-populated VM is PORTABLE meaning it can be run on anyone's PC (actually a fantastic thing) and can be dupilcated really easily. I wish they would re-think but they seem to not want people installing on lots of VMs. I know I'd have dozens of them if I was allowed. Shane.

I would generally export a RegRefnum. Like you say, it gives extra protection. One thing to be aware of though.... If you export the a RegRefnum based on the SAME User Event then whenever the Event occurs, the UserEvent is exposed in the Event Structure. Rogue code could then actually destroy the UserEvent and put ALL processes listening to that Event in Limbo. The only other way would be to implement some kind of two-tier system where the initial internal Event fires an Array of other Events for which each listener has received their own RegRefnum. This way destroying a UserEvent will only affect that listener, not all listeners. Bit more complicated but it should be do-able. I have asked NI why they expose the Refnum but I have not really heard a compelling reason to do so. I personally would much prefer to NOT have the naked Refnum exposed, or at least have the option to declare it in such a way that it is not exposed (for compatibility reasons). Shane.

I asked about this on the dark side a while ago and apparently the official NI line is that each and every VM counts as one of your 3 installations. Totally weak but it's important to know what NI thinks. That means that one "normal" installation (with 5 or 6 LV versions) counts as ONE installation apparently, allowing only two VMs to be used (officially ). Shane.