All Activity

I did do something similar years ago and posted the code here. With a youtube link demoing the graph functions. I never actually used it on a real project but put some decent time into the UX. It also allows for dragging out the graph into a new semi transparent window. It is not a generic framework, and mostly a proof of concept that could be used in an application, if you don't mind the various limitations, and restrictions.

I don't have anything to contribute to the development here. Only to say that I really like this type of function, and looking at your source it sure looks efficient. Thanks for sharing.

C:\Program Files\National Instruments\LabVIEW 20xx\resource\PropertyPages\Pages\Format & Precision\pp_SetControlF&PString.vi Valid if no error.

Does anyone know if there's a VI hidden away in the LabVIEW directory somewhere that returns whether a Format String is valid eg the "Valid" Boolean on the screenshot ? I'm terrible with regex but I can get an AI code generator to make a regular expression but I'd rather just use a LabVIEW built-in VI to be "safe". FYI this is the regex generated by AI if anyone cares: %(?:\d+\$)?(?:[-+#^0])?(?:\d+)?(?:[._]\d+)?(?:\{[^}]*\})?(?:<[^>]*>)?[a-zA-Z%]

Tested that, all paths are relative. As I mentioned, I moved my whole LabVIEW code to a different volume (by simply copying the whole development folder, preserving the folder hierarchy in which the different dependent libraries were located), and the project loads just fine. Since I am releasing the dependencies with the same folder hierarchy, I don't think this should cause problems to someone forking the repo. Having the dependencies in vi.lib would require messing up with the user's installation, which they may not want to do. I don't think I have any of those. I use a few polymorphic VIs, but none recursively. Overall it seems like I am better off writing my own source distribution release script, copying whichever file is needed, but that's sounds fairly tedious, as I would have to build a list of dependencies, etc. Or simply release a mock distribution to get that list of needed files, and then pick the original ones an copy them to my destination path?

I have similar problems now and again but it's not VIM's. Some things to try to sniff out the problem: Check project files and lvlibs with a text editor. If you have full file paths then that's a problem. File paths should be relative BUT! LabVIEW cannot always use a relative path (for example if it's on a network, different drives et.al.) Sometimes LabVIEW also gets confused but you need all paths to be relative even if it means reorganising how you structure your files. Do the above and put all dependencies in VI.lib. If you are using source control, checkout dependencies to the VI.lib directory, not your own file organisational preferences (some people like to have them on a different drive, for example). The litmus test for this is that you should be able to move your project to different locations without getting the VI searching dialogue. The search will invariably put a full path in when it finds the file-don't let it. Recursion breaks the project conflict resolution. If you have recursive functions, make sure they are not broken by manual isepction. The usual symptom is that there are no errors in the error dialogue but conflicts exist and VI's are broken somewhere. Polymorphic VI's hate recursion. If you are using polymorphic VI's recursively, don't use the polymorphic container (the thing that gives you the drop-down selector)! Only use polymorphic VI's as interfaces to other code - not itself. If you are using the polymorphic VI recursively then use the actual VI not the polymorphic container. If something gets broken you will go round in circles never getting to the broken code and multiple things will be broken.

This is too basic be of any interest to any of the gurus out there, so I am just typing this as a record of problems to be expected when releasing a source code in LabVIEW (in the way I had intended to do it). Recap: I have a development folder where there are a number of VIs that I do not care to release (in addition to other files). That folder is under revision control by git. I do not want to make that repo public, but I want to release the actual useful code in a clean repo. My approach: I select a Source Distribution in my project, in which I define which VI (+ libraries and other files) I want to save and where. There are a number of dependencies in other outside folders, which I export using the "preserve disk hierarchy" option to help with finding this VIs in the release. When running the build, I have no issue. I need to create a different lvproj file in my release (but this is a one of affair) so that it doesn't refer to VIs that have not been released. I essentially drag all the lvlib files I have exported into that project, and reorganize things within virtual folders for convenience. If I open the top level VI in that project, and run it, everything works like a charm. However, underneath the hood, everything is screwed up. Every single VI and library shows up as "in conflict". Opening up the Resolve conflict dialog doesn't help, as none of these conflicts appears resolvable (all "Select this version" buttons are grayed out). The crux of the problem is that there are two available paths for each VI, the new and the old one. Clearly LV knows which VI to load when running the top level VI (the new paths ones), but somehow, the project is "in conflict" anyway. lvlib files seem to refer to VIs by relative path, so they shouldn't be the issue. VIs seem to store absolute paths in their data, so I suspect this the cause of the problem. I have tried a number of workaround to fix the issue (releasing the distribution anew each time), to no avail: - selecting different options in the "Additional Exclusions" tab - uncheck "Preserve disk hierarchy" in the "Destination" tab - Move the source to the same volume as LabVIEW (so that there is no need to distinguish between files in "C:" such as Windows dlls and files in the other volume)

To analyze large time series remotely I have a client application that splits the data transfer using two methods; It will break down the periods into subperiods that is then assembled into the full period by the receiver *and* if the subperiods are too large as well they are retrieved gradually (interlaced) by transferring decimated sets with a decimation offset. So, as a result of this I need to merge multiple overlapping fragments of time series (X and Y array sets). My base solution for this just concatinates two sets, sorts the result based on the time (X values) and finally removes duplicate samples (XY pairs) from it. This is simple to do with OpenG array VIs (sort 1D and remove duplicates VIs) or the improved VIM-versions from @hooovahh, but this is not optimal. My first optimized version runs through the two XY sets in a for-loop instead, a for loop that picks consecutive unique values from either of the two sets until there are no such entries left. This solution is typically 12-15 times faster than the base case (<10 ms to merge two sets into one set with 250 000 samples on my computer e.g.). Has anyone else made or seen a solution for this before? It is not as generic as the array operations covered by the OpenG array library e.g., but it still seems like something many people might need to do here and there...(I had VIs in my collection to stitch consecutive time series together with some overlap, but not any that handles interlacing as well). It would be interesting to see how optimized and/or generalized it could be solved. I have attached the two mentioned examples here , they are not thorougly tested yet, but just as a reference (VIMs included just in case...). Below is a picture of the front panel showing an example of the result they produce with two given XY sets (in this case overlapping samples do not share the same value, but this is done just to illustrate what Y value it has picked when boths sets have entries for the same X (time) value): Merging XY series LV2022.zip

Well, there are two aspects. The first is the technical one from hackers diving into the software and unhiding things that NI felt were not ready for prime time, to complicated for simple users, or possibly also to powerful. The main reason definitely always is however: if we release that, we have to spend a lot more effort to make it a finished feature (a feature for internal use where you can tell your users: "sorry that was not meant to be used in the way you just tried") is maybe 10 - 20% of development time than the finished feature for public use. There is also support required. That costs money in terms of substantial extra development, end user quality documentation (a simple notepad file doesn't cut it), maintenance and fixing things if something does not match the documented behaviour. And yes I'm aware they don't always fix bugs immediately (or ever) but the premise is, that releasing a feature causes a lot of additional costs and obligations, if you want to or not. The other aspect is, if someone who is an active partner and has active contacts with various people at NI, he is infinitely more likely to be able to influence decisions at NI than the greatest hacker doing his thing in his attic and never talking with anyone from NI. In that sense it is very likely that Jim having talked with a few people at NI has done a lot more to make NI release this feature eventually, than 20 hackers throwing every single "secret" about this feature on the street. In that sense the term "forcing NI's hands" is maybe a bit inaccurate. He didn't force them, but led them to see the light! Not out of pure selfless love, but to be able to officially use that feature for himself. The according Right-Click framework was a proof of concept to see how this feature can be used and mainly an example to other users how it can be used, and indeed once it worked it had fulfilled its purpose. That it was not maintained afterwards is not specifically JKI's fault. It is open source, so anyone could have picked up the baton, if they felt it was so valuable for them. The problem with many libraries is actually, if they are not open source and free, many complain about that, if it is open source and/or free, they still expect full support for it! In that sense I have seen a nice little remark recently:

Oh, so is It now JKI who "forced NI's hand to release scripting"?! Isn't that too much of a credit for him/them considering when he released his framework relative to the previous community efforts mentioned above? Maybe it became "the last nail into the coffin" of the "VI Scripting is for NI use only", but definitely not the only and not the "thickest and longest" one.

Thank you Michael. Good point. Yes, I've noticed the dynamic approach here and there as well as using SoftMotion with EtherCAT but had no chance to dive in yet. I will take a look at the other methods later this year when we start working with ELMO (Platinum) drives.

I have worked extensively with several of my customers with Ethercat devices using the NI solution. I'm glad you figured it out. It seems like you're on your way. Finding the ESI file is the trick and making sure it's "installed" on the cRIO and the PC side. To echo what Rolf mentioned. You will get very little support from NI if things go wrong, or if you want to do something that is outside of the typical use-cases. Note: you have zero control over the topology of the Ethercat network. NI hides this network discovery algorithm, and you cannot influence it. This comes up when you have more than one device on the network and/or you have Ethercat switches in the mix. For example, if you daisy chain another device it will be named device 1 (in your image, your first one is named "device"). If you swap the devices in the chain, they will also swap position and hence, names and you cannot control this behavior. In other words, the physical network cabling dictates the device list order and naming you see in your project. This might not affect you, in your case, but something to be aware of. Especially since your shared variables will be invalidated. Personally, I don't use statically defined shared variables because I typically work with highly dynamic systems. But using your approach will work just fine and is the easiest way to get started. There is a way, to dynamically discover devices on the Ethercat bus. Here is an NI article describing this: Programmatically Discover and Access EtherCAT I/O Items - NI This might be useful and good to know in case you need this approach.

I am running LabVIEW 2024 Q3 on a cRIO-9047 with the embedded UI enabled. Two days ago I left the cRIO running overnight. The next morning the display port was not working. I found an NI support page that suggested sending a command to keep the monitor alive so I put that in. I left the cRIO app running overnight again last night. In the morning the FPGA code was still running, evident by the user LED blinking which I put in the FPGA code. However, the screen is frozen. I am not sure if it is just the screen or the application but neither the mouse nor keyboard respond. Neither can I connect from windows so it appears the cRIO is locked up. However, I can ping it but WinSCP cannot find it. I power cycled the cRIO and it started back up fine. I was really counting on using the embedded UI feature.

Ah, yes, thanks. The attachment in the original post is now without the OpenG dependency and has been converted back to LabVIEW 2018.

Nice. If you replace the OpenG VI with the above then we don't need to install all those dependencies for your demo What do you expect the cancellation behviour to be? Press escape while holding the mouse down? Mouse up cancels unless the dragged window is outside the main window? Both? Something else? I wouldn't want this feature to be a "framework" though. It would need to be much easier than that. Maybe a VI that accepts control references and it just works like above on those controls?

Another part of this history: JKI forced NI's hand to release scripting (officially supported and open for everybody to use) with their Right-Click Framework. This is how I discovered scripting. I think I even wrote one or two plugins for myself. Then something happened in LabVIEW 2011 or 2012 that broke it. I asked Michael Aivalotis about it and that's how I found out this part of the story. JKI had no intention of fixing the issue because their mission was accomplished.

Many years ago I made a demo for myself on how to drag and drop clones of a graph. I wanted to show a transparent picture of the new graph window as soon as the drag started, to give the user immediate feedback of what the drag does and the window to be placed exactly where it is wanted. I think I found inspiration for that on ni.com or here back then, but now I cannot find my old demo, nor the examples that inspired me back then. Now I have an application where I want to spawn trends of a tag if you drag the tag out of listbox and I had to remake the code...(see video below). At first I tried to use mouse events to position the window, but I was unable to get a smooth movement that way. I searched the web for similar solutions and found one that used the Input device API to read mouse positions to move a window without a title and that seemed to be much smoother. The first demo I made for myself is attached here (run the demo and drag from the list...). It lacks a way to cancel the drag though; Once you start the drag you have a clone no matter what. dragtrends.mp4 Has anyone else made a similar feature? Perhaps where cancelling is handled too, and/or with a more generic design / framework? Drag window out of listbox - Saved in LV2018.zip

This is pretty accurate. I know one ex-coworker in particular had an RSS feed push to his Outlook every post on LAVA. When LAVA had a major crash his Outlook was used to restore as much content as was possible. As for the content moderation, we try to self police our selves, enough to not get on NI's bad side. I have very rarely ever needed to intervein. One time I had to ask one user, to tread carefully on the topic they were sharing, but I did not delete any content or post. Thanks for the additional history. Jim has mentioned this story to me in the past but I didn't remember the details. I believe there was a meeting with NI where they were insisting that the scripting code wouldn't be made public, and someone called their bluff basically stating the tools for scripting are already being made by the community, and that if these were good enough for NI to use, we should also have access to them.

This is by no means a full EtherCAT tutorial but, rather, introductory notes. Please, feel free to add to this post, expend and/or correct any mistakes and information.

A peculiar thing about the EtherCAT slaves is that you must have an ESI (EtherCAT Slave Information) file for your slave. This is an XML file that describes the EtherCAT specifics and application specific features of the device. Those are available form the device manufacturer's site, e.g. https://new.abb.com/drives/connectivity/fieldbus-connectivity/ethercat/ethercat-feca-01. If you cannot get an OEM's XML file for your device, you can (theoretically, I've never done it myself) edit one of the existing files (or create a new one) either manually or with a help of special ESI Editors (cost money and, usually, manufacturer-specific). E.g. https://github.com/CopleyControlsOfficial/EtherCAT-ESI-File-Examples.

Setting up the project:

NI article: https://knowledge.ni.com/KnowledgeArticleDetails?id=kA03q000000YHbbCAG&l=en-CA

So, what I dug up so far: 1. Many compactRIO can be set up as an EtherCAT master. You don't need any special hardware for that. In fact, even your laptop Ethernet port can be turned into an EtherCAT master with the proper set of drivers (not covered in this post). Nevertheless, check if your chassis supports EtherCAT mode - go to https://www.ni.com/pdf/manuals/374786m.html and see if it listed under Supported EtherCAT Masters. 2. Download EtherCAT drivers here - https://www.ni.com/en/support/downloads/drivers/download.ni-industrial-communications-for-ethercat.html#485587. First, check your LabVIEW compatibility with the EtherCAT drivers here - https://www.ni.com/en/support/documentation/compatibility/17/ni-industrial-communications-for-ethercat-and-labview-compatibil.html. Install the drivers to compactRIO under Custom Software Installation. Configure one of the Ethernet ports as EtherCAT master.

NI was quite invested in EtherCAT circa 2012 to 2016 but then lost its interest in anything not related to big turnkey testing systems. The Industrial Communication tools were part of that together with Motion, Vision and pretty much anything else except DAQ and PXI. Basically EtherCAT after about LabVIEW 2017 is more of a "Take it as it is! If it works for you, great! If it doesn't, please don't bother us!" Even in LabVIEW 2017 it was still far from a Plug and Play experience. I worked on a project at that time, trying to interface a Industrial Controller IC-3173 to several different EtherCAT hardware. It was a long and tedious process and back then we could actually talk to support people who tried to help but often were stumped just as much as we, why something didn't work. There were many subtleties and it was not always NIs fault when something didn't work, but it was very difficult to get a deeper look into things as NI tends to hide a lot behind simple looking configurations. At this point I have very strong doubts that anyone at NI even knows how any of these Industrial Communication Products work. They still sell a few things that can work if you are lucky, but if it doesn't work, they can't support it in any way, since there simply is nobody anymore who has worked on these products in many years. The good news is that NI definitely has been getting a lot more proactive on a lot of subjects in the last year. Their efforts to get the community involved again, still need to be fully realized but the communicated intentions are strong and fairly consistent, so I dare to have hope. From some communications I had with them, it seems that they actually are planning to be more concentrated on certain core areas and actively look for 3rd parties in the market to provide alternative solutions for the products they don't consider a core technology. Industrial Communication interfaces seem one such area, where they would seem happy to promote an alternative rather than maintaining their own solution, but they might pick up on some of them, as they are not all as easy to support for 3rd party providers.

Not likely. I think the Administrators always resisted such requests unless there was a real legal matter involved. But LavaG had several nervous breakdowns over the years, either because a harddisk crashed or forum software somehow got in a fit. It was always restored as well as possible, but at at least one of those incidents a lot got lost. Some of that was consequently restored from archives other people had maintained from their push notifications from this website, but quite a bit got lost then. You can still see some old posts where the whole text is underscored and links for as far as they are present point into nirvana. These are supposedly not well restored posts and by now of at best historical value, so hard to justify to try to clean up.