Jump to content

UnlikelyNomad

Members
  • Content Count

    31
  • Joined

  • Last visited

  • Days Won

    4

Everything posted by UnlikelyNomad

  1. https://youtu.be/4pDHBrBRILQ I've managed to get the runtime happy enough to run on the RockPi S, a 64bit quad core SBC that's a third the size of a Pi. The LabVIEW stuff is still 32bit of course but this opens the door for supporting even more devices. One of the tricks I pulled to get it to work is to first enable armhf (32bit packages) on the RockPi, manually edit the lvrt20-schroot package metadata to remove its dependencies on schroot and python since it was trying to install the 32 bit versions, and just manually install those packages before manually installing the edited lvrt20-schroot package. I also needed to install netbase for the labview service to start and I installed binutils to get the tools on the RockPi to unpack and repack the package. I'm looking to automate this process but I'm not sure how to do all the architecture specifications from the commandline. If anyone has insight on easy ways to accomplish this I'd love to hear them so I can extrapolate this to other devices as well (looking at the Banana Pi M2 Zero next). This assumes you've got the RockPi up and running and can access it already: ssh/console/shell into device >mkdir lvrt20-schroot >cd lvrt20-schroot >echo "deb [trusted=yes] http://feeds.labviewmakerhub.com/debian/ binary/" | sudo tee -a /etc/apt/sources.list >sudo apt-get update >apt-get download lvrt20-schroot:armhf >sudo apt-get install schroot python avahi-daemon netbase binutils nano >ar x lvrt20-schroot_20.0.0-4_armhf.deb >tar xzf control.tar.gz >nano control Remove the schroot, python entries from the Depends: line Ctrl+x to exit, Y to save, use same filename >tar --ignore-failed-read -cvzf control.tar.gz {post,pre}{inst,rm} md5sums control >ar rcs lvrt20-schroot.deb debian-binary control.tar.gz data.tar.gz >sudo dpkg --add-architecture armhf >sudo dpkg -i lvrt20-schroot.deb
  2. Am I missing something? Where did the drop down go for the grouping options? Why are there menu entries left in that just give an "unimplimented" popup message? Is there an older version I can find someplace to revert to? Is the version on the CR on this site out of date?
  3. Oh yeah, queue terminals do update. So inconsistent behavior.
  4. Ohhhh I gotcha now. This I do see. I'd say this isn't a bug and is consistent behavior. Change the data type feeding into a string indicator and you get a broken wire instead of a new indicator. Type defs are the only thing that propagate updates so without a type def to update you would break data types to controls/indicators.
  5. Making progress on the accessor! Just need to make the two templates now and script up the template editing.
  6. Several times I find myself having to copy the content of my post, refreshing the page, and pasting the post and submitting it again because the post won't submit initially. Not sure if there's some issue with how long I take writing a reply, or it's something with chrome where I'm going to other tabs and then coming back but pretty regularly, and on different PCs, I have to refresh the paste and redo the post for the submit button to actually work. Fun fact: I'm about to copy/paste this because it's doing it on this fresh topic as well.
  7. Any chance you have an example of this? Not sure I've ever run into something like this before. I update typedefs all the time and haven't had my start async calls get boogered up. Though I do currently have NI pursuing a bug where a typedef isn't getting namespaced properly when compiling to a PPL and thus breaks all the calls once compiled because the static ref still specified SomeLib.lvlib:SomeClass.lvclass:SomeType.ctl instead of SomeLib.lvlibP:SomeClass.lvclass:SomeType.ctl which of course I can't recreate in dependent components. As long as I'm testing the uncompiled component with the static ref, everything updates as expected for me.
  8. Francois, thanks for the elucidation! I don't use frameworks like AF so I haven't run into too much hierarchy bloat and I tend to compile lower level libraries into PPLs to be used by higher levels; I'm thinking that limits how much LabVIEW can check for during type propagation since I only have one editable component open at one point. Since I'm doing ByRef I often do have to break type safety and store some relationships as base objects and then always cast them when pulling them out of the DVR for use (since you can't have a DVR reference another DVR that references the first) so this may also cause a similar optimization. IE: a server keeping a list of open connections and those connections keeping a reference to their originating server.
  9. Still unsure why this is a thing though. Duck typing? Union like tricks? Seems like this should be used in very specialized instances and not to transport data around. Even in C++ pointers have type and this completely erases type safety.
  10. I could convert this to a Tools item. Make it an either/or. I definitely like the ability to interact with the item itself. I've come back to this first paragraph several times to take out reasons why I'm less favorable to the tools menu; maybe that'll be next week's side project. What I am avoiding is conditional menus based on current state of an item; you use it right or you don't. The actions to check compatibility but it's after you select it and not while you're waiting to see if LabVIEW is going to render the popup menu correctly. I was toying with the idea of storing state in the class (user tags) or assessing the state but I'd like to maintain portability (no deps or conditional/extra class state) and everything in native LabVIEW. The tools menu does seem to be context sensitive based on project selection but that feels like a weak link to me. I think if I did a tools menu entry I'd want a UI to confirm class selection, and then I might was well make different actions available from that UI, and then suddenly GOOP or AF. I'm avoiding DVR wrapped classes (versus my DVR wrapped in a class) because unless I'm missing something... dynamic dispatch doesn't work with that mechanism. I'd much rather either continue doing this manually or create some tooling to significantly cut down on the bootstrapping effort.
  11. I'm curious on the effort done to cast DVRs back and forth between an int.Googling doesn't seem to bring anything up so I'm curious how this became a thing and what benefits it provides? Does it stop LabVIEW from doing some tricky thing with DVRS? Does it make the scripting simpler?
  12. That DAQmx template is slick. Definitely not a state machine and definitely already handles some of the features I was thinking of like templating asynchronous background tasks.
  13. I rarely use state machines in my applications so I've never been inclined to look into that. After seeing that readme I'm definitely going to take a look at it and see what all it does though. [Mass compiling now in VIPM] I suffer from being very picky in my ability to be flexible and tend to avoid [heavier] frameworks when I can. The main idea of this is that it isn't a framework; it is IDE tooling to more easily develop ByRef designs
  14. INB4 Demo Video: YubTub Linky Monday of this week I finally saw NI's Center of Excellence and after not being at NIWeek for a few years I was blown away at how far the technical sessions have come. I saw the LV Hooks presentation and of course had to try getting back into the rusty nails that I started trying to play with a year ago. I previously tried creating XNodes that could replace getters and setters for data hidden behind DVRs however I hit a road black when trying to access DVRs that were private to a class. I have finally gotten around to implementing my next approach, and it works! This is the first of a set of features to help me speed up development when I'm creating ByRef classes. My ByRef architecture involves creating a DVR and usually having that be the only data member of the class private data cluster. This allows me to branch the class wire while still accessing the same DVR contents in multiple locations. This allows me to avoid having to use additional frameworks and patterns like QMH or AF to easily support parallel tasks. This design lets you choose between synchronous and asynchronous actions and most importantly: inheritance and dynamic dispatch are still fully supported! Want to use a queue? Do it! Want to use a bool to shutdown a background loop? Sure thing! Want to use events! Go right ahead! Want to mix ByRef and ByValue classes? Okay! I know there are already project provides that try to automate some ByRef implementation details however I don't like the idea of functionality being hidden in some "core" and wanting to do something slightly differently this time. The basic idea of everything that will come of this provider is that it automates creating the VIs you would use directly, and only those VIs. Everything is visible and available and you can use the provider to scaffold the common starting points and then move on from there. I'm curious what y'all think! Does anyone do similar ByRef designs? Anyone have ideas or suggestions? Once I get the DVR member accessor scripting implemented I'll uploading this to GitHub for public critique consumption.
  15. I was testing a buffer I wrote for an application some months ago and pushed nearly 2 gigs of data into it 200 rows at a time and then read back the row count. LabVIEW's memory never went above 350megs. Definitely tricky to benchmark in LabVIEW sometimes. LabVIEW is great because it does a lot of stuff for you. LabVIEW sucks because it does a lot of stuff for you.
  16. Was the compiler smart enough that it never put the string into the cluster in the first place? /snicker
  17. And here is what the relevant bit of "solved" code looks like. The VI.OwningApp property was the key that I had glanced over and allows opening items from memory by name from the project, which aren't available from the NI.LV.XNode context.
  18. I use a lot of reference applications for things like buffers, etc. where pulling out everything everytime would become prohibitive. (As others have stated about my unbundle being inside the IPE). Perhaps the compiler would see the other items aren't pulled out and not copy everything, but if it copied my two gigs of full rate 50khz data when all I wanted was the current data size: boom. Memory fault. Ultimately this XNode is going to become part of a palette of functionality that aids in development of by-reference designs that go beyond just type matching and maybe even someday others start using these and I never have to inherit code where a class instance stores state data in a FG, especially when that FG isn't part of the class. Preview of other coming attractions: Generics in LabVIEW. (With type restrictions!) All of these features will build on what I learn getting this "simple" introduction to XNodes working.
  19. Thanks to @smithd and @DTaylor for pushing me back to a property I had missed, I can now type inspect classes! Now that I know that what I was trying to accomplish is possible it's time for some code cleanup and implementation of the scripting. Wish me luck.
  20. So I definitely need to do some refactoring of my menu generation code to hide the extra intermediate elements but now I can use it for what I was intending!
  21. Yes, XNode heh. Thanks smithd and DT, I'm going to work on those and give it a shot! I don't need to open the subvi in the context, I can just use open VI, take the Results.lvclass from the variant, add ":Results.ctl" and open it using the OwningVI's OwningApp property! Thanks for the push. I had tried to find something about getting the other app context but glanced right by it and missed it.
  22. So we'll effectively call this the first time I've heard of VI Macros. Is there some list somewhere of all the neat tricks NI is hiding from us?
  23. It seems to me that you'd be more interested in a VI scripting topic to accomplish some automatic code generation but in general OOP itself wouldn't fit this. At the highest level there is knowledge of what the output type should be and therefore should be able to make assumptions about the code it should run to get that data. There are ways I can picture accomplishing this within OOP code but it would break nearly every prescribed design paradigm, be extremely complicated (lots of VIs), and difficult to debug. Or use variants everywhere and some type of data reflection which will be a lot of extra code and completely break type safety. I'm currently exploring some XNode implementations to simplify some boiler plate code for by-reference architectures but have hit a few road blocks on doing type reflection on the class from within the XNode; turns out different execution contexts makes it difficult to get references to classes from the project on top of XNodes already being difficult.
  24. I may have gone a bit overboard with an example but this demonstrates several things: Call Asynchronous cannot use a polymorphic member reference. To get around this the TaskMgr class has a static member that takes in a Task Instance and can then call the polymorphic task while it runs asynchronously. The Start Task.vi demonstrates setting up the static vi reference properly to use the call async node. The base Task class (and TaskMgr) follow my by-reference design to allow parallel operations. The key note here is that the reference is contained within the class data, as opposed to a reference of the class itself, which allows polymorphism to work correctly. Two example tasks are provided: BgTask is implemented as a by-reference design and demonstrates reading its "progress" in a parallel loop. Note that it only dereferences the class data when it needs to update a value, instead of keeping the reference locked for the entire execution of the task. SlowTask is by-value, though the Task base class it inherits from is still by-reference for control signalling and status tracking. TaskMgr.zip TaskMgr.zip
  25. I'm receiving a class instance in a variant that I'm trying to enumerate types contained for. The attached screenie works great when run normally but it's being executed in a different context and the get class default from name is returning an error. 1. Is there a way to access other contexts via VI Server? 2. Is there a simpler way to get the private data control cluster default value?
×
×
  • Create New...

Important Information

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