Jump to content

Taylorh140

Members
  • Posts

    82
  • Joined

  • Last visited

  • Days Won

    7

Taylorh140 last won the day on August 9

Taylorh140 had the most liked content!

Profile Information

  • Gender
    Male
  • Location
    Manhattan, KS

LabVIEW Information

  • Version
    LabVIEW 2016
  • Since
    2010

Recent Profile Visitors

1,885 profile views

Taylorh140's Achievements

Newbie

Newbie (1/14)

  • Conversation Starter Rare
  • First Post Rare
  • Collaborator Rare
  • Week One Done Rare
  • One Month Later Rare

Recent Badges

25

Reputation

  1. @FantasticNerd I don't make the rules, as far as this particular situation I can only speculate why. I would guess NDA would be required as well as other complicated approvals. In this case we are requesting a installer/setup procedure. but these things take time, in the meanwhile we are limited in testing. It's great the MAX/NIPM have a list of installed stuff. This is typically where i start too. Now wouldn't it be nice if NI just had a utility that looked at the exe, and made an installer that had all the components :).
  2. It just so happens that sometimes I am suppose to reproduce a test system made by a customer. There may have been an installer at one point but no-one knows anymore and they don't want to share the source vis. In the past i have download each NI library installed on that particular PC and installed it on the other until i get it all to play nicely. However it takes some time and is quite tedious. Is this the only way?
  3. @Rolf Kalbermatter I appreciate you mentioning this. I myself was weighing this. VI -> Smaller better for sharing examples but can have evil code in them. Slightly harder to make. Image -> Safer to share but lager and much more limited. Easy to make. I was originally leaning toward an image but, I think your right VIs are better. I don't think I've come across malicious VIs here, at least that i know of .
  4. Be careful of Pragma pack when your trying to line things up for larger types.
  5. I added what I have to https://github.com/taylorh140/Pgui. It's only right since I copied the enabling technology right from this forum. I don't know if ill have a huge amount of time to work on this but ill defiantly try and improve it when I can. There is still a lot of things that would be nice to develop for this.
  6. This is true. bad habit I guess. I used openGDS for this w/ EndevoGoop400, so far I like it. But it is still new to me so there are possibly design The enabling technology for this was from @Norm Kirchner so respect where it is due. Being able to translate images allows one to build a UI component and move it into place. Each drawn component can now pretend it is the only UI component on the picture control. I'll try to get a GitHub page published soonish.
  7. Two questions about this: 1. Does something like this already exist? 2. Is this something that could be useful? Every once in a while I need dynamic UI components that can be generated at runtime. One nice thing to use for this is a picture control; however it doesn't lend itself as well to keeping other pieces of function such as mouse click events and such. I put together a mini library of UI functions for this that has the ability to be extended. The UI can be generated dynamically at runtime and be any picture thing that you can draw. Using Standard layout techniques that you might find in other GUI libraries. The hierarchy generation can always be simplified by using some type of templating string. Example1.vi Front Panel on Pgui2.lvproj_My Computer _ 2021-07-02 14-03-54.mp4
  8. This may bet a better lead; It has a lot of similarity. https://docs.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-waitforsingleobject I have never seen this used. but it does seem to work. With similar performance.
  9. Something we can both be glad about. I think I might have a lead. https://stackoverflow.com/a/35389291 But ,I'm still not sure what's going on there, they clearly did a good job.
  10. In the example above I'm more interested in how NI implemented the waiting on the queue. It seems to have better performance than I would imagine possible. I probably made some bad assumptions on the example. Assumption 1: Two while loops run on different threads. Assumption 2: If threads yield to OS response of queue would be > 1ms on average. Assumption 3: If threads actively wait CPU usage would be high. Assumption 4: Neither of these methods make sense with the information collected.
  11. So lately I have been more interested in scheduling. Two methods I am aware of are below. This is in the context of Windows OS btw. Active Waiting (polling) Know for High CPU usage Accurate to less than 1ms Yielding OS wait (Thread telling OS give someone else my time slice) Very low CPU usage Takes OS integration (e.g. less portable) Much less time accurate jitter etc. expect best performance to be 1ms resolution So I have been curious about the timeout function of the deque element for a while. To me waiting on this seems to take little to no CPU usage. but has much better than 1ms resolution. 30us +- 10us in the example below. How can I replicate this kind of performance? Is there a secret method I am not aware of (reality says yes)?
  12. I tried to do a test to see if any of the windows fonts do anything. (forgive the long image). I'm starting to wonder if windows has this function in any form. perhaps there are some fonts that do work but the ones included with windows do not seem to do much:
  13. In The Draw Text at a Point VI under the user-specified font there are two settings that I do not understand. -Outline - seems like it should put a black outline or something around the text. as far as i can tell it doesn't do anything. -Shadow - seems like it should put a darker outline around part of the text. as far as i can tell it doesn't do anything. How do these work or lack there of?
  14. Wow, Thanks! It's good to be wrong. It does sound though I was right to be weary of calling DLL's meant to call LabVIEW functions, especially when LabVIEW versions change. But it sound like LabVIEW calls its own exposed functions (lvrt.dll i assume) when dealing with Queues. I wonder if building a dll for calling the queues and then debugging these would give me the prototype. (following the data to the builtin's) #unrecommended but a quick way to do devious things. (most likely learning that it is a bad idea and leaving it alone ha ha).
×
×
  • Create New...

Important Information

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