Rolf Kalbermatter
-
Posts
3,917 -
Joined
-
Last visited
-
Days Won
271
Content Type
Profiles
Forums
Downloads
Gallery
Posts posted by Rolf Kalbermatter
-
-
QUOTE(vinayk @ Oct 19 2007, 01:14 PM)
As suggested, I used a parallel while loop to seperate the calling of the sub-VI and it was working great, like said in the above posts, for very small applications. But for my actual application this method of calling sub-VIs is not working great. So I was trying to implement the 'Call by reference' method as suggested. But my 'Open VI reference' is giving an error 1004 which I could not figure out why.This is what I did to the 'Open VI reference':
1. created a constant at 'Type specifier VI refnum' by right clicking at that terminal
3. created a constant at 'file path' terminal and specified the location of the sub-VI
http://lavag.org/old_files/monthly_10_2007/post-9618-1192817535.jpg' target="_blank">
This is the sample application...
The error means as the error handler VI can tell you, that the VI is not in memory. Why you may ask!
Because you think you provide a path to the VI to the Open VI primitive, but you don't. This VI will interprete a string input as VI name and nothing else. And when you provide a VI name only the VI must be already in memory.
What you want to do is change the string constant into a path constant instead!
And with that we are at the next problem. Using absolute path names to refer to VIs is ABSOLUTELY the worst you can do. This will immediately break when you move your project, or build an executable and/or install this on another machine.
So reconsider how you want to refer to those dynamic VIs. The way I do this is having a VI somewhere whose location is relative to the dynamically called VIs, for instance in the same directory. Then this VI queries its own path and strips its name from that path and returns that. Now append to that path the VI name you want to load et voila.
Rolf Kalbermatter
-
QUOTE(Neville D @ Oct 11 2007, 12:10 PM)
<br /><br /><br /><br />Do you have to run Thread config.vi in your code everytime? Or just once and LV will maintain the thread configs internally?<br /><br /><br />Neville.<br />That configuration should be stored in the LabVIEW INI file and reused on each load. Not sure about the current version of LabVIEW but you actually needed to restart LabVIEW in order to get that configuration active when Thread support was introduced in LabVIEW 5.0.
Rolf Kalbermatter
-
QUOTE(Gabi1 @ Oct 9 2007, 09:18 AM)
thanks Rolfk. do you mean you would not do reentrant LV2, and keep separate names? i kind of see an interresting recursive solution for these...altough it might not worth the trouble.Yes I do mean that and it's because of what you mention in your last sentence. A lot of work to create something which is hard to debug, maintain and use. I have some experience with this but with templates, since reentrancy was not possible for dynamic VIs back then. And it is a pain in the ###### whenever I have to go back and change something about it and then consequently test it too.
Rolf Kalbermatter
-
QUOTE(Smikey @ Oct 9 2007, 02:50 AM)
Hi, I'm Michael Panganiban from Philippines. I have installed SMX2064 Signametrics in PXI 1042 chassis. Other modules included are PXI 2570, PXI 6251, PXI 4110. SMX2064 comes with a device driver which I have installed properly without encountering problems. I also installed the Software for SMX2064 in which has a GUI made in Visual Basic. This softfront panel is used for simulation of the device in which function can be set, range, aperture, etc. Upon running this GUI (SM2064.exe) it always pop up a Negative Over Range window. Then I can't perform any kind of measurements. It seems that the device cannot read the input voltage I am supplying to the input of the SMX2064. The device is working properly based on MAX. I re-installed the device drivers again and software but same result was observed. Is there any compatibility issue with SMX2064? Hope to hear with you guys soon.I would say you are on the wrong board here. The SMX2064 not being a NI product, MAX can do little more than verify that the general PXI registers are there and some manufacturer identification is available. Other than that MAX does almost certainly not know how to access that board.
Then the Visual Basic application: If it encounters a problem, you will have to take it up with the programmer of that application. Again NI and probably just about anybody else here can not even guess what the problem might be.
Rolf Kalbermatter
-
QUOTE(Gabi1 @ Oct 9 2007, 08:49 AM)
quick follow up question:i never tried reentrant with uninitialised shift register.
how to recover a specific copy of the LV2 in such case? is there any other way than keeping a reference to each vi call?
Well aside from the obvious of having the VI simply in a BD and accessing that particular instance from there, no! Unlike non-reentrant VIs where the name of a VI is enough to reopen a VI reference to it, reentrant VIs maintain their data space attached to the VI instance (reference) and once you loose such a reference you loose the data space.
But then using reentrant VIs through VI Server is usually more trouble than it is worth so I personally wouldn't really do it.
Rolf Kalbermatter
-
QUOTE(JFM @ Oct 8 2007, 07:54 AM)
Hi,I just received information from NI, that this is a limitation of the Pharlap OS, on VxWorks targets (e.g. cRIO 9012) this limitation does not exist.
NI will fix the error message in LV-RT 8.5.1, but has no more information to get past this limit.
I'm not sure what version of Pharlap they purchased. But even if they got the source code for it, fiddling with the network socket code in an OS is a very tricky thing to do. Probably there would be a #define somewhere for the maximum allowable sockets and that is were it goes wrong. In many RT OSes the sockets are maintained in a static list and being static means it is preallocated at compile time and can never grow bigger than the max. Changing that into a dynamic list has possible performance drawbacks and makes the resource management in general more complex, so that is not something one wants to modify into an existing static implementation.
Nice to hear that VxWorks seems not to have this limitation.
Rolf Kalbermatter
-
QUOTE(klessm1 @ Oct 8 2007, 11:46 AM)
Thanks for your reply. For some reason I wasn't able to reply on my PC at home over the weekend. My browser settings must be hosed. Someone answered from the NI forums as well with the same diagnosis. I was able to replace LabVIEW's QTLib with Surrounds newer version and was able to get it to work. Now I have no idea is that is going to effect something in LabVIEW (something I haven't used yet). I have a support case with NI for this to see if they have any idea if the 4.3.0.0 version can be used, or if there is some way to trick LabVIEW and Surround to use their respective QTLib's.Thanks for the info!
The best bet is always to use the newer version of a lib if you get such a conflict but it will not always work. The newer version may change interfaces (yes it's a bad thing to do, but it's very easy to if the developers don't watch very extremely carefully) and then crash the application which was compiled to the older lib. But as long as it seems to work, I would definitely try it.
If you get to know what they use QTlib for, I would be really curious. I could try a disassembler but don't feel like doing it nor have I the time at the moment.
Rolf Kalbermatter
-
QUOTE(crelf @ Oct 8 2007, 06:48 AM)
That is mostly from comments on the wine-devel mailing list at http://www.winehq.org/pipermail/wine-devel/. But searching through all of the mailing list archives won't be trivial. A lot of work on MSI was done by Mike Mc Cormack and Robert Shearman from Codeweavers and they had some comments on MSI in a few mailings.
I couldn't find easily a specific wiki page for MSI on wiki.winehq.org so I'm not sure about a more concise collection on findings about MSI.
Rolf Kalbermatter
-
QUOTE(crelf @ Oct 7 2007, 03:01 PM)
Do you have any references where we could read more about that Rolf? I've been using msi for years and haven't really had a problem, and I'd be interested to hear why you and others think that it's overkill, huge and inflexible.Hard to find that back! I was looking about 6 months ago for a tool to see how MSI is built up to fix some issues with a corrupted installation that refused to allow me to uninstall it nor upgrade it to a newer version. And on the MS site I came across an article about the tool Orca which is basically the original tool to look into and edit MSI files.
In there one of the persons involved in the development of MSI quite at the start explained how it got started and the decision to use a relational database structure as the base of an MSI file and he was strongly suggesting that that use of a relational database was quite an overkill in terms of what needed to be solved but that at the time they started to realise it it was already a fact.
I would be glad to point you to that article but have to admit that I have no idea anymore what search criteria got me there in the first place but it was on an MS or MSDN site somewhere.
And on my current system most of the software that used to show up under the National Instruments Installer now also shows up in the main installed components section and refuses to uninstall from either location. Upgrading still seems to work for that software but I also have components visible that are really subcomponents of other (non NI) software and don't give any option to uninstall, repair or whatever. So I'm sure my MSI registry database is currently quite messed up but I hesitate to do a full reinstall of this machine as that takes me at least 3 days to do, with all the NI software and other tools that I frequently use. The MS registry clean utilities that should help don't do anything for these entries either!
PS: I do follow Wine development too and they did a lot of work on MSI support in the last two years and the overal consent there seems to be that MSI might be to most overengineered part of Windows and contains quite some rather questionable design decisions and implementations.
Rolf Kalbermatter
-
QUOTE(ashishuttarwar @ Oct 3 2007, 03:09 PM)
I would really recommned doing that. It's not a good idea to rely on a particular MAX default setting. You might end up just copying the program to a different computer (maybe your development machine died) and suddenly it doesn't work at all. Setting the serial port parameters explicitedly in your program before using it will prevent this problem. And believe me when you are in a hurry it is usually not the first thing to do to search the problem exactly there. So 5 minutes of extra programming time can save you many minutes or even hours of problem solving later on.
Rolf Kalbermatter
-
QUOTE(Michael_Aivaliotis @ May 16 2007, 07:57 PM)
So it turns out that the best way to resolve this is to uninstall ALL drivers and install the one I want before the build. Does anyone else see problems with this methodology? I mean, let's say for instance that you are supporting multiple projects with differnet driver version requirements. What then? If anyone's gone down this path, do you have any suggestions?I think NI shoot in their own foot when they decided to go with MSI as their installer solution. Not only is MSI even according to some of the people involved in its development quite an overkill in many aspects to the problem of software installation but it is such a huge and infelxible beast that you simply have two choices: Dump it and go for something else or live with its difficulties and inefficiencies. And as longer as you do the second as harder its gets to do the first.
Rolf Kalbermatter
-
-
QUOTE(klessm1 @ Oct 5 2007, 11:43 AM)
I have also posted this on the NI website, but I know you can get answers faster on this site.I am wondering if anyone else ran into this issue (probably not because most of you use SVN).
I am getting an error when trying to configure LabVIEW 8.5 to use Surround SCM version 5.0.4, and their new beta version 2008.0.25. I also get the error when just trying to make a dll call using the call library function (after I point to the dll and the function it gives the error). I have used two computers, and LabVIEW will load perforce and vss just fine through the options window. I also have TestStand on the systems and it integrates fine with both versions of the Seapine Surround SCM client. I tried a couple of different installation types (with and without the JRE) with no luck. I get two different errors when I run the two different versions, but they are similar types of errors.
The errors are attached.
I looked into if the dlls need to be registered, but I get the error that they don't have a register entry point, so they probably are not supposed to be registered. I do have the path for the dlls in the environment variables (put there by the installation of surround). The only thing I could maybe think of is somthing needs to be setup in LabVIEW to recognize the dll links. Like I said, no problem with TestStand 4.0 linking to either version (I believe it calls the same dll).
The dll in question is: Surround SCM SCCI.dll
That is the dll that is pointed to in the registry.
Final Notes:
The nice thing about Surround is that it allows you to set the working folder for the lowest project to the root (c:\). This allows me to contain the project specific code as well as the reuse code (user.lib) in the same repository. Therefore allowing me to control all of the code in my project through the LabVIEW project window without having to change the project settings for the SCC. VSS also allows this, but I do not really want this to come to that (size limitations, no atomic commits :thumbdown: ).
I was not able to get Perforce to allow me to set the root project to C:\. I did test out subversion, but it took me quite awhile to set it up (even without apache). I also could not see how to capture revisions of a release for a LabVIEW project that calls reuse code outside it's project directory. Would you just record the global version and save the names of all of the VI's (and TestStand sequences) called by the project? To restore that version of the project on your system you would get individual files per the revision, or would you get the entire repository based on that global revision? Help me out here almighty Subversion masters. :worship:
Thanks for any inputs.
LabVIEW 8.5 does use the QTLib for something in its user interface or whatever but I'm not sure for what. Look in your LabVIEW 8.5 directory to see those DLLs. The problem you are having is that your Surround SCC software uses that library too but not the same version as LabVIEW 8.5 uses. That gets you into the so called DLL hell. LabVIEW already has loaded it's own QTLib DLLs when the Surround SCC client gets loaded. This client also wants to load his QTLib for some functionality but since Windows sees that that DLL is already loaded into the current process it will simply attempt to have this client library link to LabVIEWs version of the DLL. And that goes wrong since those libraries are not binary compatible, something Unix shared library developers never usually worry to much about since they are used to versioning of the shared library name to resolve such issues.
I'm afraid you run into a roadblock with Surround and LabVIEW 8.5. As I have no idea for what LabVIEW 8.5 brings its QTLib stuff with it I can also not help you with any ideas if and what would have to be disabled in LabVIEW in order to not have it load QTLib, if anything can be disabled. For its UI Widget stuff I can't really imagine that they replaced the entire existing windows manager code to use QTLib instead of continuing to use their own already implemented window management code, so what QTLib really is good for in LabVIEW 8.5 is really a secret to me.
Rolf Kalbermatter
-
QUOTE(Aristos Queue @ Oct 6 2007, 06:32 PM)
Yeah! How did you do that?! When I put together the code for "Inputs req'd by default" for 8.5, I couldn't figure out how to get req'd outputs into the C code. So I'd love to know how you did it from G!I would try to make a control required and then turn it into an indicator. But not sure if that could produce something. It certainly didn't in earlier versions.
Rolf Kalbermatter
-
QUOTE(Yannick @ Oct 4 2007, 03:18 AM)
Duplicate post, see http://forums.ni.com/ni/board/message?board.id=170&message.id=276066#M276066' target="_blank">here.
The explanation in that post for string pointers inside a structure is wrong. It won't work like that without extra measures. Depending on the DLL it may crash immediately, corrupt some memory silently and crash later on, but something will go wrong sooner or later.
Rolf Kalbermatter
-
QUOTE(BrokenArrow @ Oct 2 2007, 03:55 PM)
Thanks for all the response. Yep, this seems like more trouble than it's worth. The customer is used to an old DOS-based text file that had those box characters. The way I got LabVIEW to do it was to send FFFE 6625 and I got ╦. BUT, when it writes the "txt" file, and you open it in notepad, sure enough it looks fine, but it says it's Unicode encoded. Try to read that file BACK into LabVIEW and it's SOL.Thanks for the education, I didn't know "extended ASCII" was so softly defined, since I've been using those alt+200 type things successfully since 1986 in DOS, I just figured it would work the same way in LV.
-Richard
Those box characters did even in DOS only show up if one didn't use some other codepage for displaying. Now caused codepages in DOS such a pain that they were not as often used so you could usually get away with this, but Windows 3.1 extended the codepage idea greatly and made serious use of it before they implemented 16bit Unicode support in Windows NT and ported it back for Windows 95. Only with Unicode was it possible to have support for displaying different languages at the same time without constantly having to switch codepages. Another means for that was MBCS (multibyte character encoding)which is what LabVIEW uses itself to support eastern languages in its localized versions but that is quite a painful standard as a character can have a varying number of bytes, with certain codes reserved to indicate the switch to a different "codepage".
While the display of the lower half of ASCII characters is well defined, what is displayed for the higher half depends on the viewer and its interpretation. If displayed in a Windows (and LabVIEW) control you can also get away with setting them to certain fonts as every font has an implicit codepage for its first 256 characters.
Rolf Kalbermatter
-
QUOTE(robijn @ Oct 3 2007, 03:49 AM)
Hello,Rolf, I think you are making things too complicated here. Microsoft themselves introduced the semicolon (
as comment symbol, so although it's not a standard as in ISO or IEEE I don't think there can be too much discussion about how you should place comments in an ini file. Note NI calls them config files, I guess to stay out of MS's water. My experience with config files and the routines I have developed a couple of years back, is that it is possible to enhance the functionality and speed greatly over NI's routines. To prevent messing up the file layout, I am modifying only the value part and keep the rest of the text unmodified, and don't reconstruct the section by collecting keys and values. I insert new keys at the beginning of a new line (after the last written entry or at the end, depending on whether somethings was already written). These are simple measures to retain comments.Other useful improvements could be to write entire sections (so you can store other kinds of data). That way, you can store 1D or 2D arrays of DBL/I32/string in a transparant way in a section.JorisPS yeah that smiley should have been a semicolonWhat I meant is that the WinAPI to deal with ini files has no clean means of dealing with comments.
Adding them is impossible through the API and ignoring them is very limited.
Only lines starting with a semicolon will be ignored at all by recent Windows versions.
But for a line
myToken=YES; This is a comment
querying myToken will return "YES; This is a comment"
Definitely not what the OP wanted!
The same funcionality and more than what Windows has can be already done with the Configuration functions. The only drawback with those functions is that they disturb the layout of ini files sometimes (but not the functionality). And all I can say to that is that INI files are not really meant to be read by humans and definitely not by non-programmers. That is one reason why MS moved it into the registry where the presentation of data is left to an application (regedit) instead of having it embedded in the data.
Rolf Kalbermatter
-
QUOTE(siva @ Oct 3 2007, 03:16 AM)
Thank you everybody for their valuable suggestions. Finally, I got a way to change the Document_Root while run-time.Before Starting the G Server, I kept a sequence to change the required changes in Document_root.
http://lavag.org/old_files/monthly_10_2007/post-4279-1191399091.jpg' target="_blank">
I used 2 VIs (HTTP Set Directive Value.vi, HTTP Get Directive Value.vi) in config.llb(Internet Toolkit) to do this.
OK I see you are using the InternetToolkit Web Server. The App Properties mentioned are only present for the
built in Web Server in newer LabVIEW systems. Can't do everything the Internet Toolkit server can (such as CGI)
but is quite capable for more static things.
Rolf Kalbermatter
-
QUOTE(EdDeWitt @ Oct 1 2007, 03:09 PM)
Per "LabVIEW for Everyone", there is no standard method for .ini files in LabVIEW. It's nice that they told me this, but did not tell me actually how to enter comments. I needed to comment the section titles and so I just tried a few things. Turns out, you can just put text after the "]" of you section title and it will be ignored. I don't know how to comment keys, though, becasue I did not require this. Hope this helps. Below is a sample of my .ini file with section header, comment, and a few keys...[65] A
a = 0
b = 122880
c = 7680
Not just LabVIEW for everyone!!! There isn't any standard at all and the only defacto standard is what Windows invented for ini files and as far as Windows is concerned there are no comments in an ini file. The fact that there are lines that contain some data that is never queried with a GetPrivateProfileString is all that makes them comments. Similarly SetPrivateProfileString does not really give you any functionality to add comments to an ini file.
As per Windows a section is enclosed between brackets and what comes behind is not read and a ini token has a name that starts a line and a value that follows the equal sign. The value can be a quoted string if it must contain line breaks but otherwise it goes to the end of the line.
One could of course devise various variants on this and restrict above limit to request double quoted strings for anything that contains line breaks AND spaces and stop reading a token value as soon as there is a non quoted space but that is not how Windows invented it. The Configuration functions already do some non-Windows stuff by escaping special characters and normalizing paths in order to be platform independant.
If you want to change above behaviour it is fairly easy to modify the Configuration file VI's to do so as they are clearly structured and build up. They do the double quoting already for strings containing spaces but at least in 8.2.1 is a bug in that respect where the quoting is skipped if the section did not yet exist when adding a new key.
Extending the configuration VIs to allow adding comments programmatically will however by a much more involved task. It's one thing to just ignore some data and a completely different one to add infrastructure to support it.
Rolf Kalbermatter
-
QUOTE(Aristos Queue @ Sep 30 2007, 10:36 AM)
Then change the layout of that VI to be a size 13 grid. But to open existing VIs with random (effectively) grid sizes such that the size used to achieve that layout is not preserved makes it impossible to make adjustments without blowing away the layout.You mentioned the arrow keys and alignment tools. Those predate the alignment grid. They were ruled insufficient for laying out at VI. The alignment grid makes it possible to quickly do layout using certain rules (buttons should be XYZ size, controls should be N pixels apart, window border around controls should be Q pixels...) without having to count with arrow keys or copy a screenshot of the FP into a paint program to count pixels.
By your argument, the background color of the VI should change when loaded on a system where the programmer has changed the default background color instead of being saved with each individual VI. The grid size used to construct a front panel is integral to preserving the look/feel of a VI.
Hmm, I have to say that the FP grid does not work like this for me. I tend to drop controls on a front panel and then nudge them with the cursors to where I want them (or use alignment and distribution) since the grid simply does not work well for me independent of what settings I have it. I recently resorted to disable the grid snapping for most VIs I'm working on after I found this by accident.
For FPs that are meant to be visible to the end user the grid is to restrictive to get the look I want, since most of my FPs except the main screens usually really are application dialogs and use the system dialog style, and for other FPs I just put them so they are logically aligned in a similar manner than the connector pane is layed out.
As far as I'm concerned a global "don't snap to the grid" option would be the best I could ask for.
And yes my FPs usually adapt the background color to the system dialog background color too, so there goes your other argument :-)
Rolf Kalbermatter
-
QUOTE(ryanlai @ Oct 1 2007, 03:01 AM)
You can get some more detailed explanation for instance here http://www.thaiio.com/parallelportinfo.html
So if VISA Read and Write will do the right thing on a parallel port depends on the actual wiring, the mode the parallel port is set in Windows and if the hardware supports that properly, which nowadays integrated chip-sets usually should.
Who after this discurs still thinks connecting computers through a parallel port is a good idea, does this for a hobby and knows what side of a solder iron gets hot or can't be helped IMHO. Getting a serial port wired up correctly is in comparison almost trivial.
Rolf Kalbermatter
-
QUOTE(Eugen Graf @ Oct 1 2007, 09:35 AM)
For anyone looking for this information: Basically lvserial is meant to work similar to the VISA functions but without using VISA and instead going directly to the Windows COMM API. And I think Martin Henz did an amazing job and someone ELSE could put some time into it to help with documentation if they feel it is needed.
Rolf Kalbermatter
-
QUOTE(Michael_Aivaliotis @ Oct 1 2007, 10:31 AM)
In order to resolve the original posters problem (and to be 100% sure), you would have to open every single tree of every project your company produced in their lifetime. Not very practical.It seems like there should be a way to get notified, and the ClearCase triggers seem to be it, however is sounds complicated and requires a lot of setup.
Personally I have resolved to copy my library VIs into the project directory itself whenever used in a project to avoid the mentioned troubles of changed behaviour between project developments.
And one other thing I usually do for bigger projects is a unit test framework. It will not solve the problem of automatically detecting any dependencies in any project you ever programmed, but for projects where you have a well defined unit test framework in place you can easily run this unit test in every project you are interested in regularly to make sure there have been no regressions. This also helps greatly during development of a project itself where you can tend to make subtle changes to a seemingly unimportant function and suddenly other things fail in an amazing way.
Rolf Kalbermatter
-
QUOTE(Ben @ Oct 1 2007, 05:42 PM)
It could be as easy as changing the LabVEW.ini tokens before LV launches.WebServer.RootPath=C:\Program Files\National Instruments\LabVIEW 8.2\www\new
There also seems to be some new twists on this Q, see http://forums.ni.com/ni/board/message?board.id=170&message.id=273531#M273531' target="_blank">this thread On NI.
Is tnis what you are after?
Ben
There are also Application Properties for this but I'm not sure if they are visible in a standard LabVIEW installation.
Rolf Kalbermatter
Multi screens and security levels in LabView8.5
in User Interface
Posted
QUOTE(Justin Goeres @ Oct 17 2007, 08:10 AM)
Well, that is not entirely true. The LabVIEW DSC Toolkit comes with an access control library with user configuration dialogs and login screens and a Wizard that can enable and disable controls in a front panel based on the currently active user from this access control system. It is quite powerful but the entire DSC Toolkit is not cheap and if it is only just for this user access control sybsystem it might be a bit overkill. On the other hand it is (or at least used to be, not sure about the latest status) something you could embed in your own applications without runtime license fees (not true for most other parts of the DSC Toolkit) and designing your own even remotely comparable access control system will cost a lot more in money and not have the ease of use of a front panel control configuration wizard.
Rolf Kalbermatter