flintstone

It seems this was never really resolved (or nothing more happened?) but since I made some general statements in this thread I want to give a final feedback: Of course it wasn't quite possible to switch the project away from LV but I went the other way and left the company and thus the LV world by end of June to work in a C/Matlab/[whatever gets the job done] environment. After nearly three months in my new company I totally stand by my statements regarding reliability of the development environment and long-term support. Both these issues are very big topics in my new company, they don't come easily but we can manage them. It feels like being back in the driver seat again. So thanks to everybody who helped me in this forum, I wish you all the best and hope that I will never again need support on lavag. Cheers, flintstone

Somehow my interest in new programming languages has gone mostly, in most cases it's anyway C-style syntax and looking up stuff in the documentation. I wrote several Python programs for my old company and I couldn't do a "Hello World" now because I forget everything about it so quickly. I'll go for the simply and powerful stuff: VHDL together with C/C++ to implement application-specific soft-core processors in FPGAs ... this is something which I'd find extremely interesting, as there's almost everything: from hardware design to driver implementation to user interfacing.

I guess it would have some resemblence to languages like VHDL, Verilog, SystemC with in- and out- ports for VIs and some means of describing the connections. For the layout something XML-based. Logic description and layout description separated in two files. Regarding mutli-threading and message-passing Erlang has a good name.

@mje: This is really one of the lessons of my LV developer time (which is to end soon :) ): Don't insist on doing it the way you planned to do it if you run into a LV bug, work around. E.g. using a typedef if there is a bug that breaks typedefs in this very situation (I stressed your nerves here enough with my FPGA problems) just doesn't get the job done. I insist on my point that LV is quite a buggy dev environment and the lesson is: the developer has to adapt to it. Or find himself a different job .

No, UDP is really just packets flying through the network without any state being maintained in the network stack on both sides (you can do that then in your application ). Therefore I don't understand the point in Open and Close VIs for UDP (but it would be logical to do all the necessary socket stuff in there). I would try with netcat on the very machine where this program should run if I can open a UDP connection to the remote party you set in the VI to verify it is not a network problem, then I would remove the UDP Write and just see if Open and Close work and if nothing works I'd try with sending data via UDP between two LV programs sitting on the same box.

For us they work on middle ground, we have intermittent software failures due to NSVs not being reachable in between. In this case restarting the component (but not the SV Engine) brings us back to live. Some other workpackage reported incidents where the SV Engine lost all it's values and needed to be restarted, but I didn't see this personally. But actually we're using the SVE for a system size for which it clearly wasn't designed.

... and still the definition of an "int" in the C standard beats about every definition in the LV standard by it's mere existence.

Wasn't aware that there is a separate LV bugs section in this forum so I'd like to reference our cluster value resorting problem http://lavag.org/topic/16689-my-lvlib-pathsurls-are-obviously-absolute/ . Yeah, as mentioned there, this broke one of our releases so if "dock it's pay" means we can get discount on the next NI order I'm definitly in for it.

I guess I would try with bucket sorting the pixels. 2^24 buckets should not make a problem on a normal machine and bucket sorting is a very easy algorithm.

Give some more Information, what are the characteristics of your input picture, what result do you have to deliver. The additional toolkit will cost you money, somehow I don't think this is an option for you.

You could also look at it as the position where the decimal point is set. If you have (word length == integer length) then you have the decimal point just after the last bit so this comes out as a normal integer. With your settings you get a single flip-flop which is interpreted as bit 1 of an integer, therefore you get the two values 0 = 0*2^1 and 2 = 1*2^1.

Final solution will be to only use basic types on the front panel instead of a user defined type.

NI has been contacted, let's see.

The problem with resorted cluster elements returned, this time in the way that I feared most, compilation is not broken so the system was built and deployed but is not usable now. Since there seems to be a problem somewhere in one of our base classes (not the library which showed the absolute/relative path problem) which has not yet gone away we can surely now go to ask NI for help. Yes, I'm frustrated and maybe a bit too harsh sometimes. But I really had a number of problems which cost me a lot of time due so small programming bugs in NI software, see e.g. here http://lavag.org/topic/16218-lv-fpga-master-typedef-not-found-issue/ . And my decision to throw it out right away before more code is developed for this does not only come from my antipathy but also from the fact that we are building a machine which is supposed to run for 30 years and already within 3 years we had problems which required us to change and/or the LV software environment. The lack of a long-term support version in which small issues like this FPGA thing are fixed is imo a no-go for a serious long-term software project. Compare this to other development environments where people keep the build environment together with the code to make sure that they can still fix issues years later. Compare this to the C/C++ world where 20 year old code (if done properly) will still work. My grief is not only that a basic construct like a cluster is making so many problems, it's also that I don't see how we can build a durable solution. Something which I put there and then it just works.

As you saw I tried to reproduce the problem but I didn't manage. I'm with you that this is the kind of bugs that are almost impossible to find and fix. So even worse, I have a programming environment that most probably contains a bug that can destroy my projects. With a dozen different software projects and hundreds of VIs created by us as well as > 1000 VIs created by an external partner we cannot manage to do manual checks. And, sorry to say, I dispute that NI is one of the better suppliers. I've worked in other environments and had not even half the number of problems. If I were the software manager in our project I would eat the bitter pill rather now than later and throw out all the LV code to replace it with C/C++ . This is an environment which is very stable and where long term support is provided.