Michael Aivaliotis
-
Posts
6,196 -
Joined
-
Last visited
-
Days Won
104
Content Type
Profiles
Forums
Downloads
Gallery
Posts posted by Michael Aivaliotis
-
-
Well, the approach really depends on what you are trying to do with the data. For example, is the data usually written to all at once all the time? If so then you might want to always write the data in one shot as one cluster. The only time I would write individual values would be if the writing will happen in multiple places in my code.
-
-
Ok, here it is is. I built a LV6.1 example that shows how to have a server that sends data to whomever requests it. This one shows 2 clients and is done with parallel loops for simplicity. Of course these can be put into Sub-VI's. The datatype used is string but you can use anything really. I know some people use variants.
Enjoy.
Download File:post-2-1112239412.vi
-
Yes. All you need to do is separate the VI's into separate parallel loops. This will allow the "slow" VI's to run at any speed they wish and the other VI's won't be affected. It should be straight forward but if you need any help let me know and I can post the modified code.
-
Hi John:
Thanks for the info--
I'm running 7.1.1 now, but come to think of it, seems like this has been going on for a long time... perhaps off & on since I switched From Macs
to Windows :ninja: Perhaps I should check with NI support.
Anyone else having the problem currently :question:
Thanks, Lou
Nope, no problem here. never seen this. Do you have sticky keys enabled in windows? This is in the disability aids section.
-
I'm not familiar with DAQmx and need some guidance to organize tasks settings with a PCI-6024E board.
Analog inputs: 4 channels acquired once per second. Timing is not critical, I can use software timing. I don't need waveform
Analog outputs: 2 channels. I need to update their values independently once in a while. No need for waveform generation.
Digital input: I need to detect a home position so 10Hz read update rate is sufficient. I still can use software timing.
Digital output: I need to activate a relay once in a while
Counter inputs: I need to count edges on two counters inputs.
While there are working examples for each task separately, I have to run all the above from different parts of the program. Do I need to define five tasks or can I regroup them in some way? Do digital input and output need to be on different port or can be on the same (e.g. are lines settable independently for I/O on the same port) ? Can the tasks conflict with each other, especially for timing requirement?<
Thanks
I can't answer all your questions since I've only been using DAQmx for a short while. This is what I've learned so far:
You should configure all your individual channels as global channels first. Each global channel should be configured for each input sensor. Also, you should configure each digital IO line as a global channel. The global channel configuration defines the scaling and other parameters. Once this is done you then go and configure the required Tasks. Tasks define how you collect the data. You can create a single task that contains many global channels. In the task configuration you will define the aquisition speed and triggering etc. In you LabVIEW program you will use DAQmx task ID's not global channel id's.
Hope this helps.
-
Ah Louis,
what I thought may happen, has happened.
Because i've got so many SubVIs and nested SubVIs (I need them really as i'm using Labview 2 style globals to manage counters and common repeating tasks - i'm assuming that's a good approach?) the performance suffers - now i've moved that into the main loop and removed the other, the output is occuring, but there's a lag and it's sometimes missing its deadlines.
That was why I chose 2 loops - I might try and change the output to a queue maybe, to queue up all output, so nothing is missed - it's all a bit tricky!
The code you submitted does not have many nested sub-vi's. I've developed applications with thousands of VI's and they run very quickly, efficiently and everything is synchronized. Your code is very lightweight so the lag you are seeing must be comming from somewhere else. The solution to your problem is to simply to create subvi to handle the port writing and place that wherever you need it. I built a quick VI to do this for you and I modified your original code to include this VI. Basically just place the VI down wherever you need to modify one item. The VI remembers the previous states of all the items so you don't need to worry about synchronization.
One thing I noticed is the multitude of File IO. Is this really necessary? File IO is a big bottleneck.
-
-
You can talk to a MYSQL database with LabVIEW using the Database connectivity toolkit or other tools floating around. What do you need the PHP for? You don't need this to access database data. Please explain the need for LabVIEW to talk to PHP.
-
If you just want to distribute data to many readers then another option is using USR globals. This might be easier to work with. Here is an FAQ entry on them:
-
Why are you using non-latching buttons? Please clarify. What mechanical action are you using?
-
This statement doesn't make sense. An event structure cannot react to a change in a local variable. Event structures only react to front panel events.
It should be ok to use a local variable to pass data, however there is no synchronization. You have no guarantee that the loop has read the old data in the local before new data has become available.
-
I would say this is a real bug. There seems to be some kind of disconnect between the button value and the updating of the front panel. If you do the following, it seems to work fine.
-
The LabVIEW scripting Forum is a place to discuss and investigate ways of using LabVIEW to programmatically generate LabVIEW code. In other words you can write a VI that will (when executed) create another VI. You may have seen some of this functionality in use already. NI uses this capability internally in some of their code generation tools. For example, if you right-click on a DaQmx task node you can select an option that builds a code example or a configuration VI. This wizard uses special undocumented features of LabVIEW to do this.
VI scripting is a powerful new LabVIEW feature based on existing VI Server technology. Using the scripting API, you can create new VIs, create new front panel and block diagram objects, modify existing front panel and block diagram objects, or inspect existing front panel and block diagram objects. VI scripting allows you to write a VI to programmatically accomplish almost anything you could accomplish in LabVIEW's interactive editor.
VI scripting is not advertised or available in the LabVIEW help files that are distributed with LabVIEW. This could be for many reasons. Some of these are:
- NI has not finalized the implementation.
- The implementation is hard to use and NI wants to make it user friendly.
- NI has not decided to make it a publicly available product.
- The existing implementation contains many bugs.
- NI does not want to burden the support system with issues related to an unreleased product.
Because of the previous statements, you are on your own:
DO NOT contact NI for support on VI Scripting.
DO NOT use these features for released code or applications to your customers.
DO NOT count on the implementation to stay the same for future releases of LV. It will change and your code will not be upgradable.
And Finally-->
Your computer will explode, you will lose all your valuable data and local law enforcement will come knocking on your door.
So BE WARNED! Do not blame NI or anyone here at the LAVA Forums for any problems that may arise from using these features.
The Details:
VI Scripting is exposed to you via methods and properties. To enable these methods and properties, you must add the following line to your labview.ini file. This file is located at:
C:\Program Files\National Instruments\LabVIEW 7.1\labview.ini
Add the following line:
SuperPrivateScriptingFeatureVisible=True
After you restart LabVIEW, place a property node down and click on the various properties. You will notice more items in your list.
One more thing. To expose the "create object" primitives shown below, you must install VIPM and install the package called: ogmnu_appcontrol_plus
*Update*
Others have also had success with the following ini entries (don't know what they do):
SuperSecretPrivateSpecialStuff=True
*Update*
Adam Rofer has made some interesting discoveries on some scripting related information. He calls them XNodes.
Good work Adam. :thumbup:
Here is the website: http://xnodes.lavag.org
-
Yes, you can do this. See attached image:
-
Also, don't forget that the entire LabVIEW run-time engine is downloaded and installed if it doesn't already exist. At least, this is my impression. The benefit of using remote panels is the browser interface.
-
See link:
Dr. Yun had observed that robotics combined so many areas of technology and that students naturally responded to robotics with great energy. His team created the AS series of robots and convinced the Chinese government to try it as an educational"demonstration" program in 2000. The tests proved successful, and robotics has been integrated into China's national high school curriculum. In some provinces, every high school student now studies robotics for at least one semester.
The AS-M system meets the needs of a wide range of roboticists. Beginners learn the robotic basics of electronics, mechanics and software programming. The AS-M's "VJC" graphical programming language teaches logic and proper design right from the start. For intermediate students the AS-M's unique interchangeable sensor system lets users create sophisticated solutions with minimal delay. More experienced programmers can actually "lift the hood" on the graphical programming language, and work directly with the "C" code inside, giving them complete control. The VJC software runs with any version of Windows from 98 onward, and we've even had good results using it on a Macintosh running Virtual PC software and a USB to serial converter.
-
This is a good solution. Another option is to take the output of the ring and use that to index an array of numbers that you want.
-
See image. This function will do it. What operating system are you running? Why do you ask about Linux and Windows?
-
The VI with the time critical code contains several sub-VIs that are called sequentially. Do I need to set the priority of these VIs to "Time-Critical" as well? Or is this "inherited" from the calling VI? In other words, do sub-VIs in a time critical VI run at that priority regardless of the priority that was selected in the sub-VIs properties menu?
By default, if you don't touch the priority settings on the sub-vi's they inherit the settings from the caller. Time-critical priority really only has significant effect in a LV real-time OS. Is this the case?
-
That's golden. I would have liked to be there to capture the look of that customers face.
-
Did you also think that the movie "Broken Arrow" was a story about a frustrated LabVIEW programmer battling the forces of evil to get his little Vi to work?... I did.
-
Excellent question!
It has a surprisingly easy answer. Just open a reference to the main polymorphic VI and using a property node, get the list of Callees. See image.
-
Yes, I know I should have said: to avoid the need to install/download OpenG(1), and if you don't need/want OS independent code, and you're not interested in mixed EOL characters, and, and, and, ... but I thought I had covered that with "smooch"
1. although you should've done this as the first step after purchasing LV, IMHO.
P.S. Michael, I will always welcome corrections! That's how you learn! In this case however, the code was just using the tool with the EOL as delimter as a quick solution.
Ok guys. I have an issue with this implementation with respect to showing new users how to do things. I now understand what you are trying to show Alex but the "proper" conversion of a CSV file to an array would go something like this:
Let's not forget that the original question was asking about a CSV (comma separated values) string.
Port Output Problems
in Hardware
Posted
Well, one quick thing I can come up with is the following (see image). This will speed up your longest loop. to detect the button press faster. You can do this to the other loops as well but you should use the tic count timer instead of the seconds since function. This will give you finer resolution. There is probably a slicker approach but this is the best I can do quickly.