Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Taylorh140 last won the day on April 23 2020

Taylorh140 had the most liked content!

Community Reputation


About Taylorh140

  • Rank
    Very Active

Profile Information

  • Gender
  • Location
    Manhattan, KS

LabVIEW Information

  • Version
    LabVIEW 2016
  • Since

Recent Profile Visitors

1,635 profile views
  1. So this apparently is the same with MATLAB: https://www.mathworks.com/help/matlab/ref/plus.html In the section: Add Row and Column Vectors a = 1:2; b = (1:3)'; a + b This simple code will not compile in Mathscript its the same story with Add Vector to Matrix It's just a seemingly basic incompatibility and it seems it has something to do with how vectors are handled in basic operations. unless there is some super secret setting to make these compatible ill just have to find a workaround.
  2. No this is definitely cool. It’s cool to know that there is a way to keep the data in the same scope. Now all you need is a (c compiler/assembler) written in labview along with prebuild actions and the world would be your oyster.
  3. I was working on octave with a simple script: im=[3.5 ;3.5 ;3.5] ip=[1/3 ;2/3 ;3/3]*2*pi w=2*pi*15 % 15Hz signal dt=0.0005; t=0:dt:0.05; th=w.*t; i=im.*(sin(th+ip)); % generate abc to generate 3 sinusoids offset by 120 degrees. However Mathscript seems to choke on (th+ip) I'm not actually sure what operation is happening or rather octave has some type of extension to the addition operation. I like the convenience of the above method. but I can't figure out how to do the same thing in mathscript without a for loop.
  4. So the way the map works is we can iterate all elements in the map by indexing on the input of a for or a while. However, This only works for a non-changing Map. if you are adding elements during the loop is there a good way of iterating all non-iterated items? Id like to have a version without a duplicate structure: I have these: This might be the best that can be done. but I thought id ask.
  5. @jacobson I agree that is a way to use it. but it seems like a waste of potential leaving it at just the wall of text. especially since the c++ guys can get fancy profiling tools like this one: https://github.com/wolfpld/tracy (so pretty) And i think I'm not the only one that would write their own tool to present the data if it we could get of all the necessary information. It is just a little disappointing. I became a squeaky wheel: https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Desktop-Execution-Trace-Toolkit-should-be-able-to-present-data/idi-p/4046489 Y'all are welcome
  6. Ahh, This is too bad. I wasn't aware of Real-Time Execution Trace Toolkit. I Guess the title should be more explicit Is there any way to make similar reports using the DETT? (Theoretically?) My eyes always glaze over looking at the wall of text generated from DETT. VI Calls and returns are matched by the tool (Higlighting) but i cant find a way to get this information exported.
  7. I was looking at a user guide for the Desktop Execution Trace Toolkit. And I found this: A pretty graph! ref: http://www.ni.com/pdf/manuals/323738a.pdf I would love to see this kind of detail on my applications but i cant figure out if it was a dropped feature or what the deal is. It sounds like it should just work by default. Maybe its just for real-time targets (lame)? I cant even export enough information from the DETT to redraw a graph like this. But many tools have this kind of execution time view, if it is part of the tool how to i access it and if not how cou
  8. Is this the trick where you have controls off-screen waiting to be moved into place? graphs are limited by the number of plots ready? I've also seen the setup where windows are embedded into the UI and reentrant VIs are use to plot. (setup is pretty non-trival though). I haven't really seen a solution that is nice and modular and easy to drop into particular ui being worked on. Is there another?
  9. For a final Case. Sadly there isn't any non-depreciated Items to replace that vi. Which makes this work for Clusterzilla. ArrayToCluster.vim
  10. So, sometimes when i'm troubleshooting or perhaps the customer doesn't know what they want, its nice to make things a bit more flexible. However I find this difficult with plots, they take a good deal of setup and are pretty hard add remove things flexibly during runtime. I'm curious of any other examples or demonstrations/recommendations for doing similar things. I Made an example here of something that i'm working on for flexible runtime plotting: Plotter.vi Front Panel on PaintGraph.lvproj_My Computer _ 2020-04-22 11-04-10.mp4 Here i have some functions to be desired. I am u
  11. I think i knew about that one. Its quite effective, I just have a natural avoidance of using them in anything production related due to the (not supported stigma). The also use quite a few files, I wish LabVIEW could used fewer files. But mostly I wanted to take a renewed crack at this problem. I used @drjdpowell's solution so I wasn't doing anything unsupported (it should be available to anyone using 2019). (because of the type specialization) Custer To Array: (pass the type directly if possible) otherwise make them a array of variants. Array To Cluster: Get the cluster type a
  12. Here is another shot Late to the game i guess Its a 2019 vim that supports cluster size from 1 to 256. Contains forward and reverse operations. ArrayToCluster.vim ClusterToArray.vim
  13. So there are so many ways to do evaluators. I was trying to minimize mess on the implementation (no recursion or any such nonsense) Single File capible(if function VI is removed) Contains tools for changing rules.(In the form of a spreadsheet) It uses variant attributes for the variable name space. Here it is: Made a nice and simple evaluator should be compatible with older versions of LabVIEW as well. And even gave it some test cases: Also check out the github page: https://github.com/taylorh140/LabVIEW_Eval I've attached the Eval and Functions.
  14. Nice simple find! Thanks for the tip.
  • Create New...

Important Information

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