LabVIEW
NI: Get to grips with Fundamental LV Shortcomings.
Ben wrote:
gierove wrote " ...but have no success finding all my Shared variables:"
If you are looking for ALL of your shared variables the you can serach on that.
..............
Ben
Hello Ben,
Thanks for your feedback.
Shared Variables.
_______________
Yes, I have seen the search option you are showing here. However, since my app uses 100 + Shared Network Variables to send status data over the net (in a Low Priority Thread), I get a tremendous amount of matches that are irrelevant since this search as you said matches ** all ** Shared vars The app writes status to Single Process Shared Variables with Real Time FIFO (for speed) in the Controll Threads (there are 9 of them).
I need to be able to search for one particular Shared Var !
Yes, Shared Variables may be "bleeding edge". However, their implementation, at least in 8.2, is very good from my experience, and they save a lot of coding.
I tried many of the traditional ways of sending data using TCP/IP over the net. None of the methods I tried where able to recover if the TCP/IP connection was broken at any time. The app transfers this non-critical Status Info using WLAN, and com. failures must be expected.
However, the Shared Variable communication always recovers after a broken connection. Since the 8.2 implementation of Shared Vars uses UDP and 8.5 uses TCP/IP, it can of course also be done with traditional LV programming, but my code would bloat !
State Diagram Toolkit
__________________
I was also very worried when 8.5 came out and I could not find anything about the State Diagram Toolkit! I have just deployed this mission critical Control System for a client, and must be able to continue to support him!
Nobody forces me to ugprade? Not quite: LV 8.2 is painfully slow when starting any app. from the Project Explorer that contains Shared Vars: It takes 3 + minutes to start my app to test it. Working with Shared vars is also extremely slow, with 15 - 20 seconds response time every time a change is done in a VI with lots of Shared vars. This is all fixed in LV 8.5. And that is good, but then I must upgrade....
The good news: I installed the State Diagram Toolkit under 8.5, and it does indeed work.
So in 8.5 I can work in parallell with both the State Diagram Toolkit and the State Chart Module. I have been playing around quite a bit with the State Chart Module, and it gives you a lot of control, and has a lot of Power. As said before, it is also let down by the inability to Navigate: Search for references to where Triggers and other resources are referenced / used ** in the Diagram **..
I will start a separate thread where I discuss how I have used the State Diagram Toolkit, and how these State Diagrams may be improved by using Orthogonal Substates, sub- and super-states in the State Chart Module. I am also investigating how Inter- State communication should be done in Synchronous State Charts (with Asynchronous State Charts it can be done with External Triggers).
Which by my standards and although I don't know Mike personally, I'm sure by his standrads too really counts as a small project!Taking into account that you know nothing about me or our application, your response seems very arrogante. There is a reason for the number of varibles we used, and they are used in a simple way: Sending status data over the network. I have never made any assumptions that LV is for small applications only. Our application has approx 300 VI's.
For some reasons I never felt the need to use Data Socket nor Shared Variables, despite that most of my applications are quite heavily networked. Data Socket was to buggy when it came out and Shared Variables simply had no good means to distribute them easily with a built application and were (are?) relying to much on a Windows only infrastructure for the server side. Rolf KalbermatterWe do indeed understand the difference between OO and Dataflow programming.
That aside, I am human, and I do make mistakes: Even if I had only ONE Shared Variable in my application: How can I find if this very variable is used in the wrong place if I cannot search for references to it?
I am all in favour of promoting good programming practices. However, that is not an excuse for, or not the same as, not supporting fundamental tools in the programming environment.
Hello AmiGos,
This thread really strikes a nerve, especially comments re: questionable need for StateDiagramming tools and Shared Variables!
A CS major, I'm bothered by some of the programming styles being marketed/encouraged by NI.
State Machines have reincarnated "GOTO" style programming, and the resulting mess needs an extra layer of documentation - "Enter the StateChart Module" (say goodbye to understandable source-code 
-)
The "wire-through" technique adds unnecessary wires, controls and dependencies - not to mention being misleading. See NIs SMTP w/attachment utils, and "Directory to Tree.vi" for "shipped" Examples of shift-buffered references - poor programmers fooled into making code significantly more complicated 
(but prettier in certain places.)
LV's class implementation is non-intuitive. 
They might have used the object/property paradigm already in use for VISA, ActiveX, NET and their own VI-server, but they created a totally unique graphic-interface. To me, "unique" means more to learn.
The clincher is NI's decision to go to all graphic icons which aren't intelligible in any language (except, of course "G".) After 16+ years of using LabVIEW I'm LOST in the File-palette - and it will be worse when other people's LV8.x programs start arriving at my screen.
LabVIEW 8.x syntax is harder to learn and read than 7.x - unnecessarily so.
LabVIEW is an old friend now. It's sad to see it developing bad habits and adopting "unique" for the sake of uniqueness. These trends create unnecessary burdens for "G"s friends.
Cheers.
Message Edited by tbd on 10-06-2007 06:56 PM
@tbd wrote:
Hello AmiGos,
............
"Enter the StateChart Module" (say goodbye to understandable source-code
...................
Hello,
Well, if you do not like State Charts, then you should not use them. Used in the right way and in the right places they do however communicate what the System does very well, and give a high level view of ** what ** the system does!
However, you do have a good point about the generated Source Code: It is har to follow for the State Diagram Toolkit, and not even visible for the State Chart Mpodule. (Yiu can rename the .lvsc file to a .llb file and open it and see the generated code, but it is not intuitive).
That is why these Navigation Tools ** must ** be fully implemented for these tools.
I do understand that G purists do not want to use these tools. However, many Hand-coding purists do not want to use GUI builders that generate code either, but code their GUI by hand. If we go way back, C was also banned by assembly languate purists!
Does that mean that we should stop the development?
No, but it should be done as a carfeully evaluated evolution process where one make sure that the tools that does generate code, does this in a way that can be traced by the supported tools. This is unfortunately not the case with the State Chart Module for the time being.
geirove wrote:However, you do have a good point about the generated Source Code: It is har to follow for the State Diagram Toolkit, and not even visible for the State Chart Mpodule. (Yiu can rename the .lvsc file to a .llb file and open it and see the generated code, but it is not intuitive).
That is why these Navigation Tools ** must ** be fully implemented for these tools.
I do understand that G purists do not want to use these tools. However, many Hand-coding purists do not want to use GUI builders that generate code either, but code their GUI by hand. If we go way back, C was also banned by assembly languate purists!
Does that mean that we should stop the development?
No, but it should be done as a carfeully evaluated evolution process where one make sure that the tools that does generate code, does this in a way that can be traced by the supported tools. This is unfortunately not the case with the State Chart Module for the time being.
Automated code generation will always have the attribute to create code that is hard to read and why shouldn't it. There is no point in taking I don't know how many hours to make such a tool create code that is correct in 99% of the cases (and yes reaching 100% is an utopie) and then spend 10 times as much time to make it generate that code in a manner that is easily human readable.
So does that mean you shouldn't use such tools? No but don't complain if the code looks not very neat. If neatness of code is important to you, and it is for me when it is about LabVIEW code, then those tools might simply be not the right thing for you. I have never seen automatically generated code that looks neat and clean, be it Visual C++ code Wizard, ATL, MFC, IDL or whatever. And frankly I wouldn't care in those cases as long as the code is correct. In LabVIEW I may be a bit more of a purist in that respect but I won't complain about the State Chart Toolkit but simply won't use it.
As to get 100% implementation of Navigation Tools that is also a criteria that can not be measured objectively nor does it mean the same for everybody. With the implementation of Shared Variables the whatever % coverage of those tools did not diminish one single %% for me and about 90% of other LabVIEW users since they didn't use them.
As a developer of that feature in LabVIEW I would already been quite proud that it did work more or less flawlessly and you could actually do something with it. Of course I would have a long list of things that would be nice to have, but there is always something called a deadline and priorization of tasks and if I want to keep my job as a programmer I should probably try to obey them as much as possible.
Shared variables being in fact an external technology to LabVIEW, it is not surprising to me that they do not as easily integrate in every single existing tool that existed already. First, one needs to implement a technology to even start using it. Requesting 100% functionality from the beginning is simply stating don't even try to start something like this since it involves development of the Shared Variable engine, an interface in LabVIEW for that, then interfaces in the engine to interact with LabVIEW back and forth. To expect all these things to materialize in the first or maybe second releases is simply not realistic. If you do that you say in principle don't even bother with new versions, since I won't accept them unless everything is 100% perfect and anybody trying to fullfill that request MUST fail.
I'm pretty sure that all those features are avaluated VERY carefully before a programmer even gets the task to start implementing it. That those in charge with these evaluation use other priorities and criteria than what you feel important can be frustrating at times but I'm pretty sure that complaining won't change to much about that. Suggestion is a much stronger tool in this respect.
Complaining here about the lack of such functionality will in almost all cases not bring you one single inch closer to it. Putting in a product suggestion goes actually a lot further in that respect and if you want to make sure it gets a higher attention, making people aware that this feature seems important to you and hoping they will also voice their support for this in the Product Suggestion center.
Rolf Kalbermatter
@tbd wrote:
LV's class implementation is non-intuitive.
LV Classes are nothing like VISA, ActiveX, .NET or VI Server. I agree that they are hard to understand, especially if you come from a by reference view of OO. To use them, you need to understand what the use cases for them would be, and those use cases can be significantly different from the ones used for by-ref OOP. It looks like the process here was "release this fundemental feauture, wait for all the major bugs to be found, teach AE's how to use it and then at some point start teaching the wider public". I don't think we really got to the last part yet.
Disclaimer - I still don't understand LVOOP myself properly, since I don't use 8.x.
The clincher is NI's decision to go to all graphic icons which aren't intelligible in any language
I agree. I always find it very hard to understand icons (even my own) and usually resort to remembering them (not useful when NI goes and changes them) or to heavy use of the context help window. However, I can understand why NI did this and would probably find it worse if the icons were all text.
The icons would probably only become useful when you will be able to make them larger and easily view the connections. Oh, wait, NI has already done that - you can expand VIs, but it looks bad and takes up way too much space for most advanced users.
Hi tst,
@tst wrote:
LV Classes are nothing like VISA, ActiveX, .NET or VI Server....
Disclaimer - I still don't understand LVOOP myself properly, since I don't use 8.x.
I haven't used the "LVOOP" either - and I've no excuse except that project-views without direct mapping to OS-directory-hirearchy is not something I'm ready to fight with. I'm told LV 8.5 has fixed this, and it's here (still in manilla envelope), but LV8.2.1 was a big jump for me an I'm not anxious to make another jump right now - especially in the middle of developing a large app.
> LV Classes are nothing like VISA, ActiveX, .NET or VI Server
I'm still not convinced that this needed to be true!
@tst wrote:
The clincher is NI's decision to go to all graphic icons which aren't intelligible in any language
I agree. I always find it very hard to understand icons (even my own) and usually resort to remembering them (not useful when NI goes and changes them) or to heavy use of the context help window. However, I can understand why NI did this and would probably find it worse if the icons were all text.
The icons would probably only become useful when you will be able to make them larger and easily view the connections. Oh, wait, NI has already done that - you can expand VIs, but it looks bad and takes up way too much space for most advanced users.
> would probably find it worse if the icons were all text.
I'm not arguing for "all text" - in fact "File" inside a "balloon" worked great - but "Info", is more helpful to me than a tiny 'i', likewise , "New" better than - what? I don't remember - maybe one of those "puffs of fairy-dust". 
> The icons would probably only become useful when... larger? more pixels? I must be stuck in a rut, I can't imaging the icons getting smaller and harder to read OR larger and more cumbersome on the diagram. Text-based programmers had some crude rules-of thumb for number of pages of code before subroutines were advised, there's probably some 2D analog - area seems an appropriate metric though at what "information-density".
I think the programmer should be able to choose a local-language icon-set, and submitted the suggestion, but even if they were to implement it - why is it necessary to take a giant-step backward first? To me, this seems like a natural "must have" - and along the lines of the original topic!
Cheers!
