Neil Pate

Yes, but if the firewall is totally off then it will not help.

Check your Windows firewall. Turn it off completely and see if this fixes it, if it does then you perhaps need to add the LabVIEW.exe process to the whitelist for UDP. If this does not work, check the firewall again. Seriously I have lost hours debugging these kinds of issues only to find out it is usually Windows protecting me from myself.

Sounds great Jeremy, This will be my first trip across the pond to Austin. Do you have any recommendations for hotels in the area? I know La Quinta Inn has been suggested, do you think is this a reasonable selection? Looking forward to seeing everybody soon.

Sometimes this error message could occur if some other code in the project is broken. Very often it is a class VI that is not actually used in the main code (say a test VI that has been broken as the API changed, and the dev was a bit too lazy to go back and re-run all the tests). When I get these errors I start pruning the main VI until the build works again, however this is very timeconsuming (and frustrating process) and I would say that most of the time the error is related to one of the recent things I changed.

I used to see it quite a bit last year when there was the spam about watching videos online. I thought perhaps they were related?

Yes I have seen this frequently over the last week.

I think there may be an error in the library. The "main" VI is not actually part of the library and the library references a file that does not exist, so I presume some form of renaming (outside the IDE) has gone on? After fixing this I tried this on the one TIFF file I have but it is compressed and looking at the code it appears there is not yet support for compressed TIFFs.

Yamaeda, I do not know what is wrong with your code, but can offer you this advice. To the best of my knowledge .NET calls are actually very expensive in LabVIEW, a single call can be something like a few milliseconds! Now, it was a few versions of LabVIEW ago that I had this problem, but my understanding is that it is just the "managed" way of how .NET and LabVIEW operates that this is likely to always be the case. If you are trying to render lots of stuff I expect you will have lots of .NET calls so just be careful with performance. For reference, I was using SFML, it seemed like quite a nice library but performance was terrible from within LabVIEW.

.MOD for true authenticity :-) BASSMOD does all the hard work, I have just wrapped the DLL.

Now with battle music and events posted to an Event Structure directly from within SDL (yay no more polling!), and the initial introduction of some helper classes to wrap the SDL pointers etc. http://screencast.com/t/gJVSNrtrpyCY

Those outcomes are possibilities, not guarantees. Not every application has 8000 VIs, and in a lot of situations the careful use of libraries can be really beneficial. I am not ready to give up on them yet.

Massive no from me on LLBs. I do not need to distribute my code like that, so really have no purpose for them. As others have pointed out, no namespacing, no access scope makes these a stale technology (for my situation at least) in LabVIEW. I still do use libraries though (and classes of course, which are also libraries), even with all the pain associated with the loading the entire contents etc. It troubles me too much me to have to manually namespace every VI, so I am not sure I will move away from libraries or some form of them any time soon.

That's a bit neater...

OK, so the Slylandro now has some food :-) This is just a silly video of me controlling both the ship and the asteroid (now with animation) with an xbox controller. http://screencast.com/t/Z2s6ZDvFae The jing video messes up the frame-rate, it is buttery smooth without the video being recorded. Next step: battle music!

I loved the bit of risk associated with the chance that you could accidently teleport into the planet

Pesky indeed! My favourite was the Utwig, although the Vux could be deadly (and terribly annoying) in the right hands.

Darren, that is quite a few long nights away. To whet your appetite, have many Slylandros!

Yes I would really like to get OpenGL working as part of a library. I have some stuff already, but its old-school OpenGL and very dusty!

I know very little about the Simulation toolkit, or what you are trying to model, but looking at your diagram have you not perhaps put the feedback node in the wrong place? Do you really want the output from Summation 3 to be delayed before passing it into your Transfer Function? Try putting the feedback node only in the path back to Transfer Function 8.

Try insert a feedback node in your cycle, this acts as a delay of one sample and allows you to take outputs back into inputs in the same bit of code.

Most definitely. It is so great that SC2 is effectively open source like that, I wish lots more old games were. Even the resources like .pngs etc are GPL I think.

Thanks, No, I also just saw the youtube video last week, complete coincidence. My (probably very unrealistic) initial goal is actually to recreate SC2 melee in LabVIEW. A secondary goal for later is to get OpenGL working nicely with LabVIEW and SDL. I have started this bit several times and never really got enough momentum to keep development up.

It begins... ignore the messy code in the background, just proof of concept stuff.

Million-to-one chances...crop up nine times out of ten(especially on a Friday)

You are right, but this is probably less true on FPGA. As there is no data-flow dependency on this I would be very surprised if it did not reliably get cleared at the start of each iteration of the acquisition loop. Defensive programming techniques are my preference so I would probably introduce some fake data-flow dependency to clear it at the start of each iteration.