MikaelH

I surely can, and I can use the “Set Affinity…” to share the CPUs evenly. Cheers, Mikael

I'll be staying at the Hilton Sunday evening to Friday evening

I manage to slove the problem By opening one class at a time and use the Right click "Save All (this Class)" feature I managed to get the build working again. I got so frustrating that I have to stop developing just because LV is building an exectuable, so I did this: Anybody tried it as well? So far it looks like it working, since the building of an executable only loads one core, I still have 3 others to play with Cheers, Mikael

Thanks. I'm currently recompiling all classes in memory a couple at time, but when you have 105 Instrument classes, it takes some time to do this. I've been working on this the whole day:( . //Mikael

If I don't remember wrong, by adding a normal wait=0, that will cause LV to switch thread, and that's probably why you get it working. //Mikael

Thanks, I also get a LV crash when I just try to mass compile all VIs (Ctrl-Shift-Run), so it must be some linking problem. I just have to continue looking for it. The fun thing it runs perfectly in the development environment. Cheers, Mikael

Hi I've made a change in my application to create all instrument objects using the Factory design pattern, and now suddenly I can’t build an executable. When I start the build, it finishes like this after a minute or so. It normally takes 20 minutes to build this application, wonder if this would be acceptable in any other programming language. Cheers, Mikael

I thought that the GDS Project Window Explorer hooks caused the delay in editing, but I’m now trying without GDS activated, and now it takes 15 seconds for LV to response for a simple edit, and when I now press Ctrl-Z it takes >30 seconds and of cause reordering the windows in Z-position. BTW my project file is about 870kB, is that a lot? Does anyone know if it's possible to disable the Conflict Checking in the project? //Mikael

Did you try to open the VI (when it was slow), without the project explorer? My issue is definitely tied into the usage of the Project window. Cheers, Mikael

I don’t mind sending the code for doing comparison to e.g. NI. But if the code is very similar, I guess AddQ will refuse J I’m quite sure that the next release of AddQ IDE will have all VIs rewritten or at least all connector pane wiring changed and control/indicator size and positioning. I’m not sure what Symbios next step will be in this matter. I must say I got inspired by the competition and got me working harder on our next version of GDS that we’ll release to NI-week. BTW, if you want to help out beta testing … //Mikael

If you like to test the latest beta version of GDS, you can download it here: http://goop.endevo.net/GDS/GDS_Q1O_2009.zip http://goop.endevo.net/GDS/GDS_Q1R_2009.zip The activation key is: NINI-WEEK-2010-BETA-BETA Cheers, Mikael

But is it okay to customize the Error In so it have the same (no standard) size/layout as a competitor/former employer? Why I came to think about the Error cluster was that in one of my of GDS VIs, I happened to modify the standard Error cluster by accident, and for some reason AddQ have done the exact same thing. Of cause it’s just a coincident but a pretty fun one ;-) Cheers, Mikael

I would do it in the other order, The 715 should derive from 620, since I would guess that 715 have the same functions as 620 plus some additional functions, i.e. extending the 620 type. Or maybe create an abstract base class “ARINC” and then derive CEI-620 and CEI-715 from this class, if the won't share so much code. //Mikael

Hi The initial approach is, If you want to send data from many to one use the queues , but when you want send data from one to many use notifiers. Or have a look at the design pattern Observer:

Mattias, I can see that you have rewritten lot of the code, but from scratch.... It’s of cause just by coincident controls on the front panel have the same pixel coordinates, e.g. like this: ..or that the connector pane are almost identical, e.g. like this: Cheers, Mikael

I have one idea. Try to stop the Service called: IPSec, does it work them? The IPSec service controls Network access that your IT department can push onto your computer; they might stop access of your computer to any other subnet than your company's local network. This is one way for them to limit your internet access. I've had that problem myself. If it works when IPSec is turned off, have your IT department to add the 192.168.0.x in the allowed subnets. Cheers, Mikael

Hi I’ve got the question if Symbio has stopped the development of GOOP Development Suite(GDS), and if AddQ has bought the rights of the framework. But I like to inform you all that, that is NOT the case. Mattias and his colleagues left Symbio (former Endevo) to join a new company called AddQ. Symbio will release a new version of GDS with our version of DVR class template at NI-week. If you want to check out and try our proposed DVR template have a look here: Symbios DVR template ..or check out this video. Cheers, Mikael

Question, are use using any special characters in the TCP/IP strings you send, i.e. ASCII code above 127? //Mikael

Good on you Mattias Cheers, Mikael

Hi Here is the latest beta version of GOOP Development Suite, which contains the DVR class templates. http://goop.endevo.net/GDS/GDS_Q1I_2009.zip (only for LV 2009) If you already have a version of GDS installed just move the Endevo folder under “C:\Program Files\National Instruments\LabVIEW 2009\resource\Framework\Providers” to a safe location before installing this beta version. The activation key is: NINI-WEEK-2010-BETA-BETA To view the new class templates, select the new EndevoGOOP400-class provider, and then create some classes. I’ve made a quick video demonstration how to create classes of this template and how they work. http://goop.endevo.net//GDS/videos/GOOP4Demo Any feedback is really appreciated. Cheers, Mikael

Hi John I'll post the link in a couple of days, with a new beta version of GDS. This version contains a more complete version of a DVR template. Cheers, Mikael

Nice, but I guess it will take at least 14 month until we'll see any of these features in LV :-) --Mikael

You could of cuase just wire a reference for an additional Graph from you main VI down to the sub VI, so every time the graph in the Sub VI gets updated the "Copy" graph get the same updates. //Mikael

I've sent this issue direct to one of the LabVIEW Developers to have a look at. Of cause they are a bit busy right now...but I'll keep you posted on the progress. FYI The Autosave doesn’t fix my problem. I use tons of Typedefs, most of them belonging to classes. Many of my application are using Tab with lots and controls on then, so that could be a problem. But it's still fast when editing it without the project windows open. So it has to be something to do with the project window, I would guess the Dependencies or similar. Cheers, Mikael

I'm about to BTW have you tried not using the Project Explorer for the FPGA development, is it faster then ? //Mikael