shoneill

We created something similar. We first put all FPGA communications into sub-VIs. Then we created a simulation loop for the RT where we called a model VI instead of the actual IO vi. Because we kept the FPGA reference encapsulated within the sub-VI, any code which didn't actually make use of the VI ran fine. So I would recommend simply encapsulating the communications to your FPGA target and things work better.

If the code for launching B is in A, then yes then A is dependent on B, that's the way the system is. If A needs to have knowledge of B in order to be able to function then those two modules are coupled whether you like it or not. With the code for launching B in a message you are right that a static copy of that message on the BD of A will still cause a link. Can you interact with B as a plain actor? If so, then you could also load the messages which are associated with certain state changes (used for deciding whent o launch B) via Factory method - as a base Actor - and then your static dependencies are gone. I've done this kind of thing before where I have a pre-determined state machine (Actually based on User Events from specific UI elements in my case - nary an actor in sight) and then I provide at run-time the objects (commands, messages whatever you want to call them) to the running code to tell them "When A happens, do this". The list of Events is static (This is the API) but the actual actions performed at any stage remains reconfigurable and any specific dependencies disappear. You have a skeleton of a state machine where the meat is provided at run-time.

Regarding your original post here: Maybe I have the wrong end of the stick here but here goes..... Your Actor A has a base "Do" implementation which gets called on any message being received, right? The only thing adding B as a dependency is the message set up to do this (and it's associated dynamic dispatch "Do"). I was the opinion this would make Actor B a dependency on the specific message for launching B and NOT of the actual Actor A. Or do you somehow have the messages stored within A? I don't currently use the AF because I too found it not a correct fit for what I do (and have been pondering an event-based system for quite some time now - unfortunately without concrete results). Shane.

A small tip: You don't even have to re-enable Panel Updates (Defer = False). Every time you set "Defer Panel Updates" to "True" it will actually refresh. So you could initially defer updates and then, if you want, refresh at regular controlled intervals by repeatedly calling "Defer Panel Updates" = True and only setting it to "False" once all of your work is done.

My colleague has since downloaded most of the videos...... Problem solved

I managed to get a couple of videos this morning before my IP was blocked.... Now I get the "Connection not allowed from your IP" message every time I try to connect. It's not my fault I was trying to download all Videos simultaneously over a 150Mb connection.....

The upside of this is that if you need 1 instance, you use 1 VI, if you need 8 instances, you use 8 VIs. Instant scaleability. That's the main reason why I went in this direction. In one sense, having all the relevant information in the code instead of spread between code and project makes it (for me at least) easier to understand. Add in more modular design capabilities with registers instead of globals and things start looking good. Shane.

Guys, guys, I for one am delighted at the increasingly barren "new features" list for each LV release. I've been using LV for many years and have grown to love hate accept many of its idiosyncracies as being de-facto standards. Bugfixes are cool, new features = new bugs. I don't like bugs and as much as I'd love Interfaces for LVOOP and a host of other things, at the moment, bugs and stability issues are my main source of pain with LabVIEW at the moment. Daily crashes, huge delays when editing VIs in projects used on multiple targets simultaneously.... LV needs major repair work. We would all most likely agree on that. The 20+ year old code base is no longer an adolescent and really needs to get its act together. There are certain kinds of petulant and stubborn behaviour which may be acceptable for a teenager, but at the tender age of 28, its time we raised our expectations. Minor rumblings from NI (and quite possibly some optimistic pattern recognition on my part) have led me to have some hope that this process of repair or self-improvement is already underway. I for one look forward to the day where all of the fixing in the background can finally be accelerated because a lot of the old crap (there's no other word for it) has been cleaned out and the source code for LV is finally in better shape. As someone who has been crying for better stability for years, I am delighted to see shorter and shorter "new feature" lists because I'm optimistic and believe the time spent NOT implementing new features has been used for a much more valuable long-term goal. So my message is, have faith. PS Yeah, I wrote behaviour with a "u". I won't give in to the LAVA spell-checker. I won't..

I just looked at the code. Interesting. Unusual thing is realising the work being done invisibly by the callback VIs. This seems really weird. I'm used to seeing the work being done in the BD I'm looking at but I suppose if the scope of that kind of work is strictly limited it'd be OK. Still, I find the code very interesting. Nice use of a variant tree for storage.

James, that has indeed piqued my interest. I've actually never used an event callback VI but the idea of dynamically assigning functionality to events seems very useful. Is this the missing link I have been looking for? I have to try something out......

Where each of the answers to the clues are required in a different (unspecified) language.

Personally I like coupling the dynamic dispatch behavior of the implementation with a static definition of the API for such an extensible UI. I feel the dynamic aspect of LVOOP is great for determining HOW something is done but I still much prefer the static datatypes of Events to determine WHAT should be done. This is a reason why I don't really like the Actor Framework because there's no way to effectively implement a limited API. I have recently started a discussion with AQ on almost exactly this topic regarding the ability to manage such "extensible" static datatypes (registered user event refnums) within LVOOP frameworks. It seems I may not be the only one running into this wall. By the way: As long as the UI interaction is handled BY THE CLASS, there is no problem with extensibility, even with events. Each class knows which events it can and cannot register for and control. It's only when you need to interface to the world outside of the class boundary that the dynamic - static problem rears its head. BTW, the Discussion took place HERE.

CFR part 11 is a doozy. Tehcnically, it should be impossible to adjust recorded data after acquisition without the system keeping a record of the changes made and who made it. There can be no access to the data without signing on. A perfect audit trail must be made fromt he original acquisition to report generation with all changes logged and recorded and everything not exposed. If the DSC module handles this, then it should be OK, but knowing people working in the Pharmaceutical industry (I'm actually an analytical scientist myself), I wouldn't want to be carrying the responsibility for certifying the software ase CFR Part 11 compliant. Shane.

Are you just sharing your thoughts or are you looking for input from someone? LabVIEW can also dynamically allocate memory, indeed dynamically instantiate objects and their lifetime is defined and limited. I don't see the problem with this and OOP. Being a by-value paradigm does not in any way prevent LabVIEW from being an able OOP language. Certainly certain OOP implementations may be more or less suited to LabVIEW but nothing at all about OOP REQUIRES something to be by-value. It just happens to have grown that way. It is possible to have a by-ref object in LabVIEW. Again I don't see the problem with this and OOP. So my 2c is that LV can do OOP just like other languages but (and this is kind of obvious) the specific implementation details will vary from some other languages.

I would go perhaps a step further and make a product request that casting an object to variant should pay attention to the Run-time type which it apparently does not currently do. Although I find the workaround not too cumbersome, I think it can be argued that the function of casting the object to variant should already do something because the object knows at Run-Tme what it's real object type is. Shane.

You're welcome.

If you insert a "Preserve Run-time Class" primitive on the class after casting to an LVObject it will work. Variants don't know all the intricacies of class types. So between casting the variant to a LVObject and before casting back to a variant, insert the above-mentioned primitive and away you go. Shane. I would also simply name the constant input for the Variant to Data "Object" instead of renaming the item within the variant.

For me it would be nice if the compiler threw a message when a cluster (or object) leaving a structure as hinted at above would produce an error that dynamic references are not supported, just as it happens when a naked FIFO reference leaves a structure. This would have saved my a couple of hours last time since the error was suggesting that the problem was occurring somewhere much later in the chain than was required to fix the problem.

Like I said, if you're not measuring execution time in microseconds (sub 100 us) then DD calls are almost irrelevant. Even on RT.

Should I comment, should I stay quiet...... This all depends on your definition of "expensive". I have situations where the DD call is prohibitively expensive. But that's most likely a discussion for a different application. Long story short: In cases where you're squeezing every microsecond out of your code speed, DD can be very expensive due to the inability to inline. For all other cases it should be fine.

I know arrays don't work, you can't even CREATE an array of Register references. Clusters I don't know. Never tried. But then again, aren't Objects just clusters with attitude?

Yeah, ran into this today again. It's not specifically an LVOOP issue but I found something unusual today regarding this combination. I'm using LV 2012 SP1. Normally if you pass an FPGA reference (FIFO, Register and so on) out of a structure you'll be warned by the compiler that this is not allowed. There's an extra error for that. (Dynamic references not supported). If, however, you pass an object which CONTAINS a reference out of the structure, LV will not tell you about that but rather will complain that the next piece of code which tries to do something with the reference does not have a proper named reference. LV marks the references within the object as possibly variable when exiting the structure but doesn't raise an error on that. My error message was for a FIFO reference today even though I was using registers only. IT had me stumped for quite a while actually. Having the error being associated with the wrong part of the code makes tracking down the problem harder but I'm assuming it's the same with shift registers.

Careful. I've had cases where I want my code to be portable and have had serious issues with "smart" compilers on Real-Time systems. I ended going back and putting in a load of IPEs to get my performance back. Not all of NIs compilers for different targets are created equal. Just because it works like a dream on one target, doesn't mean it'll do the same on all.

Casting the object to an XML string doesn't do what you need? This will be a killer if your objects store a lot of data but any values which are not the default for that class will be listed in a searchable form. It's a gaping hole in object encapsulation which I've made use of before, but haven't actually used it since LV 2009 so maybe it's been "patched". Shane.

Class private data is a typedef.