Jump to content

flintstone

Members
  • Content Count

    50
  • Joined

  • Last visited

Community Reputation

3

About flintstone

  • Rank
    Very Active

LabVIEW Information

  • Version
    LabVIEW 2010
  • Since
    2011

Recent Profile Visitors

902 profile views
  1. 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
  2. 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.
  3. 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.
  4. @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 .
  5. 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
  6. 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.
  7. ... and still the definition of an "int" in the C standard beats about every definition in the LV standard by it's mere existence.
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. Final solution will be to only use basic types on the front panel instead of a user defined type.
  13. 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/1621
  14. 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
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.