hooovahh

You probably already know this but, as far as I know, no NI software has been released, which officially supports Windows 10. This usually doesn't mean it won't work, and I've heard some people say they have LabVIEW 2015 on Windows 10 and haven't seen any issues yet. But it looks like others are having various Windows 10 issues. Until February I'm guessing there isn't much we can do without NI support. http://forums.ni.com/t5/LabVIEW/Windows-10-compatibility-with-applications-developed-in-LabView/td-p/3169517 http://forums.ni.com/t5/LabVIEW/compatibility-with-windows-10-and-DAQmx-14/td-p/3197358 http://forums.ni.com/t5/Multifunction-DAQ/Windows-10-myDAQ-Driver-Not-Working/td-p/3182525 https://forums.ni.com/t5/LabVIEW/Windows-10-with-two-task-bars/td-p/3198937

Oh and there is the Windows power settings you may want to check. Windows can choose to turn off USB ports seemingly randomly to save power.

I would not recommend posting your email on a public forum, spam bots crawl these sites. That being said the examples you are asking for are from the actual exam and cannot be shared or discussed. "It would technically be against their NDA for people to give out information on those since they are the currently active CLD exams (that I know of). Do not expect to get any information on those or people will lose their certification." Study the example exams, be familiar with these 6 scenarios, and feel free to post on the certification board. http://forums.ni.com/t5/Certification/bd-p/Certification

Generally you open once, do your work, and close once. Generally you use Synchronous messaging so that you don't need to worry about time delays in reads or writes it just returns the data when it is ready. Not all protocols support this, but most end with a return character making it relatively easy. If you are questioning LabVIEW, try writing a simple serial VI that opens, reads/writes and closes then run it for hours to check your sanity.

After launching the Clear Compiled Object Cache from Tools >> Advanced >> Clear Compiled Object Cache... a window appears with a listbox showing two items, User and Application Builder. By default both are already selected just click Delete. If you only want to delete one select that one, then click Delete.

A lot has changed in 4 years but this still seems to be the normal behavior of a tree control. At some point the multicolumn listbox was improved to actually realize when a column was deleted by right clicking, and adjust horizontal scrollbar size accordingly. But there isn't a similar option for a tree control. Replacing the control does indeed convince LabVIEW the number of columns are different, and that is how I've always handled this situation. One step that might help make this process easier is you can replace a control in LabVIEW, with one in your clipboard, and have all the references, and events on that control go to the new one. I tested this and it does behave as you'd expect in terms of the number of columns. I created a tree with a string in columns 3 and 4, then deleted the string in column 4 and saw that the size according to the visible scrollbar still shows column 4 in the size. I then created a new tree, copied it to the clipboard, selected the old tree and pasted, which replaced the old one with the new one. Changing the column width to 1 pixel can work as well.

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.