Michael Aivaliotis
-
Posts
6,196 -
Joined
-
Last visited
-
Days Won
103
Content Type
Profiles
Forums
Downloads
Gallery
Posts posted by Michael Aivaliotis
-
-
-
-
Well, all you would need is a current shunt.
These little babies can handle up to 50 amps but you could get others that handle higher current.
A quick google gave this:
http://www.solar-electric.com/mka-100-100.html
As you can see, all you need to do is measure voltage across the terminals (good old ohms law). The voltage range is up to 100mA and you need to set your gain accordingly.
-
Yes, cool.
The FAQ's been updated:
http://forums.lavausergroup.org/index.php?...findpost&p=2129
Norm, you've just won the golden donkey award! Congrats. :thumbup:
-
I have a very specific need for an Express VI, basically to use my own dialog message box code instead of NI's so I can move the mouse onto the buttons, set the title, change the appearance, etc. I can currently use my own code but that doesn't allow me to move the constants off the block diagram that are required to set the title, message and button captions (which I find very very helpful when coding to reduce clutter).
I'm not sure I understand (and would like to help). Why can't you create your own sub-vi and make it a pop-up vi? Why the need to go express?
-
-
-
Yes, you can do it that way too. The main motivator for my approach is when you have to do this on many many controls. It becomes very tedious.
I'm not familiar with scripting, but is it possible to invoke clipboard functions Copy and Paste and then change the control to which the property node is linked?Hmm, interesting idea. I don't think you can invoke the clipboard with scripting but you can use some windows API. After the past you might be able to use a scripting function for re-link. I'll get right on that...
-
I've started experimenting with creating a LabVIEW development environment tool that would run and assist in various programming tasks. The initial task is to determine what is selected. This is important because you can find out what is selected then perform certain actions on these selected objects.
One small area that I touched upon was the need to duplicate the same property nodes from one control to another. First of all you would select the property node. Determine what properties are there then buffer that in memory. Finally you would re-create a new property node for a newly selected control and apply the previous buffered property items.
This works like a charm with controls of the same class. If you do it across classes then the creator node errors out. You can ignore the error but you end up with duplicate properties that were not there in the original. There seems like no way to only create properties of valid items for the new node. You have to feed it an array of property items. If one of them is invalid then you're out of luck.
This is just one example of what you can do with a tool that runs while you code. I'm thinking of adding more functionality. Several other VI utilities posted in the forums could be added as well. This could be a nice way to package all the scripting tools.
Anyone wanna help?
-
-
If you can give me a use case (a possible scenario) then I can show an alternate solution. You have to consider what the purpose of this would be. Would you be talking to different hardware with each executable or common hardware? I think this would be a key factor.
The easiest way to work with multiple exe's would be just to rename them... no? Have the original exe create a copy of itself and then just launch it. Sounds possible.
-
-
-
Yes. I took this picture during a sailing trip on lake Ontario.
Geeze, what a scary image!
Since you like those kind of movies, have you seen the movie "Resident Evil: Apocalypse"? It was actually filmed entirely in Toronto. One of the main action scenes shows a round shaped building blowing up. That is actually Toronto City Hall.
-
Yes, this is normal.
There is a rule in LabVIEW execution flow. ALL loops must execute at least once before they stop. This is because LabVIEW MUST iterate in order to read the value of the boolean and then it will decide that it should stop the loop from running a second time. If you don't want to run the loops at all, you must use a case structure around the FOR loop set to false.
-
Ok, I'm starting another useless thread.
Here are some screen captures of my desktop with the ultimate. Four versions of LabVIEW running at the same time. I challenge someone to beat that.
I'm also showing my desktop... naked.
Show us your desktop...
-
-
-
-
Congratulations! :thumbup: You've discovered a bug. I'm moving this topic to the "7.1 bugs" section. I was able to reproduce this from scratch with a blank tab control. I believe the bug appears when you have "allow multiple rows" OFF and locate the tabs to the bottom.
-
Second... I have been reading info on LV2 globals and do not understand how there are less copies of memory made for an LV2 global in comparison to using a global or a global reference that is used to pull the value out through a property node. When an LV2 global (subVI) is called... isn't a copy of the global created at the output terminal of the subVI? Is this any different than a copy being created when you read a global variable, or a global-variable-referenced property node to some other control? Obviously there are other benefits, such as avoiding race conditions, but I'm still trying to figure out what the big advantage is from a memory management perspective.
I recommend you read this post (if you haven't already):
http://forums.lavausergroup.org/index.php?...=findpost&p=675
So the issue really is that with globals is this. LabVIEW really has no way of protecting access to the global data. To work around this, LabVIEW allocates a seperate parallel memory buffer for each and every instance of the global. In other words, it does NOT reuse memory buffers allocated to globals like it does with other nodes. So if you plop 5MB of graph data into a global that is located in 10 different diagram locations, you will have allocated 50MB of memory space.
Well, in general the fastest data access time is always a plain ol' wire. The value property ranks as the slowest (over 10x slower) method of data manipulation. Even slower than using a local. In my first post I said never use globals. My second comment would be: almost never use the value property. I choose locals over value every time. Finally, you may ask, well then what the hell do you use? LV2-style globals rank #1 for me with GOOP as a close second. GOOP is the ultimate in accessing data by reference.If I had a large array on the main.vi and accessed the Value property through a global reference, it would create a copy of that array, correct? And if I simply had the array itself as a global and I read the value directly, LabVIEW would make a copy of it right? And if I had the array stored in an unitialized shift register that gets passed to the output array terminal of a subVI, there is then a copy that is generated for that too right? So is there any difference besides the overhead of loading a global in comparison to loading a subVI?Finally, a note about my use of globals is that their use is typically limited by the execution flow control of my program. Since program execution is linear, there cannot be a problem with race conditions.I would re-think that. Program execution is never linear in LabVIEW unless you're forcing execution with sequence structures or wires.
With a huge array held in a LV2 global, there is no advantage of ouputting the whole array to modify it because a copy is being made. Avoid to put the array on any indicator. Look at the attached picture. No copy of the whole array is made, only the elements needed to be modified are replaced.The idea is to include in the LV2 Global a lot of functions to manipulate the array in place
without having to access/copy the whole array on calling diagrams.
Yes jpdrolet I agree. A modification that I would recommend to your image is a s follows based on your last statement:
This entire code with the while loop would make up the the LV2 global VI.
-
Actually, the problem occurs with using the Variant form of the data (non-strict). If you are using the strict control refernece then this problem does not occur. This is because the refnum contains the type information on the wire and does not rely on the variant to data function. So in other words, your original implementation would not have this problem.
-
-
Hmmm....
I think I know what you are trying to do. Are you trying to move the menu from the top of the VI to the middle of the window? There is no way that I know of at the moment to do this. However, If you like to play with some methods. Here is an older post with some info:
... We have to get you to switch to Firefox. :thumbup:
. I use that in my programs as well. It slipped my mind.
New user question about voltage monitoring
in Hardware
Posted
Take the 2 wires from your analog input and put it across the shunt.
.