Jump to content

vito

Members
  • Posts

    13
  • Joined

  • Last visited

vito's Achievements

Newbie

Newbie (1/14)

0

Reputation

  1. How much is Wezarp? Had a look at the website and couldn't see a price. Went looking for Wezarp on the LabVIEW Tools Network, as indicated on the Wezarp website, and nothing showed up.
  2. This looks great. I've been urging NI to provide this solution for years. Good to see that others are taking care of user needs. I'm seeing a lot of this lately. LabVIEW may finally become versatile if a user interface can be presented on a tablet or mobile device. Others are also making LabVIEW target other devices. It's starting to look good. Kudos for a great product!
  3. Thanks Michael. I didn't know that one of the Arduino offerings has built in Ethernet.
  4. hooovahh, one of the features of LabVIEW is parallel loops. Sure you can get things done without it, but one of the significant features is not there. I hope single loop operation will be attractive enough, as I'd like to see takeup of this product so that it continues to be developed. I'd like to see LabVIEW compiler for Arduino become what LabVIEW Embedded for ARM was supposed to be. I programme microcontrollers in C. A single loop works, but then I have a SysTick event that fires every 10 ms to lets me do other things and all "events" fire an interrupt that allows the "event" to be addressed. Maybe the LabVIEW compiler for Arduino will nicely handle interrupts, which may be enough. What do people think about a "release" command that can be inserted in a loop to yield CPU to the next loop? All things said, I want this product to succeed. It has great potential.
  5. Filipe, Great to hear that the first release will support the Arduino Due. Given that the Texas Instruments TM4C1294 LaunchPad can be programmed with Energia and that Energia uses Wiring and Arduino framework, do you think it would be a big effort to target it? The big attractions are built in Ethernet (and lots more) and a $20 price tag. If I understand you correctly, the first release will only allow a single loop operation. If so, this will be very limited. Good enough to get a taste for what it can do, but not good enough to use for serious applications. Even a simple mechanism where a "node" would signify "release" so that multiple loops can be run one after the other when released may be a good stop gap measure. The ability to run multiple loops will be essential to get market takeup. Regards, Vito
  6. Filipe, this is great. I've been programming with LabVIEW (desktop, Real-Time and FPGA) for about 10 years and this is the best thing to happen to LabVIEW since the Event structure and FPGA programming. It's the best thing to happen to LabVIEW in 10 years! I've been requesting, some would say badgering, National Instruments to do something like you've got under development for 3 years now. Thanks to Arduino Complier for LabVIEW, I don’t have to wait for NI or rely on them. This is a game changer. The fact that you got it to work on a very resource limited Arduino UNO is impressive. It would be nice, sometime in the future, to consider the Arduino DUE, with a 32 bit microcontroller running at 84 MHz (rather than 8 bit running at 16 MHz). Better still, there's the Texas Instruments TM4C1294 LaunchPad which has an ARM M4F core, running at 120 MHz, Ethernet and much more - all for just $20. It would be great to one day see a LaunchPad Compiler for LabVIEW. The Launchpad has Energia, which brings the Wiring and Arduino framework to the LaunchPad, which may make it a good fit to you future plans. I tried the now (effectively) discontinued LabVIEW Embedded for ARM (LEFA). It had a lot of potential, but failed in our evaluation (http://forums.ni.com/t5/LabVIEW-Embedded/LabVIEW-Embedded-Performance-Testing-Different-Platforms/m-p/1882581 ). LEFA was OK with a single loop, but when multiple loops were implemented, performance fell such that only about 10% of the CPU was available. How is your multiple loop performance? Is there any significant degradation? I look forward to this product. I think it's going to be revolutionary. I even more look forward to a more powerful platform such as the Arduino DUE or LaunchPad. I’m not sure of your business model, but opening up to the community would get many of the functions such as filtering, FFT, etc going.
  7. I suspect the board only version may be much cheaper since it does not have WiFi (if you don;t need it). I'm also on Sydney and would like to get one when I have the time to play with it.
  8. Hi Shaun, From my brief look into the various technologies so far, I suspect that NI's Data Dashboard and what you mentioned will become the two standards. The websockets solution will need to be packaged for easy consumption and include a decent user manual. I like the idea of two competing technologies . If it wasn't for such competition, we'd still all be using DOS! Regards, Vito
  9. I've put together a list of the various methods/products that allow a remote device to be used as a user-interface for LabVIEW. The post can be found at http://forums.ni.com/t5/LabVIEW/Using-a-remote-device-tablet-phone-etc-to-provide-a-user/td-p/1813504. I'm interested in hearing your comments and info.
  10. ned, Thanks for your insightful and detailed reply. There's one thign I didn't understand. You mentioned "(... as an aside, in your template code, you could simplify by using the reference provided in the event data node to clear your boolean, rather than using an explicit property node ...)". Which Event Data Node reference do I use and where is it wired? Regards,
  11. QUOTE(JDave @ Nov 14 2007, 12:24 PM) JDave, Yes, it can become confusing to differentiate from actual UI and programatic interaction. This is a strength and weakness of the ESSM architecture. The beauty is that you can click in one place and see all your handlers. The problem is that once you have 50 of them you loose track of which are front panel controls and which you have used. As with most things there are workarounds. You could always label the programmatic interactions starting with, say and asterisk or some other character that you like. This change is easy and reliable since all programatic handlers are lsited in the one place (the LEDs). I still find the ability to click in one place and have all my code listed with descriptive headings and able to jump to any using the pop up menu saves me a lot of time. Anyway the ELCL architecture does not provide a solution since all tasks are delegated to the Consumer Loop and the list is just as mixed. Does a series of events address your concern "I found that I was trying to pack as much as possible into every event to avoid creating new events"? Regards,
  12. QUOTE(ned @ Nov 14 2007, 01:31 AM) ned, I see that you are not impressed with the new proposed Event Structure As State Machine (ESSM) architecture. Firstly, thanks for taking the time to show me the equivalent functionality using a conventional Event Loop And Consumer Loop (ELCL) architecture. My objective is to put up for consideration a simple, effective and expandable architecture for LabVIEW programs. The ELCL architecture requires queues to be established, wired up and destroyed and an additional loop. So it's not as simple, therefore it needs to have other advantages to make up for the loss of simplicity. I'd like to now address each of the disadvantages that have been mention for the ESSM architecture: 1) My primary criticism is that this isn't LabVIEW - you have broken any sense of dataflow. Maybe I'm missing something here, but whether you put an action into the (invisible) Event Queue or a queue that the programmer explicitly established, dataflow is broken. And to the same extent. I don't see any difference between the ESSM and ELCL architectures in terms of dataflow breaks. 2) It is impossible to probe a wire to see the sequence in which your states execute. The "LED panel" provides this information and in a better form than a text string. This is because the "LED panel" is graphical. You can see LEDs flash and note their occurrence and order a lot better than strings that flash up. 3) If a user event occurs in the middle of one of your event sequence chains (one case triggering another) you'll lose the ordering and will have trouble following what happened. Whether you handle user events in the Event Structure or delegate them to a Consumer Loop, if a user event occurs it will equally interrupt the ordering. 4) If you ever need to split your logic from your user interface - say, you decide to move to an RT target with a remote display - you'll have to rewrite all your code. Yes, this is a disadvantage of the ESSM architecture. However all the code will not have to be rewritten, but it will have to be cut and pasted into a new structure or the Event Structure will have to be changed to a case structure and unwanted cases removed. Not sure how hard this would be to do or how often or likely it is to happen. Haven't had a need to move my code to another target yet and I'll cross that bridge if and when I come to it. 5) As an added benefit, other LabVIEW programmers will quickly understand what you're doing, because it's a standard pattern. This is the subject of the topic. This is a new proposed architecture. Is it good enough to use or not? If it stands the test of the LAVA forum, perhaps it will get used. If significant holes are found in the ESSM architecture then it will disappear. So, I'm still happy with the ESSM architecture, but I look forward to more input as I'm keen to standardise my development on a simple, effective and expandable architecture. Regards,
  13. I think that an Event Structures As State Machine architecture works well. It's what I'm using for my project. It's not the sort of structure that is taught by NI, however I think it has some distinct benefits. Three other architectures have been mentioned in this topic: 1) State Diagram 2) Producer/Consumer (Producer can either be a normal While Loop or an Event Structure) 3) Event Structure With State Machine Inside An "Idle" Event Case As EJW stated "The program I have seems a whole lot more complicated in regular diagram form that it would be if I just used the event structure with a few user events." A State Diagram is very inefficient at responding to User events since you need polling. If you look at the Producer/Consumer model it has wires running everywhere and a lot of "code" before you even start putting anything useful in. The Event Structure with a state machine inside an "idle" event case offers, in my opinion, no benefit over using the one event structure and firing off some Programmatic Events (NI uses the term User Events for programmatically-generated events. That is, events not generated by the user are called User Events. Talk about calling something the exact opposite of what it is! I'll use the term Programmatic Event for programmatically-generated Events.) Having highlighted what I see as the disadvantages of the three main architectures, let's look at the elegance of an Event Structure As State Machine architecture. You put down a while loop that takes up your entire screen and then put in an Event Structure. Your architecture is now complete. Simple, quick and easy to understand. Compare this to NI's example of template Producer/Consumer structure!!! You would now add whatever your software has to do. For each user interface control, you can readily create an Event Case to handle it. Most can be done within the one event case. For Programmatic Events, start with an Initialize Event Case, which you fire using the technique mentioned below. Add others as required, including an Exit one that sets the While Loop's conditional terminal to True. All cases can be readily viewed by clicking on the Event Structure heading. There they are all listed, just scroll down and select one and you are instantly there. With the closest method to an Event Case Structure As State Machine architecture, which is the Event Structure With State Machine Inside An "Idle" Event Case architecture, you need to click on the Event Structure heading to list all User Events and then on the "idle" case and then the Case Structure to get a list of Programmatic Events. Why do multiple clicks when one will do it. Why have two structures, when one will do. If you ever want to print out your code, it prints out such that each Event Case is on one page. For those that like to work on public transport on the way to work and home, this is great. If you need to do something that takes up more than one page, rather than expand the diagram to go beyond one screen, just fire a Programmatic Event to another Event Case and continue from there. My initialization happens over four event cases and can be readily expanded to more. This allows sequencing, which is very important when initializing, but also ensures that things are not crammed together. The Event Structure as State Machine also cuts down on subVI's. SubVI's are great when you have a specific task to do or do such a task in multiple places. But how many times have you created a subVI just because you ran out of space. Delegating code to the subVI in this situation does not help legibility as you need to open a subVI to see the program flow (and you'll forget to pack it for when you work on the bus!). It's so much nicer to get the current Event Case to fire another Event Case and you continue looking at your code in the next Event Case (a three dimensional block diagram!). When using an Event Structure As State Machine architecture, we have to be careful that each case can be executed quickly. By quickly I'm talking about less than 1, 2, maybe 5 milliseconds. This is a long time to do a unit of work. I've got 1 kHz data with 20 data channels coming at me at 10 Hz (100 element arrays) from which I select six channels, decimate, buffer, scale and then graph (with scrolling) and the whole thing happens in 3 milliseconds on a middle-of-the-road PC. Most responses to user action or chunk of data processing can be handled in well under 1 millisecond. If you're doing a long task such as processing an array of data and it takes over a few milliseconds, it can often simply be broken up and processed in smaller chunks. This takes care of 90% of actions. What happens when we have something that can take a long time? Here you must use one of two techniques. If your task goes off and does something that you don't need any output from it (writing to disk, displaying something complex, etc) you can use VI Server to serve up the VI and set it up so that it executes in parallel and immediately returns control. This way the Event Case is exited quickly. Finally, you can set up a queue and parallel loop that is communicated to. This is the Producer/Consumer model, but only those activities that cannot be done quickly, sliced or parallel launched need to be worried about. In a medium complexity program you'll probably only have one or two of these. So yes, there are some Consumer Loops, but very few. And they are very simple. Each consumer will have its own queue. Rather than having a Consumer Loop with multiple commands and having to send a superset of data that fits all the Consumer's commands, you just send data to the Consumer Loop along its dedicated queue. The consumer loop is waiting for data, it sees it and processes it. Compare this to the typical consumer loop that has to read the command, then pull out its data from a one-size-fits-all data structure and then execute its. The simplified Consumer model works since there are only a few (generally about 3) Consumer Loops since only tasks that take longer than about 5 milliseconds and can't be sliced or served, need to be send to a Consumer. Now for the controversial bit. How do you fire off Programmatic Events (again which NI call User Events, even though they are not initiated by the user – talk about confusing). The purists would say that you need to register events and define things. For those that wish to go this conventional and conservative path, go for it. Personally, I hate the complexity. There is a simple method. Before everyone jumps down my throat, I know that the method I'm proposing forces executing to go through the user interface thread. Yes, there is some latency (but no less efficiency), but if someone can quantify it, I suspect it's negligible. [As an aside, does anyone know how often the user interface thread is run?] The method of firing Programmatic Events is it to put a Boolean indicator on the front panel and label it with the action (eg. Initialize, Update Graph, Exit, etc). Now, whenever you programmatically want to execute one of these Programmatic Events just create a Property Node with Value (Signaling) and wire a constant set to True. You can now create a new Event Case that responds to a Value Change for the indicator. What I do is put all these indicators on a tab labeled Programmer (I'm sure they can be hidden if required). I also write a false to the indicator as the last step of the handler Event Case. This way, when I want to, I can click the Programmer Tab and I can see where my program activity is. I can also see where it is if, during development, it is stuck – it's the Event Indicator that is on. Sure there is latency in using Value (Signaling), but the added visibility allows you to make up for the loss of efficiency. I hope I've presented a simple, elegant and efficient architecture. It could certainly do with some refining and I look to the community to find holes in the architecture and give me the opportunity to address them. The benefits I see are: 1) Quick and simple to set up 2) Very legible as all actions are an Event Case that is readily listed and jumped to 3) Easy to expand. 4) Can be used for small or large projects 5) If you're willing to use Value (Signaling), great visibility on where you're code is at without any extra programming. See attachment for a template.
×
×
  • Create New...

Important Information

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