Jump to content

ShaunR

Members
  • Posts

    4,849
  • Joined

  • Days Won

    292

Posts posted by ShaunR

  1. To a reasonably educated individual, the common conceptual base which underlies virtually all programming is more important than the specific language a person learns first.

    I sort of semi-agree with this. With text based languages, its much of a muchness. With functional languages (lets forget OOP for now) like c, pascal, java script, VB, PHP et al, only the syntax really changes (pascal uses the asignment ":=" as opposed to "=" for C for example). Once you learn one its just a case of learning the IDE and syntax and away yoiu go :) But changing between paradigms is a bit different. Its much more difficult to change from C to Prolog for example even though they are both text based. Couple changing paradigms with changing from text to graphical just compunds the leap.

    Anybody with an open mind to new concepts will readily embrace them regardless of age or prior experience; prior programming will give them a solid foundation to build upon.

    Indeed. But the problem I come accross time and time again, is that many people are not open minded, or they've been doing it for so long in one way, that it takes great effort to join the synapses in a different configuration.

  2. Could you post a snippet from Passa Mak (or, a few) to show how you're finding all of the

    I don't have LabVIEW 2009.

    It grabs all controls from a FP. Then extracts the labels and text dependent on the control type. PM Get Control Text.vi uses recursion so it will drill down into nested clusters.

    Passa Mak creates a list to save to a file since the save and load are separate, but for a regex replacement you could put a write node immediately after the read node in the PM Get Control Text.vi and modify the string in between.

    • Like 1
  3. Its not too hard to find and replace text. Passa Mak does it for controls, indicators and tip strips. It also has a diagram scanner to extract string constants. It wouldn't take much of an imagination to modify the the relevent bits for descriptions, revision history, decoration text etc. Although its not designed for regex replacements, it covers a lot of the bases you'd need or, at the very least, show you how to go about it.

    • Like 1
  4. I'm with Gary on this one.

    Another aspect is that not everyone "gets" OOP. There are many coders that use OOP capable languages that never write a bit of OOP in their entire career. Perhaps a better approach might be to start them on normal LV with the advantages of all the existing examples and training resources and filter out those that just don't have the head for it, rather than assume that everyone can and will learn.

  5. Whoever gave you rep for this post deserves a beating. Everyone knows emoticons are only for those who lack telepathy, and, frankly, those kind of people don't belong on the Internets in the first place.

    Another opening soon for Vaguely Interesting Engineering. CVs to Crelf :P

  6. Think about it! There is no other way to make this feasible possible. The Embedded development system simply converts the VIs to C code and compiles that with the C tool chain for the target system. Just as there are 10 C coders a penny there is one impressive C compiler that works for almost all hardware, namely gcc. NI could spend 100ds of man years and try to write a LabVIEW compiler engine for every possible embedded hardware target out there and they would not get anywhere. By converting everything into C and let gcc (or whatever tool-chain a specific embedded target comes with) deal with it, they can limit the development to a scope that is manageable.

    And of course the direct communication with hardware resources has to be dealt with in C somehow. There is simply no other way. The LabVIEW system can not possibly abstract the 10000 different hardware targets in such a way that you would not need to do that. On Windows you usually get away without since there are enormous driver suites such as DAQmx and many more that take care of the low level nitty gritty details like interrupts, registers, DMA, etc. On an embedded target that NI has at best had a board in their lab to work with this is not a feasible option.

    If you need out of the box experience you should not look at embedded hardware. You are anyhow not likely to use the development kit board in an end product so the out of box experience stops there already.

    A much better solution for out of box experience would be cRIO or maybe sRIO.

    To me, its a bit like Codegear selling you Delphi and expecting you to do bits in Visual Basic.

    People like LV because it is not C. What they could have done is run a linux kernel on the ARM and then use the linux RTE or ported their RTOS which currently supports intel and Power PC. There arn't that many platforms out there that they support so I think for that price they could have made a bit more of an effort.

  7. Look for the property FrameNames of the CaseSel class. This is an array of strings much like the Strings[] property for enums.

    OK. I've looked now :P

    Its a little bit more complicated than that, since the frame names has to match the number of cases. If you just wire it to an array of strings, you will get an error and only 2 cases will have the names. You have to create the correct number of cases (array length - 2) using the "add frame" invoke node then wire your string array to it.

  8. Shaun,

    Referring to this page, did the NI sales rep show you a Tier 1 or a Tier 2 evaluation board+device ? The Tier 1 devices apparently work "out of the box" - although that says nothing about UI configuration flexibility.

    BTW even if what you say is true re. the inflexibility of the UI vis, unfortunately I suspect there will be nothing on the NI site that explicitly says so.

    regards

    Peter Badcock

    Product Development

    ResMed Ltd

    Well. the board had a 2 line LCD display so it must have been tier 1. It did work "out of the box"....... with the demos. And as long as you changed only the data to the front panels it was fine. But when I said that our device was to have a 12 line matrix display and how could I mod the "display" vi to do that, he said I'd have to write my own display driver in C. He did demonstrate compiling, downloading and live debugging with a demo he had prepared. But when I started asking him to modify it, he changed some settings and then it would pop-up with a window full of c code and he would twiddle bits. I pushed him on it and asked why he wasn't changing the vis. Thats when I looked inside and found....well nothing, apart from the controls and indicators. The vis seemed to be purely placeholders for the generator.

  9. That's rather dissapointing Shaun. Was it an NI sales rep or some 3rd party rep ? Either way I hope they didn't know what they were on about. I naively assumed LabVIEW for ARM/Cortex would be more flexible than that.

    Anybody else used LabVIEW with ARM or Cortex care to shed light on their negative or positive experiences ? Was anybody satisfied with their "Out of the box" experience ?

    regards

    Peter Badcock

    Product Development

    ResMed Ltd

    It was an NI rep and the toolkit was "The Embedded Module for ARM Microcontrollers"

    This is what it says in the sales blarb:

    The Embedded Module for ARM Microcontrollers includes the LabVIEW C Code Generator, which generates C code from the LabVIEW block diagram.

    Embedded Module For ARM

×
×
  • Create New...

Important Information

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