shoneill

I agree with this statement 100%. It's just weird to find out that some really clever people were born WAY after me. It leaves the thought "Well what the heck have I been doing all that time?" which if course is completely silly because I was out drinking for most of my University life..... I know exactly what I've been doing

You're not the only one. I also remember PLAYING asteroids if that makes you feel and better.....

I remember reading about Asteroids in a C´t article. They mentioned how the graphics output was vector-based and not raster-based as it is today. They had a competition to re-create the game. It was cool.

This reminds me of swapping out user event references from within an event structure.

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.

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

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.

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.

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.

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

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.