Michael Aivaliotis
-
Posts
6,196 -
Joined
-
Last visited
-
Days Won
103
Content Type
Profiles
Forums
Downloads
Gallery
Posts posted by Michael Aivaliotis
-
-
Hey, you can always add a password.
File>>VI Properties then select ->Security
-
The idea arose on Info-LabVIEW and was initiated by ggatling.
Adding the 'Use default if unwired' option to the case structure output tunnels was (IMO) a great idea. But I would still like to take them one step further, though this might be a new kind of tunnel for case structures...So often I have a case structure inside of a while loop and several shift registers on the while loop. Each case usually operates on only a subset of the shift registers, so I spend a great deal of time (and diagram space) making wires from one side of the case structure to the other. When I come back later, there is no readability advantage to having made all these wires that only serve to say this case does not operate on this data. So....
How about a pair of tunnels for a case structure such that when the output is unwired it simply passes through the data that was on the input tunnel... much like a for loop shift register behaves when N=0, or like the dynamic event terminals on an event structure.
If you want to speed up wiring of your tunnels, here is a utility that will do that for multiple cases in one shot. It doesn't eliminate the wiring but it makes it a whole lot easier:
http://forums.lavausergroup.org/index.php?showtopic=211
Here is the discussion and responses to this initial post:
Great idea. What I currently do to have a default case that has all the tunnels wired through, and then I just duplicate that case and delete the wire that is going to be modified in the case. But when you decide to add a shift register, you have go back and make space and wire up the new tunnels. And the through-wires take up real estate. So I am all in favor of this new construct. How about the "virtual pass-through"?--
David Ferster
How about a pair of tunnels for a case structure such that when the output is unwired it simply passes through the data that was on the input tunnel...I second the motion. Could the current tunnels just be modified
slightly to implement this idea? For instance when you wanted the data
to pass thru for a particular case you could right click on the tunnel
and select the "just passing thru" option that would display a small
arrow on each of the tunnels for that case. As you flip through the
cases, the tunnel image would have to update to no arrow if it was
wired. Of course the arrow on the case tunnel would have to be
distinctly different than the Sequence Local Arrows.
--
Brian Bean
I would prefer a even more flexible solution: Make a special, usuallyhidden case with a name such as "_default outputs_". For example, you
would right-click on the case and select "define default outputs". Now
you see a case that has a different color. Here you can wire away and
define what the output terminals should receive in all the "regular"
cases *if* they are not wired. Only outputs you don't wire here would
receive the default for the data type as we have now. By default, this
case is empty, duplicating the current behavior for unwired outputs.
In your very special case, you would connect the desired input and
output tunnels across, but now the possibilities are truly endless.
Now you also have the opportunity to do math, e.g. insert a [+1],
[-1], etc as often needed. One output tunnel could receive a special
wired constant (1, -100, Inf, NaN, etc.) that would be more suitable
for the particular situation than the default for the data type we
have now. One output tunnel could receive a mathematical result of
multiple input tunnels.
Just some ideas ... (We can dream)
Christian Altenbach
This is a great idea! This would make state machines/QMHs soo mucheasier...
I do think the special case should not be among the usual cases, because
it's not something that is selected by the "?" input. But there's plenty
of room on top of the case structure to add a special thing to access
this "define default outputs" diagram. Besides you don't want/need this
feature on small cases.
Joris Robijn
Yeah I thought of this too. It would be very useful. They could have the same behavior as the loop shift registers (rememberinglast value when uninitialized, add elements to the left to remember latest N values). It could replace the while loop/case structure
combo in state machine and LV2 functional globals. Now just add a "next case" output terminal (to set the case that will be executed
next time) and you have a state machine in a single structure.
They could also be used in sequences to pass data from one frame to the next, keeping the left to right data flow (unlike sequence
locals).
Since no one's mentioned this yet (although I'm sure I've seen it in these pages before), if you plan properly, you can consolidate all your shift registers into one cluster and then just replace using "bundle by name" the item that needs changing in any given case.However, I must concur that for individual shift registers (like the state the program should go to next), it would be great if I could specify that the "default" value was, say, "Poll" instead of "Init" (where "Init" is the first state and thus currently the default state).
Just my $0.02 worth...
I'm not much in favor of NI adding some new visual variation on tunnelson cases. You'd have to add them as matched pairs of objects, much like
shift registers. They would require some vertical spacing along the
sides of the case structure, like shift registers. Even if the case
diagram area between them were freed up, they would still 'stack up'
along borders. Though they wouldn't wreck dataflow, they might make the
visual flow of data less obvious. This is the same problem I have with
default-value output tunnels, though I understand why (with the advent
of the event structure) thisfeature became necessary.
I am intrigued by Christian Altenbach's suggestion of a 'default-values'
case - at first look, this doesn't seem like it would obscure dataflow,
in fact it could enhance it. Until NI adds some new block diagram
feature for this, I'm content to string a set of wires across multiple
cases. And that's why I wrote the tunnel wiring utility - I always need
to add a wire *after* the cases have been established.
-
-
Why?... Yes, it is possible. Do you want the button to stay down or pop back up? If you want the boolean to pop back up then use a local variable on the boolean and set it to false.
-
LV6.1 has event structures.Don't know how the event structure improves the following because I don't have access to >6.1 at the moment ...
I don't see why not? Have you tried it? What problems are you seeing?Now is it possible to extend this to give me real time <cough> syntax highlighting?
I didn't see any flashing on my end in the examples posted previously.I reckon this could be done with the text select and highlight method outlined before, but it might be pretty ugly (flash, flash, etc).I saved the LV7.0 version into 6.1 however I noticed that the behavior changed. The 6.1 version behaves very buggy. It does not remove the hi-lighting...
Open the attached VI using LV6.1 to see bug.
-
Ah well of course, you want me to write your whole program for you... see attachment (LV70)
-
What I described to you in my post is exactly how this is done by the suppliers of toolkits for LabVIEW. There really is not much more to it. When the VI's are distributed, mnu files are included. I'm not sure what you mean by "the .mnu files change". The .mnu files included with the toolkits always reflect the VI's they are included with.
Ah well this is called a "Merge VI". Here are some links for more information:
http://forums.lavausergroup.org/index.php?...findpost&p=1121
http://digital.ni.com/public.nsf/websearch...52?OpenDocument
-
The datalogging capabilities that you talk about are rudimentary but may be useful for something. I just don't know what. :question: I honestly don't know why NI has not dropped this feature since I have never come across anyone who uses it (of course now I will be proven wrong). The type of files created are the same format as your standard datalog files. Datalog files can easily be created by writing a cluster into the file IO functions. How is this different?
Go to a brand new VI and create a bunch of controls (booleans, text input etc.). To enable datalogging you have to go to this VI that you want to log data from and go to the Operate>>Data Logging>>Change log file Binding. I bet you didn't notice that before eh?
You will be prompted for a file. Enter a filename with any extension. Now go back and edit the values then click the run button. Now go to the Operate>>Data Logging>>Log.. menu. The values of all the front panel controls will be saved as a single record to the file. To retrieve the data you have to place this same VI on the diagram then right-click on it and select "enable database access". A weird file cabinet icon will wrap around the vi and now you can create indicators to retrieve the data from the datalog file. So in essence the entire front panel of your VI becomes the cluster you would otherwise use in your normal datalog file IO VI's.
See image:
-
Hey! I heard that!
Actually James, If you look at the sub-vi's that Quixote is using, you will see VISA there. Presently this is the only way to use serial. As far as the coding style your improved re-write is great! Of course it can always be done better...1. Consider using the VISA Serial routines as they have the following benefits:-VISA routines provide a common interface to serial, GPIB, and VXI, so learning one helps if you use one of the other buses.
-VISA routines give you enum inputs so you can select "COM1", "COM2" instead of 0,1.
-
-
Here is a brief tutorial (with pictures) on how to replace the index control in an array. This is useful when you want to provide a user friendly interface to the array control or you want to create custom front panels using the array control as a main component.
Right-Click on the border of the control and select Customize from the menu
Click on the wrench Icon to break apart the control
Click on the index control so it is selected with a dotted line around it. From the menu select customize which will bring up another control editor window for the index cotrol.
Now from the right-click menu you can replace the index control with any other numeric object, in this case a slider.
Now you just close the control editor window, don't save the control, just say yes to replacing the old index control.
The final product.
-
You should not edit the mnu files directly. Go to your LabVIEW menu and select tools>>Advanced>>Edit Palette Views. This will bring up the palette editor.
From this editor you can edit exisitng subpalettes by right-clicking on the nodes or you can create your own mnu file. You can only create custom mnu files in your user.lib subpalette.
Once you insert a submenu you will be given a choice to create a new mnu file.
I hope this gives you some starting point with mnu files. There is extensive help in the built-in LabVIEW help on this topic.
-
Now it's running.....the Problem was about the Path-creating from a simple String!
When you use the \ then on the Windows 2000 System it makes the right Path!
But when you use this Backslash in the WinNT System, than it makes the Path false!
So i use than only a : in my ini-File and it works. Because the LV makes then the Backslash self!
Are you guys using the built-in ini functions that come with LabVIEW? If you use these config VI's you should never run into compatibility issues because this is handled automatically. I hope you're not creating the path yourself using strings are you?...
-
You can't build applications or run the Application builder in the Evaluation Version of LabVIEW... Sorry.
-
It seems that your wish is granted... twice!
See this link 1:
http://forums.lavausergroup.org/index.php?showtopic=158
See this link 2:
LV7.1 Feature: Navigation Window for easily viewing large front panels and block diagrams
-
You should have no problem doing what you want with LabVIEW. NI has developed a LabVIEW Datalogging and Supervisory Control Module but this only works with LabVIEW version 7.1. I don't think you can buy it for version 6.0 anymore. Here is a description from NI's site.
Like I said, you can do all of the above with regular LabVIEW but the add-on module will make your development go much faster.# Graphical development for distributed monitoring and control# Networked database for distributed data logging
# Configuration-based alarms and events
# Real-time and historical trending
# Built-in networking for data sharing and integrating third-party devices
# User-level security for applications
Overview
The LabVIEW Datalogging and Supervisory Control Module is the best way to interactively develop your distributed monitoring and control systems. With the Datalogging and Supervisory Control Module, you can extend your LabVIEW application to view real-time and historical data, configure and manage alarms and events, set up security on your applications, easily network OPC devices and LabVIEW Real-Time targets together into one complete system, and efficiently log data to the distributed historical database. The DSC Module also features intuitive wizards and dialog boxes to help you develop applications faster and better. Whether you need to build a full-scale industrial automation and control system, a high-channel count data logging application, or monitor and log a few dozen I/O points for historical collection, the LabVIEW Datalogging and Supervisory Control Module provides the tools to make you more productive.
-
Hmm, it appears to be a bug that's reproduceable in LV7.0 and LV7.1. Can someone else confirm this? I recreated the same VI in LV6.1 and it behaves as it should. It appears to be some kind of rounding error bug. I found a work-around:
1. Right-click on the control and select representation>SGL
2. Right-click on the control and select representation>DBL.
It will work now as expected. -
I've moved this post out of the bug-list section because I don't think it's really is a bug. If others disagree I will move it back.
I've modified your example VI (LV7.1) and added a fix. I also converted it to LV7.0 for the other folks in this forum. The problem is that when you hide a page in the tab control, that is currently active, LV doesn't know which tab it is suppose to make the active tab. You, as the programmer, must give LV this information by setting the active tab. I've shown this in the code by adding a property node that always forces the first tab to be active.
-
So ... I am guessing that the regular LV Runtime installer does not install VISA the same way that it gets installed when included with a built application?
Perhaps I am missing something but I really don't understand why installing the runtime engine separately shouldn't work. For this to work would I need to do a separate 40+ MB VISA installation? (you would think that at 30MB - the runtime would include VISA serial IO capability) I must have assumed wrong.
The LabVIEW run-time installer only contains information for installing components related to running LabVIEW VI's. Hardware communications (like serial) requires different modules that are not included with the "basic" run-time.
You can try a little experiment. Create a blank build script. By "blank", I mean do not include ANY vi's. Go right to the Installer tab and configure it as shown in the attached image. Build the app. Run the setup.exe file on the computer that cannot communicate with the serial port or has errors. Does this fix it? If so, then you now have a serial port installer!
-
What I want to do is wire another button that would stop the case structure from continuing to execute as soon as the user clicks on the second button. I have tried several different ways to do this with no apprent luck. In a nutt shell I am looking for a user control that would stop a case structure in the middle of execution.
You cannot abort a process this way because you have not programmed any modularity in your code. The only way to do this is to put case structures around the bits of code that you need to abort and then make those cases false when you hit stop. For example, if you have three VI's that have to execute and you are executing VI#1 then you can ignore VI#2 and #3. However you cannot abort VI#1 until it has finished executing. If you need this type of control I recommend using state machine architecture and break down your code into smaller chunks that can be controlled better.
Here is the FAQ entry:
If you want to do simple start and stop button behavior, look at the attached example (LV70)
-
I think the best way to debug this would be to probe the path going into the Open/Create/Replace File.vi. If this looks good then another thing to look at is permissions. Are you logged in as an administrator? Sometimes file writing to certain directories are limited to specific user levels. It is strange however that none of the VI's give you errors.
You should place the General Error Handler.vi at the end of the file IO chain. This will trap any errors for you. -
There is nothing built-in to LabVIEW but check out this post. It can be done by running a custom VI. You can probably put this VI in the project menu to make it more accessible.
-
Over the years i've gotten accustomed to living with certain rude behaviors in LabVIEW. For example, when you move an object around on the diagram with your mouse, you have to go back and cleanup the mess that LabVIEW left behind. It seems I'm constantly walking around with a virtual pooper scooper of sorts.
Here's what I mean. Below you can see a simple VI with a typical assortment of wires attached. This a simple example of the best case scenario - few wires.
If I then click and drag the VI to a different position on the diagram, I get multiple overlapping wires.
Yes, this is normal behavior but I think it can be done better. The next image is the proffered reaction to my move.
As you can see the wires have wrapped themselves to the proper position. Of course this would happen in real time. As you move the VI, you would see the wires wrapping and moving as you drag the mouse. I could best demonstrate with an animation but I am not a computer animator.
Also, in combination with this feature, it would be nice if each object (VI, function etc.) had a no-fly zone. What I mean by this is shown in the next image. 
The red border designates an area where the wires must come straight out of the VI. This means that no other wires can go behind the object or pass near the object's no-fly zone. This would force clean diagrams since it would be impossible to have objects overlapping wires. The next image shows an extreme object movement and how the wires would auto-wrap into position.
Also note that the terminal is also an object so would have a no-fly zone as well.
Yes, I'm dreaming... I can only hope. :thumbup:
-
Well what do you know!? You're right! I just did a quick test and confirmed this. Thanks for the warning. I mistakenly assumed that it would behave like the Variant to Data function.
Live webcast of LAVA meetings
in Site News
Posted
Well, if we were to go live and pay for the service ourselves it would be very expensive. Nothing we could afford. It also doesn't look like anyone is offering to donate this either.
I've been experimenting with a free (free as in open source) web streaming utility that may allow us to do this at no cost. It is a technology called NSV. For more information see here:
Introduction to NSV
The only problem is that it's one way. You will be able to view but not ask any questions via voice call. We can work-around this however by having a live chatroom open that can capture questions from remote users. I am planning an experimental webcast to test this system out in the near future. More information will be available in these forums when I'm ready for the test.