shoneill

What do you meant he data is nor delimited..... How do you separate adjacent floating point numbers with a scan formatter with "%f%f" in it?

Limit the length of the strings being read by using %xs where "x" is the number of characters you want to read.

The same goes for non-floating point numbers.  %3d will read in a three-digit decimal number.

Using this you should be able to get what you want.

XControls remind me of following image:

They promise SO much but don't deliver what they were clearly designed for and could probably manage.  I use them from time to time but my expectations have steadily shrunk over time.

Dunno, sounds like somethings a bit awry with your object hierarchy if you need to be manually checking for overrides.....

Havie you tried handing off the UI to the actual class?  That way they can automatically show the correct GUI.  Hint: Subpanels.

Shane.

I take it she's OK though.  You don't mention, so I'm just assuming...

@Daklu,

I responded early in the thread with the option of having a class as an input for a DD call instead of looking to change the connector panes. That idea was thrown out because of excessive maintenance required but personally I find it the "correct" choice.

I agree neither strategically nor practically (when you think about HOW this would be implemented) with the idea event hough I fully acknowledge the problem motivating it.

Shane.

Just as Dynamic Dispatch has 'Must Override' and 'Must Call Parent', a static method could specify 'Must Implement' and 'Must Call Parent'.

 

Note that 'Must Call Parent' has essentially the same semantics for Static and Dynamic Dispatch. Yet 'Must Implement' might be loosely analogous to a less-stringent 'Must Override'.

"Must Call Parent" won't work with SD because the child doesn't know the connector pane of the parent.  Or it does in a given moment, but needs to be manually updated if you ever change the hierarchy of your classes which will almost certainly be a major PITA.  This can be done automatically with DD since the guarantee is there that the connector pane is identical.

I still prefer to use objects as input parameters instead of going down this route.  If the objection to this is the maintenance of the individual classes then the maintenance of the implementation being provided would be (in my opinion) just as problematic.

Shane.

PS The argument that the class hierarchy is (pun unintended) static and such maintenance problems won't occur, then my counter-argument is that the only constant in software engineering is that nothing is constant.

Yes, that's perfectly possible, but it doesn't solve anything - I ruled this option out from the very beginning. By looking for a broken VI on a specific target type you can't determine incompatibility with that target. The VI can be broken for any number of reasons beyond incompatibility with Real-Time or FPGA.

 

There isn't any way but brute force object traversion looking for target-incompatible objects...

 

/Steen 

Well I would think defining a broken VI as being incompatible with a target would be a valid response.

Seeing how it is incomplete it cannot run on the target.  Testing a broken VI for compatibility seems to be a bit wierd if you don't mind me saying so.

Is there any way to get the list of errors or warnings for a given VI?  If so, then filtering them would give you the information you need.  If not, it would make for a great idea on the Idea exchange.

Shane.

Stupid programmers.

Or NI Marketing, it's kind of the same thing. 

Is it possible to programatically create a RT or FPGA target and copy the VI there to see if it's broken?

Anything else is way too much work.

Shane.

Just curious, have you run into an issue with memory, storing all that state data for a single change?

No, I don't store THAT much.  Each undo or redo is a coupld of kb at most.

I generally sculpt my UI to have a single (for smaller VIs) state for updating the display which simply takes this data and, well, updates the display.  The actual DATA is coming from elsewhere, I'm not storing that because as soon as I store it it's out of date.  A lot of my state data is references (which are essentially unchanging and COULD be stored elsewhere) and simply visibility settings and so on.  Typical UI stuff.  I'm not writing a word processor.

Shane.

I've done this using bacisally the memento pattern.

I create an Class for my program (which derives from a base Memento class) which then stores ALL data needed to properly enumerate the program at that time.  Since I'm dealing mainly with UI representation of incoming data, this is do-able with finite effort.

I then have my undo / redo handler which receives and spits out objects of the Memento Type which can then be simply inserted (when a new step could be undone) or retrieved (when undoing or re-doing).

I've found this to work really simply given the initial assumption that the objects you are "storing" completely represent the VI state at that point in time.

Shane.

PS Yeah, the stored objects could each represent sub-states of a VI but given the number of VIs I have to implement and the finite time my days offer, this is by far the quickest solution I could come up with and it's complexity is not overwhelming.

Indeed, that was one of the first things I tried to resolve the issue. Flushing had no measurable effect as far as I recall. The hardware for this project has since been disassembled so no further testing can be done.

I had some issues with certain RS-232 hardware.  Apparently the hardware can do some weird things with serial buffers and I even had lockups when trying to flush buffers with adapters of certain manufacturers.

I only say so because I've never encountered the problems you've listed with VISA (Other problems yes, but these ones no).  I've always beena ble to get sub-MS or near-ms responsiveness with the appropriate baud settings.

Have you tried adding a "flush serial buffer" primitive with your code to speed things up?

There are some UART chips which behave different to others (Especially when dealing with USB-RS232 converters).

I've had success with that in the past.

Well I'd guess that the compiler doesn't know yet that the VI guarantees the same output object type as the input.  I agree that this should work, but the compiler needs to check for situations where it KNOWS the type will be maintained abd it seems to be lacking here.

I would say that you should file a bug report.

 

shoneil: In this particular case, I'm talking about how many pipeline segments the child class uses in its override VI. If the parent specifies 2 feedforward nodes, the caller will be expecting that it takes two iterations to move data through the pipeline. If the child takes three iterations, it will be out of sync with the rest of the program. In a straight linear program, that doesn't matter, but if you have two parallel pipes where the results get merged at the end of the pipes, you need both pipes to be the same length.

 

 

@AQ

Thanks.  The pipelining (although it WAS mentioned previously) helps clear up at least one concrete case for this that I can fully appreciate.  I think I get the general gist of it now.  I've had my own problems with pipelining FPGA code so I can appreciate how this would be a great benefit.  Thanks.

I've spent quite some time investigating the functionality of the 3D picture and I question whether it's worth a "proper" OpenGL wrapper....

There's a LOT of undocumented but official (Yeah, the help sucks) functionality int he 3D picture control.  Did anyone know that you can share the geometry data between objects but still scale then individually?  This allows memory-efficient implementation of multiple copies of a single object for example.  Or even proper documentation of the different texturing formats available would be cool (I've already found out through trial and error).  Maybe they're all already in the help but for the life of me I could never find them....

Shane.

Shane, did you attach the correct image?

 

Your description mostly matches the picture, but not quite as I see it. Is the upper the curve and the bottom the text, or should there be an upper?

 

Why did you need to texture the curve, surely the quad rotated so it was on its side would have done the same thing?

Yup, it's the correct image.

The curve (Upper 2/3rd of the picture is a single Quad with the curve applied as a texture (Generated using 2D picture controls BTW)

The middle part (The comour bar with varying intensities) was prohibitively expensive to redraw with traditional 2D picture control.  Therea re a fixed number of pixels on the detector (in this case it was 256) but the scaling and interpolation coupled with the vertical stretching of the colours was very time consuming on a 2D control.  With the 3D picture control it was lightning fast.  It was a simple input of 256 Colour values (which need to be modified for intensity) and OpenGL does the rest.

The botton part (The numbers) is, similarly to the upper part simply a Quad with a texture (which was again generated with the traditional 2D picture controls) applied.  Both the upper and lower parts were sufficiently fast to redraw with the 2D picture control (and subsequently applied to the 3D picture).  The middle part (The coloured part) was not.

Shane.

I am having trouble following the discussion.

Since when does the execution time of a program belong to it's compile-time definition.  Yeah, for FPGA I can grok that but this can be done by folding possible DD calls into a case with each "DD" VI present.  If timing is maintained then good, if not then boohoo, compile error.  I just don't get WHY this would be a job of the compiler outside of FPGA.

I'm not trolling, I just have the feeling I'm missing something important here.

Shane.

I've misused the 3D picture control as a 2D display area in the past.  Texture scaling is so much more efficient it's just nor funny any more.

Three separate 3D objects.  Upper is a simply Quad with texture applied, middle is another quad with a linearly interpolated and vertically copied texture and the bottom one is again a quad with simply texture applied.  It was a little tricky at first making sure the first and third objects had the same texture size as dispaly pixels (to prevent blending) but it worked quite well and was way way faster than anything equivalent in 2D.

Shane.

More like the Application property "All VIs in Memory", then loop over "Open VI Reference" and get their execution state....

Abort those you don't want to leave running and don't forget to close your references properly....

I would say that you need a base List class for each different datatype you want to support.  If you do it via inheritance then your String class still has a method to insert Objects which can violate the "String" idea and might lead to problems elsewhere.  It's just not a clean implementation.  This (in current LVOOP) requires more or less a COPY of the  base class for String, DBL, LVOOP Object and so on.  If you want strict typing to a specific LVOOP class, then you need a base class for that otherwise your back door "LVObject) will remain open always.

Either that or simply input EVERYTHING as an object.  Write a set of simple wrapper classes (Yeah, it's a pain) and simply use the LVOOP insert everywhere.  You can define the Methods Insert (String) if you like, but I would have them use the LVOOP method in the background.

Templates create (if I'm not mistaken) new entities from a generic data type which shares no inheritance relationship to it's cousins.  This is similar to simply replacing the datatype of the base class in your example.  Instead of having some "void" datatype, simply create a template class with String and replace as required. Would it be nice if this could be automated / sped up with LV, sure.  That's maybe a good suggestion for the Idea Exchange.

For me Templates are (regarding the end result) similar to my first point above (Different base classes for each datatype).  Sometimes we get so LVOOPy in our heads we try to do everyhting WITHIN the Hierarchy.  Sometimes the answer is to copy the hierarchy and be done with it.  Create the new classes as required instead of trying to cover all bases from the beginning.

And yeah, I'm always traing to over-inherit such functionality myself.

Just my 2c.

Shane.

And using a class instead of input fields doesn't work because.......

Sounds like you need to fire that second-rate subclass designer   Just joking of course -- the goal of this language feature is to help convey information to developers about the intent of subclass design -- to help you implement the correct things. Not make things hard.

Your proposed enforcement is an illusion.  Due to the code not having any interface representation it may never be executed.  Not being able to compile a class just because of a missing VI prototype which is (quite possibly) never called seems seriously flawed to me.

Your proposal sounds like my wife.  She often not only wants me to do something (lets think of this as the interface) but she also wants me do do it her way (your enforcement) even though this has no bearing on the start or end status of the operation.  I've never had the spontaneous idea that this was a good thing.  When finished, if she asks me if I did it "her way" then of course the temptation is to say "Of course dear" event hough you know it's not true.  If a class is in the position to do WHAT you want, why is it important that it does it your way?

The ability to aggregate several statics into a single selector in the palettes exists through poly VIs. That's a mechanism that could be more elegant, IMHO, but it does work if polymorphism in the editor is your concern.

I think here we may have some significant common ground.

Regarding overloading: From a user point of view:

If you already have a specific object wired up in your program (with static "Init" function following the object constant) and you want up change the object type then you also have to go and search for the "Init" function for the new class, it won't update automatically because it's got a different name.  I don't actually care what name it has, I'd just like such operations to automatically find the related VI for my new class.  I would inagine some secondary identifier for class functions aside from the filename, like "Ability" or something which would allow the IDE (And only the IDE) to perform such swap-out operations on otherwise unrelated class functions.

That's all, it's not a major headache, it's not a showstopper it's just behaviour I run into all the time where I think it could be solved so much easier.

Shane.

PS I think there's some common ground between this idea and Jack's also.  Adding "Ability" tags for static VIs and telling child classes they MUST IMPLEMENT those abilities reaches the same target without having to have functions with the same name and different connector panes, no?

I don't see a FPGA reference being passed between the nodes being used.  The image os of the host VI and not the FPGA VI, right?

OR did the snippet simply create property nodes for your terminals.... That's kind of confusing me a little.....

How does your host VI look?

Shane