hooovahh

Yeah using the original cable, and using no extensions is a good test to see if it works in any situation. You shouldn't have to have a work around, but if there isn't any other option, you can try to capture the error seen when the device is disconnected, then have your code retry to connect to the hardware with some amount of timeout so that if it goes away for a short time you can recover. This is of course only if the DAQ you are trying to measure isn't a continuous signal in which case the only solution is to not disconnect in the first place. Some NI USB devices have firmware updates, is this one of them? You can go into MAX, find the hardware, and there usually is a tab or button for updating the firmware. Have you tried other USB ports? They aren't all equal and some have less internal hubs than others. Have you seen this type of issue on any other computer? It is possible the device is faulty.

Not quite. So the VI macro works like the XNode (cause it is) where an input can have the ability to become any data type, then the type propagation within the VI will go through all the primitives inside, or polymorphic types, or whatever just like it does when you change the type on a wire in a normal VI. The output changes based on the input, in almost all situations, the reverse is not true. When you wire the output of an XNode the inputs don't change. The only exception I know of is with a few XNodes like my Variant Repository, which will look up stream when you wire an output, and then attempt to change the output to be the type that it is wired to. Another exception to this is the variant to data, where in some rare cases it will change the output based on what is wired to it, and the Type input can be left unwired. I would not expect this new structure to work this way. I suspect it just looks at the inputs and sees which cases cause no broken wires, then changes the outputs as needed. BTW can't wait for 2016 now, along with a few other beta features that will finally be given the attention they need.

I'm not NI, and this is slightly off topic, but in the past NI's answer has been that technical limitations came up when with the licensing of XNodes for public use which caused NI to stop looking into making it open. It sounded like NI (or some within NI) saw that this was a niche group of developers that would want this, and figured it wouldn't hurt to open it up, but ran into issues which were not easily overcome. With little reason to continue looking into fixing these issues, and with such a small group of developers who would use it, it sounded like NI wanted to invest in other areas instead. Being part of this small group I certainly am not happy with the decision and hope it changes, but understand why NI hasn't continued to work on opening it up as far as I know.

Again I never got around to implementing it, but I assumed the reason for having the double buffer size, was because you would then never need to perform a shift, which is where I thought the more intensive operation would be. By having a double buffer size I can perform a read and just have it read the subset of N samples that I want continuously, but of course to to do this a single write has to write to both halves of the buffer, but again no shift is needed. The method you described is close to what is currently implemented (in the non-xnode version posted), where there is one buffer, but it won't shift data, it will write it, and then if it gets to the end of the buffer, write again at point starting at 0. This means no shifting and no double writing unless you reach the end of the buffer. The trade off is that when you do a read you need to shift the data, if the subset you are trying to read wraps around the buffer, if it doesn't no shift takes place. Since the shifting was taking place anyway on some reads, I had the read function write the shifted data back, so the next write starts at pointer 0 again. These are the 3 implementations I've thought about with minor details changing how it is done under the hood, causing different performance. As I mentioned before the current implementation is probably better than most if you are writing more often then you are reading, which was my case when I was needing this. I never did any bench marking between these three.

I'd also suggest you wire directly to the PC. Using any hubs powered or unpowered is asking for trouble.

I went looking into the 2016 beta I had and I couldn't find this. Is this a thing that isn't in the beta but is intended to be in the 2016 release?

Other than the discussion mentioned, where you can load the LabVIEW OS (Pharlap?) in VirtualBox, there has been no new progress. This would be a very cool thing to have, but my I wouldn't know where to start. If you make any progress on this be sure and update this thread, or the one linked to the following thread.

Yeah I like that. It could fix several things I've been thinking about, like what if you want to adapt an input to a 1D of any kind of data, but it must be a 1D array? Then you could have a case where you wire your input into a Search 1D array, which would break if a 1D wasn't wired. Not sure how this would work for performance performing a task with a primitive, whos output isn't used. The compiler might optimize away code and do strange things. Want to ensure only a cluster is wired? Wire that input to an unbundle function. Want a 2D of something? Wire to a transpose. Still there are times when I want more complicated checks, like the input is a cluster, and one of elements is a numeric, and has a label of XYZ, but I guess that's when XNodes could come in.

So usually this is where I mention that discussing the beta material on the forums is against NI's NDA, and how you probably shouldn't talk about it. But in this case I'll let it go for more than one reason. Welcome to the forums. Can't wait to play around with the expanded VIMs in 2016 that feature does sound useful. If you are reading LAVA's discussions about VIMs I hope that you've realized one of the key features we'd like documented, is how to force a control to be a defined type, and not always adapt to type. I see that code for this has been started in the VIM XNode but doesn't appear to be complete, and relies on arrays of strings on the front panel labeled something specific. I'd suggest adopting what has been used on the right click frame work, assuming NI has gotten good feedback. Here you can have a control defining the types that an input can become, or choose it to be the one type it is in the template, or choose it to adapt to any type. The configuration of this matters much less to me, than the fact that it actually works. I'm not a fan of having to jump through hoops to get things to work, but I am grateful when those hoops exist.

Sure thing, attached is my Post-Install. It will look at all MNU files installed, and look for any files that share the same name as the XNode, and replace them in the palette, with the actual XNode call. I add a suffix to installed VI files so my Post-Install only looks at the name before the _ suffix, because the suffix isn't added to XNodes by VIPM. It has a few OpenG dependencies, so if you are making a package be sure and add those to the dependencies list, so that they will be installed before trying to run the Post-Install VI. Oh and you'll want to open it and resave it, I back saved to 2012 and assume paths to the OpenG library might be messed up. As for the reply, some of the abilities describe being able to be called, here is the description for the GetTerms4 ability: But as for a formalized list, I just don't have one. Here are a few other string values I've seen put into the Reply and have things get called. UpdateImageAndBounds, UpdateTerms, GenerateCode, Initialize, this list just comes from seeing what others have done. Post-Install Custom Action Replace XNodes in MNU.vi

You should never use the abort execution button, unless you have to. Pulling the rug from under any application is a bad idea and you should allow it to perform the cleanup operations that the developer made for it. Many times in the LabVIEW world it has been said that using the abort button is like crashing your car into a tree to stop it. It will stop the car, but it may have other consequences. The more proper way to exit is to hit the red X in the upper right corner of the window, but of course for that to work the developer needs to add the Panel Close? event to an event structure, and then cause the code to perform the cleanup that pressing the stop button would have done. In this example this wasn't done because it is just an example and not a full application. As for your other question, the last time I needed to upload a website for free I used comlu which is apparently hosted through this site: https://www.000webhost.com/features They have FTP and other basic features, but there is no way you will be able to install the LabVIEW run time engine and various other tools to make this work from there. If you need to have a site that is driven by this technology, you are either going to pay for full access to a VM, or make your own VM and run a web server from it. I think this tool primarily can be useful from within a network, where a computer with a static IP in the corporate network can just serve pages for access within the network.

You actually can put an XNode directly on the palette. Look at the Add-ons >> Find LabVIEW Add-ons which on first being created will open up a web page. A fun little trick that you can use to do something to do all sorts of things on first copy. I have one function that can open a folder to a network location where some specialized documentation is stored. When you are editing the palette manually, you just need to change the filter on the browse dialog to show all files (*.*) and select an XNode and it works as it should. For VIPM there are a few tricks, but the best I've come up with is a using the Post-Install action VI. In the Post Install you can see what VIs were added to the palette, so I will search for any XNodes, then see if a merge VI was made for that XNode (just the same name but different extension), then read the functions palette, replace the path of the merge VI with the path to the XNode, and then resave the functions palette I opened. A bit of a pain for sure, but once you have it working the updating or adding new XNodes can be done just by making a merge VI, and adding it to the palette, then the Post Install does the rest. But for your situation I wonder if the Copy ability will work just as well, where the dialog is seen on the creation of the XNode instance.

The Webservices dependency has been removed. All that is needed is to run the Example.vi, then open the Example.html in a web browser, I've been using chrome because of the awesome page debug and inspect features. Because of this it might be possible to use this on an RT system as well, you just might have to generate the HTML, and JS files from a host.

That's the only downside I can think of is the thread swapping/performance. Still not sure why it works this way, it could be a bug, I'd post on the NI forums and see if you get the attention of someone at NI.

Wow that is strange. So all methods to try to get this information out of the New Value, is going to fail because that information simply isn't there for some reason. OpenG has a few methods, and NI has newer Variant functions in 2015 and those also won't work. There is also a few methods to disconnect type defs but that doesn't seem to help. One method that does work, but might not be desired is to use the control reference in the event, then go to a property node and read the Value then get the name from this. I'd recommend getting the name the way you currently have, and then use this method if the name is empty. You can also use another function to determine if the variant is a type def, and if it is then use the property node method.

Wow this is a lot of fun. So I have code now able to move and resize the images by updating the style attribute along with the new image data sent. Other control moving and resizing isn't done yet but could be. I also updated the Select class to support changing menu items. This means if you have a Ring with 3 things in it, you can update it with a property node to have 3 different things, or 4 things, and the select item in the web page gets updated. I also worked on reducing the amount of data sent. Right now on the refresh interval all data is resent, and for images that don't change often that is a lot of wasted time and resources. So if the data hasn't changed from the last sent data it doesn't send it. The exception to this is on the first load of the page it requests all data. I'm not going to post these changes just yet, I'd like to see if there are any other bug fixes or features I'm going to implement first. Once again thank you so very much for getting this started, so much useful code in here, and having it be open is the best part so that changes like these can be made by anyone with the time.

Okay I'm not quite done updating it but here are a few improvements I was able to make. The refresh rate is defined by an input, along with if borders should be drawn at the size of the front panel or not. I'm thinking this should probably be a setting in the config file that already exists but for now this is inputs in the Publish.vi. Controls that don't have a specific type defining how they should look default to the Control Class, which will show the control as an image. This means the Show as Image setting is ignored for control types that don't have a specific class handling how they should be displayed. Two examples of this are the cluster with random things in it, and a custom array that shows alternating picture ring images. I believe I have scrollbars working. To do this I had to change the Body HTML, and all controls, decorations, and text to absolute positioning, and then adjust their Left and Top positions slightly because of the drawn border. Now if the web page is too small to show all the items in it (including drawn border, and controls outside the FP) then scrollbars appear. Something I would like to see, and have no clue how to do at the moment, would be to handle controls moving, or being resized. The example that came to mind was if I have an array with 20 large items in it, then I could set the number of rows visible to 20 so all items can be seen, and the scroll bars I mentioned earlier would scroll the page showing all items. But then if I later only have 2 items to show, I'd like to set the number of rows visible to 2, then send the new image with just the two items in it. The problem right now is, the page expects the image to be the size when there are 20 rows, so it stretches the image of 2 to the size of the 20. What I would like is a way to update the HTML file, and then tell the page to refresh the whole thing if something in it changed size or possibly position. Any thoughts on how to do this? Thanks. FPPublisher Hooovahh Edit.zip

So what was needed to make this work? I have an array of controls that I would like to be seen as an image. I found in the ObjectFactory.vi that I needed to add the Array class to the Init state, and then add a state in the Finish state to create the object, where I used the Control class. Then when I ran the VI it asked how I would like to configure that control and I choose as an image. But in the web page all that was seen was an outline of the array control, and nothing inside it. Ideally what would be useful is any control that doesn't have a class made (default case) would be represented as an image rather than having to make special edits for each control type. I had another feature request that I thought would be useful, and that is to have visible scrollbars in the webpage when needed. I tested this by making my VI front panel large, then ran the webpage and no scrollbars were seen. I then made my window small and they never showed up. Is there something simple in the HTML page to enable these?

Who has to deal with DDOS, spammers and abusers? Primarily Michael, forum members to a lesser extent because we are affected too. So I think it should be clear that this decision is in Michael's hands. If I had a vote I'd say to have it open, until something goes wrong, like some script kiddy downloading all CR items continually for days. If that happened once I'd lock it down. But if Michael thinks you should be required to login to perform some actions then that'd be fine with me.

I've certainly worked with other ones, but they mostly all suck for one reason or another. Another issue is all the other cheaper, crappier ones, are so forgettable I don't remember the brand or model. I've heard good things about the BK, but haven't used one programatically before.

Certainly not lots of cases, but even if there are two it is some times easy to update one, and forget about the other. Especially if some other developer is the one maintaining my code.

In this case scripting is your friend. You can have a tool that finds all instances of a type def, that is a constant, and then replace that constant with the updated one. You might have a problem with typed controls that contain that type, that now need to be updated. As for combo box, it isn't terrible, but again if I have a function that really only has three modes I want an enum and then I'll update it later if a 4th mode is added, and every place I have a case structure without that new case being handled, my VI will be broken (assuming no default case which you can do with an enum). With a string you have to have a default case which handles all cases not handled. Also there would be added code to handle if a case is called that doesn't exist, where I know that can't happen with an enum. But again all of this could probably be wrapped in another abstraction layer and these issues could go away with more code.

Yup, there are just some places where rings are so damned convenient. I can have a list of common baud rates for hardware on the UI like 500K, 250K and it translates to a decimal value of 500,000, but then I can have an Other option where the user types in what they want and my code does its best to work with it. Having to translate that back into enums, from enums back to rings, while supporting an "Other" mode, and saving and loading from disk can be a pain. Come to think of it, this would probably be a good place for some OO and classes to handle all of this. But still this is a bit of a band-aid when the IDE could support sparse enums.

While NI takes applications into the project provider, there are some unofficial ways to use it. Of course this comes with no real documentation. It's a bit of a mess really, NI seemingly didn't put in the effort to make this a polished API likely due to the fact that few people would want to do this. Adding items to the menus are a much easier process and in most cases just take putting a VI in the right folder, and then setting it to run when opened. http://digital.ni.com/public.nsf/allkb/2ED4443B186788E18625714000757C03 Oh and while QuickDrop can make the editor a bit easier to use with scripting functions, there are only so may keys you can use, and then there is the fact that you need two shortcut keys to invoke your function. A better idea might be to put something in the tools menu, then invoke it through a single shortcut command. This can't happen today, but there is already an idea exchange item for it.

Based on how seldom the toolbar has changed over the years, I suspect it is not a plugin based design. The buttons you see are the same buttons that have been there (with a few exceptions like cleanup) since 2004 or earlier. If it changes that little, I doubt NI made it a plugin design. You can put things in various menu bar items, like Tools, and File which can be useful for calling VIs to perform actions on the open VI. And there is the Project Provider Framework, which has the ability to add items to the project toolbar, but not many people do this because it can be a pain to work with, and is somewhat incomplete. That being said this is probably a good idea for the Idea Exchange.