Jump to content

Black Pearl

  • Content Count

  • Joined

  • Last visited

  • Days Won


Posts posted by Black Pearl

  1. I assume the queue might be better in performance.

    More use cases (SEQ, producer-consumer) -> NI put more manpower behind the optimization code -> better performance.

    I think 8.5 it was a big marketing about Qs and multicore performance, they never adressed notifiers.

    But might be completely missleading, as a notifier only needs 1 piece (the current piece) of data while a queue might queue up (as the name suggests), so those optimizations would be unneccesary for a notifier.


    • Like 1
  2. Just some unqualified basics from my experience. I care about EE safety in germany (little experience from my side and tech not legal dep), so might be different with american steam engines :P . But statistically touching 230VAC is giving you a chance of about 2% to get killed.

    For the legal issues, you have 'employers responsibility' for anything that happens (in germany: BGV A1 and BGV A3 for EE). So for me, if someone is killed by bad electrics I produce, my boss (= employer) will hang. If he has no idea about EE, he can delegate this responsibility to me (in written form -> vEFK=responsible electrical skilled person?). Note: not written -> no proof in court! And as an vEFK you should get insurance like management (you actually are in this position -> you are the leader of/responsible for all E-staff). But this actually is designed for big companies. So normally (I don't think most do, which is actually illegal) you outsource this to an electrician who takes care about DIN VDE 701-702/BGV A3 regulations.

    A second legal aspect is, that you get exemtions for small companies, e.g. a risk analysis of a work place is necessary for companies with more than 10 employees.

    And finally, I can mix everything to make it more complicated. In europa, you have two different norms covering machine safety, one electrical and one mechanical. Doesn't work in practice, because you need electrical signals to transmit the emergency off to the motor. So you need to conform to one of these, not both.

    All confused? Well, I read 4 books about the tech stuff for safety, and above is a short summary.

    In germany, we have an institution called 'Berufsgenossenschaft'=BGV (yep, that's equal to the BGV from BGV A3), translator gives me 'employer's liability insurance coverage'. I think any company is required to join one of them. And they need to pay for any accident I get at work -> they don't want this accident happen -> ask them about necessary safety requirements. A lot of safety concepts I learned was from their publications. I don't know if you can go for a similar institution, otherwise I'd just get a lawyer specialized into this -> half an hour isn't much money, and he has no interested in selling you much insurance!


  3. I havn't used Ton's API, as I wrote my own (less complete) at the same time.

    It is useful if you use some automated process (e.g. build scripts). For my reuse packages, I use a pre-build hook in the OpenG builder to extract the log from hg and create a LogFile.txt that is deployed with the package.

    Also, I have written (but I don't really use them) small vi's that allow you e.g. to rename a vi (save under new name + tell hg that it's renamed) and the like. Didn't had the time to continue on this. But for integration of hg with the LV-IDE, you need the API.


  4. Depending on the complexity of the problem, I also start with pseudo-code. On the more detailed level, I keep an uml model together with the code. For state machines, at least a bubble and arrow diagram (using dia, OpenOffice/MSOffice, or simple a paper) will be my starting point. Both get pasted as pictures on the BD. The most 'primitive' form is a simple comment on the BD as Val pointed out.

    I think this practice is 'good' and even is encouraged by NI for the exams (I think you get points when just commenting 'this vi will save the data' as much as coding it actually).

    Those design comments also serve as documentation later.


  5. Offline commits sounds interesting. The main troubles I had with SVN is to manage changes I coded at customers location. At least took me a frustrating half an hour or so.

    Using mercurial (and above article statesit is pretty similar to git) did resolve these issues in an elegant way. It proved to be robust enough to accept copy&paste behaviour instead of the correct push&pull way to sync between the hard disc of the dev PC and the USB Flash drive.

    Having to deal with possible IT infrastructure changes, I'm glad to rely on a tool that will be able to adapt to those changes very quickly. I'm unsure if SVN will be able to catch fully up yet with the robustness I found in mercurial.

    Concerning binaries, the members of my team doing electronics use mercurial as well. And I think they were transfering their schematics and layouts via USB from one member to the other as hg repositories, as available manpower and project timeline did require.

    One thing we do is to reflect the modules in the system and not the complete system (doesn't really make sense to store electronics design and software/code in the same location/container), and keep those small enough to be managed by one person and passed along quickly. Second we have a very fast and direct communication inside the team, so we actually very much fullfil the requirement of 'collaboration' imposed by DSCVs.

    It's pretty much an evolutionary process you can have in R&D teams, but might be problematic if you need to manage production throughput or document formally (documentation is always worth the effort, even in case of failure) to fullfil regulated industry standards or the like.


  6. Difficult to say, if I'd follow AQ, a must have is the hitchhickers guide.

    On the practical side, I found it difficult to get a book with the reason that I'd like a library on my workspace. The promise to get a new worker addicted to LV gives me a free wish-list on LV-books, and let them do their own selection some more. But actually, there aren't many books on LV, and I don't use any of the other exept the two you mentioned.

    Look at the projects you like, get some domain information.

    I've got a cool set of EE books. My bedtime lecture at the moment is (rough translation from german) 'electrical equipement of machines and machine-like installation' from VDE explaining the DIN EN 60204-1 (VDE 0113-1). Stuff you need to know when you wire machines instead of SW. :rolleyes:

    And, I don't think books are too important. I've tons of sientific papers I could download from the net on the subjects I had to deal with, and even greater: you can find some stupid videos on youtube. Stuff with less than 1k clicks that demonstrates you a electrical control cabinet and the like. Would have been propably cheaper to invite me to their fabs instead of producing the video. :frusty: (no, I don't link it, after it's has more than that 170 clicks!).

    Please note that I was working over the weekend (you can guess what I had to design from the text above), so I'm a bit dim in my brain.:beer_mug:


  7. Now comes the fun part - creating getters and setter to access the members of "private data". I also intend to do that with templates, unless someone has a better idea...

    I'd say templates are the way to go with VI scripting. And copy/replace operations. If you need to create things completely by code, you need to write a lot of code. And most of the time 'useless' code just to make the created code look nice (minimizing wire bends).

    You can take a look at my latest project here.

    I think about 50% of the scripting-related code is just to get the wires redrawn as they were before.


  8. "An error occured loading VI 'Demo VI Using Globals.vi'. LabVIEW error code 6: Could not load bloack diagram." - LabVIEW 2010.

    Thanks, I have a NI CAR for this behaviour. You can select Demo SubVI using Global.vi as Top-Level VI instead. All you miss is to see that it's recursing through SubVIs as well.


  9. Original idea by SteveChandler

    Now available for beta testing.

    Developed in 7.1, should run in any newer version.

    License: BSD, © Felix Schubert

    Dependencies: OpenG, included with suffix


    Unzip attachement

    Start Globals2FGV.llb and run it

    Select Global Variable VI -> Demo/Demo Global.vi

    Select Top-Level VI -> Demo/Demo VI Using Global.vi

    Select FGV Target Folder -> Demo

    Open Demo/Demo SubVI using global.vi and Demo/Demo VI Using Global.vi

    Press the transform button

    Take a look at the VIs mentioned above and inside the FGV Target Folder

    Customization: Change the VIs in the templates folder.

    Known issues:

    * Some references are not closed

    * Errors when closing invalid references in shutdown can be surpressed

    * The placement/rewireing doesn't support the smaller footprint of newer LV versions

    * The FGV target folder isn't validated

    * The transformed VIs are not saved and not presented to the user


    * Use wrappers for Get/Set

    * Display locations of global references

    Your feedback and bug-reports are welcome.



  10. AQ, thanks for this explanation.

    More than once (when VI scripting) I stumbeled on the fact, that unrelated objects actually have a common set of properties.

    Are your considerations already down to the SW level (e.g. about an alternative class ancestry or other means that group these properties together, e.g. seperate objects that will be included in the 'old' obejct)?

    On the abstract level, structures and SubVIs have a lot of similarities. Most obvious: both own a diagram (sometimes more than one, e.g. Case Structure). This is important, as we now can distinguish between 'inside' and 'outside'. Having an inside and an outside, we can have directions (input and output). Also controls/indicators, tunnels, shift registers, case selector, n-terminal (for loop) have an inner terminal and an outer terminal.

    • What about a subVI that is marked as "inline" -- can we just show its contents directly? Could a user looking at the caller VI be able to edit the inlined subVI right there without having to switch windows? How bad would that be? How common are subVIs small enough for that to be even slightly useful?
    • What if I had a subVI that took a single scalar input and produced a single scalar output... could I have "autoindexing" on the subVI and just wire an array to the input and get an array out?

    Continue that route! One feature I'd like in LVOOP would be, if I could write a VI that operates on an array of objects and perform the same type propagation as the array primitives do.

    I need to make a bigger explanation of my thoughts. I was studying the concept of multiplicities in uml. This is a feature not covered by LV at all. So at first I would need a palette for set theroy operation like union for multiplicities that require uniqueness of the elements. An example of this is the bag collection posted by Daklu.

    So my own try was to use an array of objects and add a new object wasn't found, could be performed in a for loop for an union operation. If the code was manually inlined, I got the type propagation I wanted. Making it a SubVI, I always had an array of parent class, even if all elements where of child class. This requires a for loop with type casts outside the SubVI (so actually more code than contained in the SubVI).

    Well, this was just leading to a very big set of ideas that would get maybe 20 votes on IE, as most users will just don't care about this abstraction layer.


  11. I had some similar design issues. The solution I came up was a state machine and a queue for communication. The state machine periodically checks the queue (timeout=0ms) if it gets a 'Pause' message. In the pause state, the SM waits (timeout -1) until it receives a 'resume' command. In the state transitions, the tasks are closed/initialized.

    About semaphores. I think it is easier to use the subVi boundary for this. An action engine always protects data from concurrent access.

    Concerning uml, it's not really that complicated. Most you can find on wikipedia. Another ressource was M$ Visio, which gives a nice intro but is not always compliant with the uml standard. Also keep in mind, that uml is not a programming language where you will get compiler errors. It's for modelling, so you are allowed to make incomplete models.

    If you can choose an uml tool, make sure it supports all diagrams you might want. I use eclipse/papyrus for this. You certainly want Class Diagram, State Diagram and Sequence Diagram (for modelling the communications).


  12. Yes, you're right... for now. Does it tell you anything about some of the design proposals I've been working on lately that I've kind of stopped differentiating "structure node" and "VI"?

    If I climb a mountain and view everything from such a high abstraction level, that's clear.:lightbulb:

    You propably need to do software in graphical IDEs such as LabVIEW or uml to see it. But actually it boils down to software-developement basics. You have a box around something (the SubVI boundary, a loop, encapsulation in OOP, virtual folder). :oops: Formulated it the wrong (graphical) way. Encapsulation is the abstract concept, the box around is the graphical (language-specific) implementation. But it's hen and egg (the ancient greeks and geometry, that's long before we invented tubes and transistors).

    Second step, we do something with information/data. So let's put this data inside the box. Call it state information, variable, invariant, whatever. Put everything (data) we have in a container. Place containers inside container. Recurse or iterate that process. This way, we just get order in the chaos, information out of the entropy, the ultimate process of creation.

    All we still need is a way of interaction: queues, tunnels, controls, interfaces, acess scope, a door to open the box ....

    But: is this the nature of being? Or is this just a reflection of or mind (we live in rooms that have doors that only go to specific other rooms, no wormholes possible).


    • Like 1
  13. My guess is that another event case was executing (and showing it's SubVIs FP). During this, a click was performed on the suspected button (has to be enabled) on the Main VI. When the SubVI was closed and the event was finished, the queued up event was proceeded. Propably a more complex variation of this, which did also do the disabeling&greying out.


  14. Sharing data between parallel process requires some kind of reference. You can either use a by-ref class implementation or use a LV-native reference communication (queue, user event, notifier).

    Using a by-ref object is similar to the LV2-style global/ActionEngine (with the bonus that you have inheritance as well as multiple instances). A situation where you won't be able to avoid by-ref is recursive data structures. Another situation where you might use by-ref is when translating code from other OOP languages or using their design patterns/architecture ('cause they are by-ref).

    Using a messenging system and by-val OOP as Daklu mentioned will give you an abstraction between the data (object) and the communication. If you use uml to architect the system, this is really nice as you code the class diagrams into the by-val classes and the sequence diagrams into the communications. Also getting into troubles due to race-conditions is much less likely when using queues&friends. Also, clusters (especially type def'ed) are straight foreward converted into by-val classes (just adding the OOP super-powers).


  15. I once wrote a 'converter' that was able to create xml files from LV code and recreate the LV code from the xml file.:cool:

    In my testing I did use kdiff3 to see if the LV->xml->LV->xml produced the same xml files.

    Based on this experience, this will be the issues you will need to solve to make it usable:

    • There is no 'lines' in LV code as in text. To serialize it, the complier/IDE/converter needs to impose such an 'order' on wires and nodes. To my finding, it's the order in which the objects are created. So if you delete some section of the code and recreate it identically, the serialized code would have changed.
    • Nodes (functions, SubVIs, ...) and wires are different entities. I did store them in different sections of my xml file. So reading this text would mean constantly scrolling from the one section to the other (like a basic code thats full of GOTOs). But how to make a better guess? A SubVI can have a number of output terminals, and each wire from those terminals could branch to feed more than 1 input terminal.

    Let's ignore the technical details of the points above and abstract the bigger picture from it. When coding in LV, we use a 2D space (with some limitations such as cyclice wires are not allowed). A text file is always linear 1D. To transform the 2D into 1D (and reverse) without loosing information is not really easy. When coding the 'converter', too much effort was absorbed by getting everything positioned correctly when converting back to LV, and the xml file was obfuscating the code by recording every wire-bend. Also you need to use a lot of 'links' (I just assigned id-numbers to the wires, propably using hyperlinks would improve it a bit), making it very hard to read.


    • Like 1
  16. Let's look a bit deeper into the meaning of static and dynamic. Remember text based languages with arrays.

    Static: Known at built time, e.g. the variable is defined as array[1..10].

    Dynamic: Memory is allocated at run-time when the specific operation is executed, e.g. CreateArray(10).

    In OOP, this maps to the class/object relation. Static stuff is 'owned' by the class, while dynamic stuff is 'owned' by the object, e.g. memory is allocated when the object is created. If I remember correctly, in java I could declare an attribute as static, meaning all instances of the clas (objects) share the same attribute (so they all access the same data space). This is something that isn't possible (?) in LVOOP given the by-val/dataflow nature.

    Making something static will make the memory footprint smaller, as the data space (both for attributes and methods) needs to be allocated once for all objects, while dynamic methods/attributes need to be created for each object.

    I've mainly seen the usage of static declarations when there was no 'variable' (attribute) involved, like math functions (e.g. RandomGenerator.ReturnInt() would be static).

    I've also seen that developers did split their classes into a dynamic 'normal' class and a static class that contained the static methods as a kind of library of helper functions.

    Ok, that's my share of limited knownledge.


    • Like 1
  17. I haven't done interviews, but just experience with how people performed around me. Most important is they do more of your work than you need to invest to keep them busy. So you most likely will want someone who is strong at doing the job on his/her own independently (otherwise you might just become a bad manager).

    I think a good indication could be their hobby projects. (team spitrit, fields of expertise, independence).


  18. If you program in such a way that the wire before the +1 primitive isn't branched at all the LabVIEW compiler will reuse that memory location.

    You are right in this simplified example. The compiler can optimize this code.

    But the conclusion (parallelism) is implying a branching (into multiple threads!).

    Propably I get's a bit clearer if I extend the example:




    Seems to be perfectly sane if i,j are ints. If they are pointer (e.g. to objects), we already have a race-condition desaster. Furthermore, I see no way a compiler could prevent this. The programmer will need to take care (e.g.


    my_i=i.clone //this should happen before returning -> caller might change the object in the next line




  19. Thanks for that positive story.

    Actually it is hard to believe the attitude of text-based programmers looking at a graphical code as a kind of 'toy'.

    I work in a very thight interdisciplinary team. When we talk about electronics, we look at the schematics and not at text. If we need a mechanical construction, we also look at drawings. And whenever we do design some optics, we have beams, surfaces and lenses drawn. And when something is measured/characterized, it's also graphically plotted.

    So really weired to do text-based software. :frusty:

    One interesting though we had in talking about this though.....to the computer using a series of bits read as text by humans to represent a "block of code" is no different than using a series of bits read as a picture by humans to represent a "block of code". The difference ultimately exists in the mind of the programmer not in the language/computer constructs.

    Here I would disagree. There is a very important difference between data-flow languages and all other languages.

    At first, this is a bit hidden in the compiler (there are some good explanations in wikipedia, and of course some pretty detailed issues posted mainly by AQ):

    In a text based language I can write


    where the data before and after this operation is stored at the same memory location.

    In LV you can't. Each wire (upstream and downstream of the +1 prim) is pointing to a unique memory location.

    This data flow paradigm has sever consquences:

    • Parallelism is nativ :wub:
    • We have a duality of by-val (native) and by-ref, while text based compilers are limited to pointer :throwpc:/by-ref.


    • Like 1
  • Create New...

Important Information

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