shoneill

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 main issue I see is your resource definition is spread about rather than being in one place so if you run into resource issues it is harder to get a picture of what is going on. That said this technique is also great for reusable code. Take a look at the VST sample projects, they make extensive use of this for reusable code modules under FPGA.

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.

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......

I love trying to understand lordexod's posts, they are like doing a cryptic crossword 

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.

The dynamic dispatching is not expensive.

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.

Do you have compiled code separated?

Never agree to a fixed price project for a finished work.  The "customer" can simply claim something minor was not finished and decide not to pay.  You need to make sure your liability ends once the customer accepts your code is transferred.  Each deliverable should be immediately billable.

I did a project like that once without help from a lawyer and it cost me 4 months of my life.  Didn't get a penny at the end.  Even if you have a contract, you have to have the means to enforce it legally.  Most developers simply can't do that so I would also reiterate the stance of either money up-front or forget about it.

Shane.

I have had cases in the past where I explicitly wanted the plot bounds larger than the plot size.  I can't remember what it was but it had something to do with using plot images I think.

I think it is because the GrapChart also covers some 3d graphing objects:

 

 

(source: http://zone.ni.com/reference/en-XX/help/371361K-01/lvprop/propmeth_class_hierarchy/)

 

Ton

I don't see 3D in that list, but I do see intensity graphs and charts....