Jump to content

hooovahh

Moderators
  • Content Count

    2,945
  • Joined

  • Last visited

  • Days Won

    203

hooovahh last won the day on April 8

hooovahh had the most liked content!

Community Reputation

718

10 Followers

About hooovahh

  • Rank
    Im no supervising technician Im a technical supervisor

Profile Information

  • Gender
    Male
  • Location
    Detroit MI

Contact Methods

LabVIEW Information

  • Version
    LabVIEW 2017
  • Since
    2004

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Thanks for your contribution. A couple of things. Using polymorphics for this type of thing can become a pain pretty quickly. I had a similar thing for reading and writing variant attributes and used scripting to generate the 60+ data types I supported. But even then there were times that the data type wasn't supported. This also added 120+ extra VIs (read/write) adding to loading overhead. The more modern way of doing this is with a VIM that adapts to the data type provided. Your VIs were saved in 2015 when VIMs weren't an official thing, but you say you use 2018 where it is. Back then I'd still support doing this data type adaption with XNodes. Posted here is my Variant Repository which does similar read/write anything including type def'd enums and clusters. Putting these in a global space that any VI can read and write from is pretty trivial. All that is needed is a VIG, functional global variable, or even global variable in a pinch. This will keep data in memory as long as the VI is still in memory and reserved to be ran. This has other benefits of easily being able to load and save data from a file since it is all contained in a single place. Also with this technique there are no references being opened or closed, so no memory leaking concerns. Performance-wise I also suspect your method may have some room for improvement. If I am writing 10 variables 10 times, looking at your code that will mean 100 calls to the obtain notifier, 100 calls to the send, and 100 calls to the release notifier. I suspect reading a variant, and then calling the set attribute 100 times will likely take less time and processing power.
  2. So I just discovered this, this morning and I think it will help out in making VIMs when dealing with supporting a scalar, or 1D array data type. I have an example which is my Filter 1D Array VIM, posted here, which is heavily inspired by OpenG's implementation. In it the developer can filter out a scalar, or a 1D array of something from a 1D array. I did this by adding a Type Specialized structure at the start which checks to see if after building the array, if the data type matched in the incoming array. If so it is a scalar and should be used. I then have another case where the data just goes straight through thinking it must already be a 1D array. But what I realized today is that is unnecessary. If in the VIM my input is set to a 1D array, and we add a build array with only 1 terminal, and that build array is set to Concatenate, then that whole structure isn't needed. A Scalar will become a 1D array with one element, and a 1D array will have no items added to it after the build array. In this example the code simplification isn't much, but someone may have had two cases in a type specialized structure which handle scalar and 1D array separately and using this they could be combined them into one. And one other minor thing, I don't think I will actually be updating the Filter 1D Array VIM to use this, just because knowing if the input is a scalar means other sorting work not shown can be ignored helping performance.
  3. Far from perfect, but what I have at the moment, is on Mouse Move, Mouse Down, or Mouse Wheel event (with the limit to 1 just like you), read the Top Left Visible Cell. This gives the Tag and Column number. Using a second property node, write the Active Item Tag, and Active Column Number to what was just read. And then read the Active Cell Position Left. I then use a feedback node to see if the Top Left tag, Column, or Cell Position Left has changed from the last time the event was fired. If it hasn't do nothing. If it has, then go do what it takes to either shift the current image up and down, or left and right. Left and right are property nodes on the controls to move them, but value can stay the same. As for shifting and image up and down, I use Norms low level code found here, which is pretty fast, but I did have to add a couple of op codes to it since his post. Alternatively you might be able to set the image origin to get the same effect but that uses a property node, as apposed to the value of the image control.
  4. Well that or some really complicated stuff is happening. Here is a UI I've been working on lately. It is the view of a sequence that is currently running. On the left is a green arrow that moves to whatever step is currently being executed. Next to this is Goto arrows showing that a step has a condition that might jump to another step. Then there is the tree control that shows the sequence. In it is the step name (I blocked out many) then two columns that show some settings on the step with icons, and a column for a comment on the step. To the right is detailed information about the step that is currently selected. I'm welcome to have some feedback but here is how I made it. The green arrow is in a pane by itself. The arrow is 2D picture control constant, and the position of the control is changed but the value of the control never changes. The set of Goto arrows is another 2D picture control. This time it takes up the whole pane and is redrawn as needed. Since the user can scroll the tree, this means we need to poll the scroll position (on mouse down, mouse move, wheel scroll, limit to 1 event) and if it changed redraw the arrows. The While Loop can be collapsed and if that happens, the green arrow needs to point to it since the current step is in the loop. In this example if the while loop is collapsed, then the Goto arrows need to be removed. This is done by reducing that pane size to 0, making more room for the sequence tree. The tree is set to fill the next pane. The icons in the tree are two separate 2D picture controls (since icons can't be in multiple columns easily, and their size is 16x16). The position and value of them are dependent on the scroll positions of the tree. To reduce weird UI stuff when resizing, the 2D pictures must be aligned to be at the top of the tree control. The 2D pictures aren't transparent because doing so means the Erase First option must be set, which ends up flickering when scrolling since these need to be changed on scroll, window resize, or collapsing of the while loop. Because of not being able to be transparent, and wanting to align to the top, the 2D pictures actually contain the headers as part of their pictures. Maybe I could have done this with another pane. When scrolling too far right or left we want only partial column icons to be drawn so the column width is checked on scroll to ensure it looks right. Also since the pictures aren't transparent, the blue background of an icon is separate image. Oh and the scroll wheel works, and will mess with lots of these things. This mostly works well. But as you might guess it can take some time to draw all these things, figure out where they should go, and get it looking right. At first I had the quick and dirty of on any Mouse Move, Mouse Down, or Wheel Scroll event, just redraw everything. This meant tons of events firing all the time doing mostly nothing, and some times flickering the screen. So then I started looking at ways to improve it. If there is a value change on the tree, we don't need to update the Goto arrows at all, just the icons. Other information can be cached too to help with performance. Maybe we could draw all Goto arrow permutations on start, and then switch between them as needed then we wouldn't have to draw them. We would only need to move them vertically as needed. This is the kinda thing I was talking about when I said diminishing returns. Right now drawing that goto arrow is probably 10ms or so. But by complicating the code we could bring it down to 1ms. Is it necessary? Well no but if the total time of doing things adds up to be too much we could look into that to reduce the performance. Oh and to add to the complicated nature of this, this is the same UI that is used to create the sequence, with dragging and dropping and moving steps around, dragging Goto arrows around, and clicking icons to perform other actions like sliding in another subpanel, or changing the icons. In all of this, the defer panel updates is only used once, and it is on a full refresh which only happens on first load. Everything else we just update what we need and it has been pretty responsive.
  5. You probably already know this, but property nodes have a larger performance hit than a local variable when just the value needs to be updated. But if you want to update it in a subVI I get why you might use property nodes. The alternative there is to use the Set Control Values by Index function. You can read the indexes of the values you want to update in an initialization step, then pass on the indexes, and values you want to update. Of course this exercise, and this topic has diminishing returns. I mean lets say I just update all UI elements, all the time, periodically. The time it takes to update all of this can vary a lot based on what needs to happen but lets just say it takes 100ms which to be fair is a long time. Will the user notice it takes a while? Maybe. Okay so add the defer updates and lets say it is down to 50ms. Okay lets just update the elements that change 30ms on average due to some overhead. Okay use Set Control Values by Index, 10ms and you've added a decent amount of complexity to the code that might not have needed it. So for me it usually starts with just update everything and see how it goes, then refactor as needed. It feels like the lazy method but I've gone down the other road where I'm hyper concerned with performance and timing and I spend lots of time making the code great, but overly complicated which can make the code harder to maintain. Various tools can help minimize these issues, but then there are potential down sides of that too.
  6. I opened it in my 2018 and am missing all kinds of things, but attached is what LabVIEW came up with. In the future you might want to go to the Dark Side, because they have a subforum dedicated to this type of thing. Source 2016.zip
  7. Thanks everyone for giving suggestion and helping out other users. This is outside of my expertise and all I could give is a shrug and pass it along to Michael. It seems like this is isolated to a user, or a couple of user's setup and not a wide spread issue. If there is any real issue with LAVAG I can pass it along.
  8. I've never seen Jeremy's presentation, some neat stuff in there for sure. Since my demo (and another one here involving Notepad, Video here), I have cleaned up the VIs a bit with some basics like set Parent/Child relationship, get relationship, move and preposition, get/set menubar, resize status, and title bar, and a few other style functions. This hasn't been posted publicly but is pretty basic and pulled in from other examples on the forums. A more updated and complete Windows API could be useful.
  9. My go to site for this kind of thing was Flaticon but man this place is even better. Any idea what the licensing restrictions are? I couldn't find anything about that other than it is open source with no specifics.
  10. I don't have a solution to this but am interested in the topic. Darren also recently mentioned that this should work in 2020 for VIMs without the hacky work arounds found here.
  11. I think searching is limited to 4 characters or more. I'd also suggest Google is a better search tool than...well anything.
  12. Just an FYI Pi4 isn't officially supported by LINX yet, but several people performed some manual steps to get it working.
  13. So the Pi3 can be deployed to with Linx 3.0 as you may have found. This is an official toolkit from NI that adds the target in the project and you deploy to it like any other device, and is free. There is no front panel or UI when running on the Pi so keep that in mind. But the code can be deployed and set to run on startup so that it runs headless. There is some licensing to be aware of, specifically it can't be used on any commercial applications. NI has said that in collaboration with the LabVIEW Community Edition (free as in beer expected release in May) that the Linx toolkit is to also have some kind of new release. The same people that make the Arduino Compiler also make a Pi Compiler which can be used for commercial applications and has the front panel running on the Pi so you can plug in a monitor and see it. Other than the Pi, the MyRIO is really the intended platform for students. NI has partnered with Universities to offer a discount bringing the price of one I believe to $500. I'm not a student so I can't see it. But used ones on ebay pop up all the time from students who bought one for a class and no longer need it. I picked one up for under $200. The price of a raw Pi ($30-60) compared to the MyRIO ($500 retail) is a huge jump. But NI justifies the price with all the stuff you get. I mean the raw Pi doesn't even come with a case. But the MyRIO has a real-time embedded Linus OS, an FPGA, built in Wifi, USB network, USB host, a bunch of IO, and the support of NI. If your project needs an FPGA, and you want to program it in LabVIEW it is by far the cheapest option. If you don't need an FPGA then it can be seen as over priced. I'd start with the Pi3 and Linx and see what is possible. There are lots of online videos and tutorials and the upfront cost is pretty low.
  14. What is your use case that you need to turn it on and off? I suspect you already know but there is an INI key that turns it on and off but is only read on LabVIEW start.
  15. Okay I'm done guessing without actual testing in the environment. In Windows -1 on the Read From Text File, and Read From Binary File both read the whole file. I feel like there is a bug or two found in this thread.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.