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.

My definition of "Code Smell" is completely different to that in the article. To me it is a behaviour that indicates a particular bug or type of bug.

They are already here if you are talking about pre-processor commands - Conditional Disable. But I feel your pain, not necessarily with FORTRAN, but certainly C where everyone has their own definition of INT and "macros" that can be considered cryptographically secure.

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

So since we don't have any further input on this it will seemingly be unresolved.

This really gives me a great feeling about building a big and expensive system with this software ...

I'm sure now that this is really the problem, I wanted to do local tests on a different machine with a pre-synthesized bitstream and I saw the problem again. I reproduced the build environment path structure with a USB key and it worked.

The guys that manage the automated build system really don't like this but at least I can point them to this thread so they can be angry at the manufacturer who does not provide a bugfix for this and not at me .

Regarding the "Disconnect Type Definitions" option, do you mean to do that for the host application or for the FPGA (where I don't find the option in the build settings)? For now it does not matter anyway, I want to run my Test VI from the LV IDE until I have debugged my FPGA implementation.

Cheers,

flintstone

Since I cannot reproduce it with the few attempts I tried I'll have to wait.

For the dialog: Yes, I know it, I also find it confusing but this should not be the problem.

I'm still investigating and as I said I'll have to ask my colleague but we never changed the relative positions of the lvlib and its VIs. We changed the drive to which we check the whole project out, so I do not see a reason to use an absolute path there.

We had a change of the VM infrastructure we are working on recently and also switched the drive where the project is located so this would match the information in your post. I will test this.

Thanks!

The paths in the lvlib file are not Windows path format so I guess they are symbolic, too. My colleague is already on Easter holidays so I'll have to wait until next week. I doubt he did exactly this but maybe he did something similar so thanks for the hint.

Thanks for having a look, unfortunately I cannot switch to newer versions due to the project policy.

Yes, you can find a before-after comparison below. I took out all Item sections but one and replaced folder names there with dlevel1 ... dlevel6 up to the directory where the lvlib file is located.

Thanks and cheers,

flinstone

XML START

BEFORE:

-------------------------------------------------------------------------------------------------------------------
<?xml version='1.0' encoding='UTF-8'?>
<Library LVVersion="10008000">
 <Property Name="NI.Lib.Icon" Type="Bin">%!#!!!!!!!)!"1!&!!!-!%!!!@````]!!!!"!!%!!!(]!!!*Q(C=>7R=2MR%!81N=?"5X<A91P<!FNA#^M#5Y6M96NA"R[WM#WQ"<9A0ZYR'E?G!WPM1$AN>@S(!ZZQG&0%VLZ'@)H8:_X<^P(^7@8H4Y;"`NX;8JZPUX@@MJXC]C.3I6K5S(F/^DHTE)R`ZS%@?]J;XP/5N<XH*3VSEJ?]Z#F0?=J4HP+5<Y=]Z#%0/>+9@%QU"BU$D-YI-4[':XC':XB]D?%:HO%:HO(2*9:H?):H?)<(<4%]QT-]QT-]BNIEMRVSHO%R@$20]T20]T30+;.Z'K".VA:OAW"%O^B/GK>ZGM>J.%`T.%`T.)`,U4T.UTT.UTROW6;F.]XDE0-9*IKH?)KH?)L(U&%]R6-]R6-]JIPC+:[#+"/7Q2'CX&1[F#`&5TR_2@%54`%54`'YN$WBWF<GI8E==JE3:E3:E-51E4`)E4`)EDW%D?:)H?:)H?5Q6S:-]S:-A;6,42RIMX:A[J3"Z`'S*<?HV*MENS.C<>Z9GT,7:IOVC7*NDFA00><$D0719CV_L%7.N6CR&C(7(R=,(1M4;Z*9.T][RNXH46X62:X632X61?X6H(L8_ZYP^`D>LP&^8K.S_53Z`-Z4K>4()`(/"Q/M>`P9@<P<U'PDH?8AA`XUMPTP_EXOF`[8`Q<IT0]?OYVOA(5/(_Z!!!!!!</Property>
 <Property Name="NI.Lib.Version" Type="Str">1.0.0.0</Property>
 <Item Name="Timing" Type="Folder">
   <Item Name="TIME_msecTimerTimeout.vi" Type="VI" URL="../Timing/TIME_msecTimerTimeout.vi"/>
 </Item>
</Library>
-------------------------------------------------------------------------------------------------------------------



AFTER:

-------------------------------------------------------------------------------------------------------------------
<?xml version='1.0' encoding='UTF-8'?>
<Library LVVersion="10008000">
 <Property Name="NI.Lib.Icon" Type="Bin">%!#!!!!!!!)!"1!&!!!-!%!!!@````]!!!!"!!%!!!(]!!!*Q(C=>7R=2MR%!81N=?"5X<A91P<!FNA#^M#5Y6M96NA"R[WM#WQ"<9A0ZYR'E?G!WPM1$AN>@S(!ZZQG&0%VLZ'@)H8:_X<^P(^7@8H4Y;"`NX;8JZPUX@@MJXC]C.3I6K5S(F/^DHTE)R`ZS%@?]J;XP/5N<XH*3VSEJ?]Z#F0?=J4HP+5<Y=]Z#%0/>+9@%QU"BU$D-YI-4[':XC':XB]D?%:HO%:HO(2*9:H?):H?)<(<4%]QT-]QT-]BNIEMRVSHO%R@$20]T20]T30+;.Z'K".VA:OAW"%O^B/GK>ZGM>J.%`T.%`T.)`,U4T.UTT.UTROW6;F.]XDE0-9*IKH?)KH?)L(U&%]R6-]R6-]JIPC+:[#+"/7Q2'CX&1[F#`&5TR_2@%54`%54`'YN$WBWF<GI8E==JE3:E3:E-51E4`)E4`)EDW%D?:)H?:)H?5Q6S:-]S:-A;6,42RIMX:A[J3"Z`'S*<?HV*MENS.C<>Z9GT,7:IOVC7*NDFA00><$D0719CV_L%7.N6CR&C(7(R=,(1M4;Z*9.T][RNXH46X62:X632X61?X6H(L8_ZYP^`D>LP&^8K.S_53Z`-Z4K>4()`(/"Q/M>`P9@<P<U'PDH?8AA`XUMPTP_EXOF`[8`Q<IT0]?OYVOA(5/(_Z!!!!!!</Property>
 <Property Name="NI.Lib.Version" Type="Str">1.0.0.0</Property>
 <Item Name="Timing" Type="Folder">
   <Item Name="TIME_msecTimerTimeout.vi" Type="VI" URL="/dlevel1/dlevel2/dlevel3/dlevel4/dlevel5/dlevel6/Timing/TIME_msecTimerTimeout.vi"/>
 </Item>
</Library>
-------------------------------------------------------------------------------------------------------------------

With SVN diffs I could find the revision where the change from relative to absolute paths happened. My colleague did this commit after having fixed another very strange problem where cluster elements were resorted and we did not know how this happened.

This all gives me an extremely bad feeling, my fear is that the cluster resorting and the relative/absolute path problems are only symptoms of some underlying problem and we cannot trust the code as it is now because we only saw the effects that would actually break something but if e.g. cluster resorting has happened with values that have the same type then the error will only be found by misbehavior of the actual device or code inspection. Both is not desired .

Cheers,

flintstone

Hi,

I know checked vs an earlier revision of the projects that would work with automatic build (again in the text editor) and there are relative paths used for the VIs of the lib. So at least I know now how to fix it for the release which is due now.

But since I'm 150% sure that neither I nor my colleague decided to make these paths absolute (and I also do not find the corresponding setting in the GUI) I assume it must have been done automagically by LV. And I have to say, this is not acceptable. I cannot check manually the paths before handing this over for automatic build.

Maybe someone can identify possible errors we did or give a hint how to force LV to use relative paths everywhere and anytime (apart from the "standard libraries" of course).

Cheers,

flintstone