Thanks for the response. Unfortunately, the LV courses are one or two
weeks long.
Long enough to learn the language, but not long enough to get experience in
building applications the size and complexity of yours.
It sounds like you are familiar with mutexes. Your multiple reader
scenario is a
technique that we also use inside of LV. As you know two threads should
never be
in critical section at once. There were a few mistakes when LV was
first released
with multithreading support that would allow for that to occur. These problems
took awhile to be reported, and when we brought a large application in
to debug,
we believe we resolved the bugs there. We are still tuning the behavior on
multi-processor systems. Most recently, we are paying attention to
cache line
size to see that writes from one processor don't flush the cached memory making
the read of the other processor very expensive.
It doesn't surprise me that you had some range checking code that could
be written
more efficiently in C than in LV. It would surprise me if some
profiling and tuning
wouldn't make the LV code run close to the C speed. Typically its the automatic
memory management that causes the speed difference.
>
> What about portability, if you're using ActiveX controls? I also tried to use an
> ActiveX-Text control to implement a compfortable Macro-Editor for our Application, but
> once the ActiveX got it's focus it did not release it any more. All kbd-typed-text went
> to the ActiveX and not to the selected Textbox. (Our VIs have no window decoration,
> since they occupy the complete screen.). Usable? No.
>
ActiveX controls do affect portability. Unfortunately, we can't always have
every feature that the ActiveX controls do. We added ActiveX controls, DLL
access, and the like so that engineers can make their own tradeoffs between
getting the project done and being portable to other platforms. Unfortunately,
building an ActiveX container isn't a very easy thing to do. I believe the
limitation that you see when you hide title-bar is hidden will be fixed in
the next release. Most of those limitations were due to the fact that
we tried
to leverage MFC to get the container completed. The new implementation doesn't
use MFC.
....
>
> Then you probably have multiple screen desktop with 21" each 😉 ? Ok. Some one is
> printing its the code, some one else is just working with the online display. I'm
> prefering my desktop with 2 x 1 meters to keep several printouts of header files,
> pieces of sourcecode and documentation avaliable. Thus i've the overview without
> clicking, moving windows, etc. just with a little turn of my head.
>
Actually, I've only got one 19" monitor, but then I've got a second
computer, or
perhaps a first computer, a Mac, that has a 17" monitor. I don't know
of any
programmers that print out their source code except to print out small sections
for a code review, and even those are increasingly done online where reference
material is readily available. When I first started working at NI, some
of the
engineers had a partial printout of LV 1 that they used as a monitor
stand. I
suspect that today the printed LV source code would make a pretty good desk.
Anyway, like in textual programs, the key is modularity, and that has been
difficult with UI VIs because access was only allowed from the diagram
of that
VI. That will soon change.
>
> For me it's is not only the second time doing this job. (The first implementation of
> this software that i realized, was a redesign of an existing system, when i was phd
> student at the university of darmstadt three years ago.) And when i started at TGS
> everybody in this company told me about the nice features and the great performance of
> LV, its easy way of programming etc. and i suspected the suitability of LV for this
> project. As a newbie i had no vote for that project. Any software design tool that
> places a lot of uncontrollable overhead in the background of the application could lead
> into the same situation.
>
Agreed that high level tools and languages always remove some
flexibility, but
I still believe that LV is a suitable tool for doing a project such as yours.
The project that discovered the initial bugs in the LV5 multithreading was
a test application with lots of UI displays, a 10ms loop time, and hundreds
or parameters to be read, range checked, and logged. They also used a dual
processor computer and had some DLL calls here and there for performance
reasons. The thing being tested was a turbine engine, freshly overhauled,
being put through its paces to determine if it passed. For larger, more
complicated engines, they didn't use LV. They had custom VME equipment and
SGI workstations for their higher end systems, but manpower to build those
systems was much higher. As computers get faster and LV MP support
improves, they may be able to move additional systems to LV. They can always
choose a more flexible system, but it made economical sense for them to use
a higher level tool to cut development time.
You have lots of experience with other tools, so there is no reason why you
should be limited on what tool you use. I hate it when this happens.
They tell the engineer that they can only use LV, rather than explain the
reason why they want them to use it. I hope that you have a chance to
use LV again in the future and will look at all of the new features and
updates that are going into it. It will never be as flexible as what can
be done in a totally custom HW/SW job, but I believe your initial advice
about measuring the temperature in a cup of tea sells it far too short.
Several years ago I was able to visit Darmstadt for a technical conference.
If you ever get a chance, I'd encourage you to come to Austin for NIWeek.
You will see what can be done with LV and NI tools, and we can continue
our discussion person-to-person if you wish.
Greg McKaskle
