MarkCG

parallel qmh subvis is very common, nested qmhs I have never seen, but should be no reason why you couldnt . Try posting your code or something that reproduces the error, not much to go on with just the error message

Hi bublina yes I definitely use clusters for parameters that are related. I just look for a cluster change event and send the whole cluster if just one element has changed though, I typically don't care which one has changed. So if I had a cluster of PID loop gains on the front panel, I would just send a message called "PID loop gain changed" whenever the proportional, integral, or derivative gains where twiddled. good to see I'm not the only one thinking this way! Yes I chose to implement he dictionary is a variant hash, I just like being able to look up any kind of data with a string instead of iterating through an array. Probably is a wash performance wise. ah ok makes sense.

You won't get much help with such a request. It's asking "please do my homework for me". Try posting your attempt at it. If you want someone to just do it for you, then expect to pay a rate anywhere from $20 to $200 per hour. Probably 50% in advance.

Yep this is pretty much what it is, as shown in that thread. I just made the message name independent of the control name. I also found that sometimes I wanted to associate a particular message name to a particular value of the control. For example: Log button becoming true sends "Start Logging" command, Log button becoming false send "Stop Logging" command. The thing I like about this is that I can handle fiddly "stateful" control logic inside XControls. The Xcontrol has an enum value and I can register a particular enum value to a command specific command message. For example, a "tape deck " type control with play, pause, resume and stop / abort buttons. Three button, four messages "Play" "Pause" "Resume" and "Stop". The X control logic wraps the "button logic" up nicely without having to smear it over 4 cases of you main UI's event structure. So now would you have 80 boilerplate VIs instead of 80 event structure cases?

Derp! Ok this should be attached. Yes I have used control refs to do this. Control-Value-Command Registry Example.zip

Hi all, as the complexity of some of the systems I have worked on grew, I found that I could have dozens of user controls in my diagrams, handled by an event structure. Almost all of the case structure cases handled "value change" events and simply enqueue the new value and a "X changed" type command to the appropriate module or remote target. Having 80 cases in an event structure, all doing more or less the same thing seems like it's crying out for refactoring. I came up with attached class in order to capture UI command-value pairs and write them to a network stream, using just one case of a case of the event structure. It leads to a lot less code repetition (at the expense of some more BD real estate on the left hand side) but I am more or less happy with it because it's less wiring overall. I made an example (attached) to demonstrate it. What do you all think of this way of structuring my UI code? What improvements could be made?

usconverters.com Several times I have worked with folks decide that the way to build a data acquisition or even machine control system is to take a generic windows PC, install the LabVIEW dev system, and hook up a new and Ebay-ed variety of virtual RS-232 , virtual RS-485, and GPIB device, and maybe a cDAQ chassis to it. Educating them on why this is not a good idea, most of the time, is a never-ending battle which I am not sure I want to even fight anymore.

Network streams or something simpler based like the STM library are well suited to commands from HMI to RT target or status updates and events from the target to HMI. For tag data, where you care only about the last value, unbufferred network shared variables are good. Doing it all as one pipe could be done, sure, it's all tcp/ip under the hood anyways

I never understood the logic behind that causes the "bitfile signature does not match" message that forces recompile if you are opening the fpga reference by build specification or by VI. it caused me great annoyance as I was learning the LV FPGA side of things. The ip address should have nothing to do with it but it seems to, also when you pull a copy of the project from the source code repo it wants a recompile. Why? I think that if the hardware in the project matches the bitfile it should not complain. I just gave up and just open a reference to the bitfile exclusively. With custom fpga code on ethercat targets I erase the fpga and download the bitfile directly via right clicking on the fpga target in the project.

Yes deployment is a little long when using interactive mode, not too bad now with newer version of LVRT where it only deploys VIs that have changed after initial deploy. The bugginess is annoying but I have figured out how to avoid the crashes in edit time. I'm pretty sure I can reproduce on way to make LV hard crash when editing statecharts, but I wonder if NI would care if I did document it... I also was surprised you couldn't rearrange triggers and static reactions. I just decided I would never rearrange them and deal with it. That's part of the lack of polish for sure. Yes. That's a big one. I wish NI would give up and include it with the full development system. I'm a witch doctor and my magic is strong. Seriously though- I have read some things from functional programming decrying the existence of "state" in programs. But my view of the matter is that the state of the physical system you are controlling needs to be reflected in the computer to be able to do anything useful. Almost always the state of the system is dependent on is prior history and what you can do next is dependent on that. I don't see what are talking about, when applied to programs that control a machine in the real world. But I am starting to read about it Functional Programming, maybe it'll reveal the answer as to how to avoid the problem!

Thanks for sharing this! Now you got me on an Alan Kay video watching roll. His way of thinking abotu things really resonates with me

I believe this NI addon is very unappreciated. I am using it right now to a production machine with multiple stations for a customer. No specs provided beyond asking "what should it do if X" and boy howdy-- doing things in term of statecharts is had made thinking about the problem and crystallizing the logic an absolute breeze. it is also easy to test the logic encoded in the statechart. Doing the problem in terms of a conventional LabVIEW "state machine" would be much less fun and take longer. There are of course, some bugs as you might expect for such a little used module, some causing hard crashes of the dev environment during edit time. What is it in your opinion that has turned people off LabVIEW statecharts? Is it the the statechart paradigm and the need to learn it? Or the perception that it's just re-inventing the wheel? Or the bugginess and half-finished quality of the module?

Thank you very much for the advice ! I too had issues with connectivity-- for some reason the sbRIO was connected to the test computer with some weird usb to ethernet converter that kept flaking out. Really annoying and wasted valueable time. I had to bypass it and set up a link-local connection the normal way. The grader claimed that the " The User Interface is not adequatly developed for the UI message Handler, Network Stream to RT, Communication intilization, and error handling." Not really sure how so, as the usual pattern of an event shandler was there, network stream connected when you press the connect button to the correct IP, network stream commands get forwarded, and shared variables are read (programmatically based on IP) . Not sure what they are expecting as that is how it is done in all the examples, and in most people's real world programs. Anyways, I'll contain my frustration and try again. Thanks!

I took the CLED and was surprised just how much you were expected to do in a 4 hour test. I did not use a template project as the project file is provided to you.. should I have? I have used cRIO on four different projects and gotten nice reliable systems that keep ticking along for months at a time. This includes writing custom FPGA code. So I was disappointed that I didn't pass. Any tips out there from people who have done it?

It's because the label is aligning itself to the X control, which contains the string control. I have a very similar X control and didn't figure it out how to make the label align perfectly. You could alway hide the label and hand align some text typed directly on the front panel

are you updated to the latest compactRIO support , 14.6? there are problems with that specific module and the 906x series chassis, though it may not be what you are seeing http://digital.ni.com/public.nsf/allkb/EE21CD363EDE58E486257E0E0045C9A8

It tells me I look 47. I blame the Actor Framework for turning my hair gray

I never use enum state machines anymore. Just too much aggravation to edit the enum for me. Any typos are caught pretty quickly by error handling during testing.

This is what I came up with in my work It is somewhat surprising that there is not an FPGA moving average express VI already provided by NI- there are IIR filters. I might even try to figure out scripting so I can create a moving average VI with a given fixed point configuration, window size, and choice of memory implementation.

Hmm, for me, to the contrary everything has worked without a hitch since unseparating source for that particular project-- it solved the deployment problem I was having. It was in 2014 too. I have a feeling cause hiccups when you have dependencies shared by both the windows target and the real time target- for example you have a class that works on the RT side, and a typedef control within that class that gets used somewhere on the windows/HMI side. That's a no-no, disconnect from typedef always if you have too. I don't have conclusive evidence to back it up though. I wish I had a clearer picture on how the whole dependencies / multiple targets / compiling worked to better understand why things like this might happen

Still not quite there when working with with projects involving different execution targets in same project, like compactRIO. Deployment errors when running in interactive mode on remote target, build problems, forcing recompile doesn't always work. I'd rather just deal with the excess changes in source control than have to do work arounds.

It's got its uses, it's definitely helped me simplify certain problems. Just to not be vague, hardware abstraction classes for communicating to various random instruments and hardware, loading those dynamically according to a config file, is one clear slam dunk for LVOOP to me. There are others. I definitely get very annoyed by the "everything must be a class" philosophy, with vaguely implied benefits of "reusability" or "so we can change it later" (inheritance) being the justification. Using OOP does not necessarily practically imply either benefit IME. If you can already see the whole picture of your hierarchy of classes before implementation, and see how it will benefit you, do it. But just using LVOOP that it will somehow be easier or "better" without a clear picture of what you will accomplish with it will just make things more complicated than needed.

If you have multiple instances of an application that uses network streams, you can have each EXE give its stream a unique context name by generating a GUID. There is a way to get it via .NET.

I wrote a small application in it just to see what it was about. I was a utility with AF that would launch multiple actors dynamically, to communicate with multiple Real-time PXI units on a factory floor and push some VIs to them. These VIs would then be executed via VI server is parallel on each unit to do a firmware upgrade on some equipment that was attached to one of PXI's serial ports. Having multiple parallel actors running and keeping track of the upgrade process for each unit, which would take 10-15 minute, was really handy. I would keep the child actor queues in a variant hash and look them up by IP address. I was happy I wrote it with AF. However, other than that one thing, I decided AF was just too heavy for MY purposes. For the kind of applications I write (machine control on cRIO), needing to launch multiple instances of an Actor is just totally unnecessary, because the number of hardware peripherals the machine is controlling is fixed. There is no need for dynamic launching whatsoever. I do make use of LVOOP to make Hardware abstraction Layers fairly frequently, and occasionally use a strategy pattern for some complicated control algorithm things. I too am fascinated by the concept and genius behind its implementation-- but I am not convinced it is the way to go for most of what I do. I have had problems with people inheriting the little bit of code I wrote using AF being unfamiliar with framework and having a very steep learning curve. I have read stories on here about how large projects using it would cause the IDE to grind to halt due to coupling of actors (really not AF's fault but the IDE). That is why I decided to leave it alone for the time being. I don't want to say it's bad by any means, better programmers than I have done great things with it. There is an example application written by Elijah Kerry that is a good demo of AF's potential: https://decibel.ni.com/content/docs/DOC-21441 .

Nope, it works regardless of the gap size between elements-- array =[1,10,100,1000,10000,100000] with min =99 and max=10001 works just as well, returning [100,1000,10000] . But be sure to do bounds checking on min and max, so an empty array is returned if they are out of bounds.