hooovahh

Yup, someone can correct me if I'm wrong, but I believe ethernet and RS-232 (VISA) is a RT only resource and the normal VISA and TCP palettes use those, no FPGA needed. Doing CAN on FPGA is something I have done before, but just like AIO streaming there is an example that just shows how to send all the CAN data to a FIFO, and RT VIs that convert it all to frames, then XNet or other custom code can convert it to whatever you want. If you wanted to write code that would do something custom like, when a specific frame was seen, set an output, then that could live on the FPGA if you weren't okay with the response time of going through RT.

So I remember investigating a few things with this menu bar at one time. My goal was to just remove the menu bar all together, without using VI Server. If your window implements the menu bar using some kind of standard Windows menu bar then this is relatively trivial, and using the GetMenu on user32.dll returns a reference to the menu, and SetMenu sets the menu. The problem I've found is that LabVIEW implements menus not as a standard menu bar, and using this Get and Set don't work as expected. I show an example of how to insert notepad in a front panel window here, and I can remove and add the menu bar using this DLL calls. (here is the post with source) My point in all of this is, if you found a way to change the color of a LabVIEW menu bar using OS calls, I'd be very interested in it. In my investigations I couldn't find a way to easily remove the LabVIEW menubar, let alone change any of its properties. Oh and the color probably comes from the theme applied in Windows, so if you are able to change all menu bar colors then that could be tried.

Thanks, I made assumptions based on other builds I've seen, which is also why I prefaced that with "I believe". I should have been more explicit stating I've done few deployments to RT to date.

This is really the preferred method for a PXI running RT. One other thing I'd mention is with cRIO vs PXI. With a PXI you essentially need two programs written, one for the RT one for the Windows PC for UI and communication. with a cRIO you may need three applications, Windows PC, RT, and FPGA. This may mean more work if you can't fit in the scan engine profile of an FPGA, but it also means flexibility if you want to do other custom things.

I never really thought about the implementation details. I guess an option would be to use user events that get generated when those UI elements are interacted with. Of course that would mean you can no longer just auto generate a web page from a VI, you'd need code to create those user events, register for them, and handle them separately. I kinda like the simplicity of the auto generated stuff so I might just live with value changes. I mean that's all the RT Linux HMIs have right? EDIT: I started making this and idea exchange but wasn't sure if it was actually what I wanted. I was thinking given a reference generate a specific event, but wasn't sure if the webpage could even support that type of dynamic changes for things like menus popping up on right click.

That wasn't the intention, sorry if I didn't spend the time to research each and give a more detailed table of the pros/cons of each. The intention again, was to show that there are many similar toolkits trying to accomplish a similar task. Make a webpage which hooks into a VI running on a server, usually by replicating the VI's front panel in a webpage. No idea about the limitations of each, I suspect runtime menus, events, subpanels, tabs, .NET, ActiveX, and XControls to have varying levels of support. I would be very impressed if there is one that does all of these somehow. We should probably make this a new topic if we continue with this discussion soon.

Remember it's not just 3rd party tools. NI has shown lots of interest in their tools, and the linked keynote. Only recently have I seen a real need for something like this and will have to choose from one of them at some point. So no, I don't think it is common, but lots of people are asking for it, some must be using it.

Hm....well I think a continuous read might be the fastest. Set it up to perform something like N channels N samples, reading continuously at a fast rate, then perform a read, taking in all samples ready to be read. You will likely get lots of samples because of your fast rate but who cares, just grab the newest for each channel, do calculations, and write single point, or maybe have the write task already open set to a continuous write, and do not regen. The point I'm making, is I suspect that if you have your read task set to a continuous read, then just read how ever many samples are on the buffer, then this might be faster than reading a single point on each channel one at a time, because the task is already running and all that needs to happen is transfer the data. Maybe the write can work the same way but it might be more complicated. If you already have the task running, maybe performing a continuous write would be faster than multiple single point writes, but regen needs to be off. Otherwise your output will repeat because this is usually used to do something like continually write a sine wave, you use the write once and it loops back around but, in this case you wouldn't want that. Sorry I don't have any hardware to test on.

I wasn't really thinking of it as free advertising, at first this was the list of tools that you wouldn't want to try, if you don't want to spend money. This list does contain WebPanels I think is the only free one in the list (other than the one discussed here)

Oh so sorry, there are so many it is hard to keep up with. Okay lets see if I can do this justice. Front Panel Publisher Websocket API for LabVIEW Webpager Wezarp VIRemote WebPanels (or this) Web UI Builder LabSocket Remote Witness Data Dashboard, and NI Web Services should get an honorable mention, but isn't true to what this is supposed to do, which is turn a VI into a web page. And NI even has teased porting the LabVIEW run-time engine to JavaScript. EDIT: Updated the list.

Topic continuing from here. Discussion was talking about alternatives of generating interactive web pages that hook into running VIs. Here is another non-free competitor. Webpager

If Windows is too slow for you, then you need something that can be more deterministic. Before that I'd recommend just looking at getting better performance from your code by looking for ways to optimize it. Because the type of control you are talking about seems like it can be somewhat slow. If that doesn't work and you need to respond quicker, and want to stay with LabVIEW then your options are some kind of real time OS or FPGA. The cheapest method isn't cheap. Maybe you can get a hold of a myRIO which is still on the order of $1000. On top of that bench top power supplies aren't made to change settings quickly, so even if you were able to sample an AI, and output an AO at 1KHz, I doubt many supplies can respond that quickly. In the past I've used power amplifiers for this type of work and they are made to change output very quickly. Give it a 0-10 and it outputs a 0-100. Of course this equipment is generally very expensive. I know you want some more control over this simulator, but would discreat components work? I mean if you used an op-amp and some basic circuity could you have the voltage that varies from the solar panel, directly drive the input to the PSU? And also this sounds like such a simple system, that maybe a small embedded micro could work. Program an Arduino like board that samples an AI and outputs an AO. The Teensy has a low cost version that is only $12 and has AIO and can be programmed with the Arduino IDE using all of its libraries. Without knowing your system details, I'd just recommend using normal Windows code. It's simple and easy, and could probably just use some optimizing.

I'm not sure I understand your question, but if you make a build to be deployed on an RT target, I believe all the dependencies should be copied over. Similar to if you build an EXE for Windows there will be a Data folder with the dependent DLLs. OpenG relies on that external DLL library and I'd expect it gets included in the build.

This isn't a working solution but it might help. I would use 7-zip, which has a command line utility, and a DLL. http://lavag.org/top...rs/#entry101116 There someone asked about zipping a folder of files in a way that wasn't supported so I suggested using 7-zip in a command line to get the function needed. You can look at the code and modify it to extract the zip using a password.

I also tried back saving it in 2013 SP1 and it also had some runtime error with the in place element structure, which is odd because the only place you are using it is with these DVRs, and one place in the XNode code for being an unbundle/bundle but the error didn't come from there. I know this has a ways to go before it is code repository ready, but you're going to want to revisit the VI descriptions, lots of stuff in there with my name on it. Glad you are finding some of my code useful, but it incorrectly identifies what the code is a part of and where it comes from.

Is there a reason the running average needs to be in the file? Just curious why you don't have a circular buffer in your program and calculate the average with that. Even if you do really want it to be in a file for some reason, is there a reason you can't have two files? It sounds like the running average is filled with dummy data anyway and could be saved in a temp location.

I've never really thought about it but you are totally right. I suspect it has a lot more to do with the target audience of LabVIEW, being scientists and engineers, who may have no or little software discipline background. Who needs SCC when it's just me in a lab making a single giant VI? Why would I need requirements tracking? Bug tracking? Documentation? Coding style? Certification?

In the NI world people usually talk about Requirements Gateway. (RG) It was a tool made by another company that NI bought and modified to support NI software tools a little better. I don't know that it can do all the things you asked, it basically links Word documents, and LabVIEW source, finding tags in the code, usually to signify a requirement is being fulfilled by that part of the code. Imagine you had a detailed requirement document. RG can pull out the text and tag information so it knows "R12-345" means "The software shall have a UI". Then in LabVIEW you can put down a comment on the BD or FP stating you cover that requirement. Then you can write a test document that proves that the requirement is in the build by having a user test that the UI exists and stating it covers that tag. Then you could have test results logged showing that the test was performed, and what steps passed, meaning those requirements in those steps were tested and were implemented, and so they were coded. When all this linking works well, it is beautiful. RG can generate matrix tables showing start to finish where the requirements go, from creation, to implementation, to test document, to test passing. This requirements traceability matrix can be stored for each build and then you could record coverage this way. It's a lot of work, and honestly most of the time it isn't worth it. But for medical devices, customers like to see the ducks in a row. Bug logging for me is separate and I haven't seen a good integration. Not that it hasn't worked, I just haven't seen it integrate with all the other tools for traceability.

Watch the Wednesday Keynote >> NI's Software Platform >> Around 7 minute mark http://www.ni.com/niweek/keynote-videos/ "Port the entire LabVIEW engine to Java script". Yeah I was messing with the Show Public URL function so that was probably it. I commend your efforts and hope it is in a semi-complete state when I have a need for this type of thing.

I never had good luck with this. Maybe it was older versions of TDMS but it never seemed to work right. I can try it again and see if it works right.

Not ignoring you, I just have nothing to add. Have you contacted NI?

Yeah I'm a big fan of TDMS and I still learn things every once in a while by experimenting. One thing that helps is as you already noticed, writing chunks of data. Basically calling the Write function as few times as possible. If you are getting samples one at a time, put it into a buffer, then write when you have X samples. Got Y channels of the same data type which get new data at the same rate? Try writing X samples for Y channels in a 2D array. I think writing all the data in one group at a time helps too but again that might have been a flawed test of mine. I think it made for fragmented data, alternating between writing in multiple groups. Because of all of these best practices I usually end up writing an actor that takes care of the TDMS calls which can do things like buffer, periodic defrag, and optimized writing techniques. A bit of a pain for sure when you are used to just write to text file appending data, but the benefits are worth it in my situations.

Pretty neat. I couldn't actually get it to display live data for some reason. I tried in the source, and the EXE and when running both only 8080 gave me a static image of the FP, and 8001 was page not available. That being said I was able to follow the code and understand it, and see where you can add methods for other control types. This isn't any thing new really, but no one has released a free version that worked well, and is fully open, as far as I know. Don't get me wrong I, think the toolkits others are making are awesome and hope they make lots of money off of them. But in many cases the bosses just believe "software is free" and are often leery about buying 3rd party toolkits. Wezarp is another one you've probably seen doing some self promotion. Even NI has been dabbling in it at some level according to their keynote this year. Until recently my development world was in a place where I would never really have a need for this type of software. But now I could see some places where this could be very handy. Especially with my somewhat limited experience with web design. EDIT: Oh and VIRemote is another.

Okay new version 1.3.0. This adds support for having only the 2015 runtime engine installed Adds the ability to abort all VIs in private contexts (still not clones) found in the settings window because I didn't think this was a common feature needed Several bug fixes with the registry, and screwing up what program controls what extensions Removed a few external dependencies (like pv.exe) Added a listbox to the settings for what file extensions this program takes over (by default VI and CTL) Moved config file location from Program Files to ProgramData folder Simplified open file process Few bug fixes for picking the right version of LabVIEW when selecting the only default option Added some asynchronous calls to help prevent a lockup from a non-responsive LabVIEW version. I really think this is the most stable version and have been using it for a few weeks without any real issues. I still have some locking up issues when LabVIEW doesn't respond but it doesn't happen often, and a restart of the tray program fixes it for now. I updated the page on my personal site, but here are the direct links. If for some reason there is an issue with it, closing it from the system tray (or taskmanager) and then relaunching LabVIEW should return things to the way they are normally. This is because on startup LabVIEW writes to the registry to take over the file extensions. Source 1.3.0 Installer 1.3.0

Either you misunderstood what I said, or you misunderstand what that expression means.