Rolf Kalbermatter

QUOTE (Götz Becker @ May 8 2009, 03:20 AM) Well 2 to 3 minutes sound quite bad. I did recently a project on an cFP-2020 controller (77MHz RT controller) and while it takes some time to deploy it was less than 3 minutes for sure. There were a few problems on that system that made it take up more time than I had suspected but the deployment was not the big factor on it. 1) one was that the source code debugger sometimes caused the controller to die completely when single stepping through the code. This is a known problem with the used LV 8.2.1 version but an upgrade was for other reasons not desirable. 2) Enabling VI Server on the controller made the system grind to a crawl so it was not able to do its task. I had to integrate all the parameter downloads into the controller into my already existing TCP/IP server instead of just remotely call the according VIs. 3) As the system integrated more and more functionality I had to find out that normal while loops are a bad thing on a real time controller. It worked perfectly and blazingly fast on my notebook system but started to slow down on the controller. Replacing all long running loops with timed loops made the system fully responsive again. 4) last but not least but this was not because of the LabVIEW environment or real time nature, but because of the customer application: It had been a monolithic application running on a desktop system before, with countless global variables scattered throughout the controller part and the user interface part influencing each other back and forth. When calculating the needed development time I had vastly underestimated the time needed to separate this more or less cleanly into a user interface application running on the desktop machine, and an independant controller application running on the RT controller. All in all I guess the time needed to do this would have been not less than writing the whole application from scratch again, but the LabVIEW diagram was unfortunately more or less all that was there in terms of documentation of the existing system and its interaction between the different instruments and IOs. Your 3 to 10 times development overhead is definitly way to overestimated. There is some extra time to find out about the specific details of the RT system and the used hardware but not that much. I would really recommend to start with a good system design that works on your local desktop too and then port the controller part to the RT hardware. This should be quite a simple step considering that LabVIEW on a RT system is really quite like on the normal Desktop. An interesting starting point might be also the NI System References Designs, specifically for RT and HMI applications http://zone.ni.com/devzone/fn/p/sn/n23:1.7489,n24:RefDesigns. I've been using my own system reference design from earlier projects which have the advantage that I have the complete source code of every part of the system but the Reference Designs have some good ideas and even components you can take into your applications. Rolf Kalbermatter

QUOTE (Gavin Burnell @ May 7 2009, 02:33 PM) Actually its a bit more flexible than that I think. However there are for sure difficulties. Rolf Kalbermatter

QUOTE (shoneill @ May 7 2009, 09:50 AM) Just a quick and dirty example. I didn't try to get around having to supply a valid path to the method note. Download File:post-349-1241721479.zip It's LV 8.0 because although the node is there, it returns an unimplemented error in 7.1. (04/20/2014rk, the original link got lost in an earlier LAVAG server crash) Attached is a more user friendly version of that VI. It uses the OpenG file library to create a temporary file name and makes the turnaround through a disk file in LabVIEW versions prior to 8.0. VISRV Create VI from Binary Buffer.vi

QUOTE (neBulus @ May 7 2009, 07:45 AM) In newer versions of LabVIEW the need to save the VI to disk would not even be necessary since you can create an in memory VI object just from the binary stream using private methods. Rolf Kalbermatter

QUOTE (Cool-LV @ May 6 2009, 01:14 AM) It is a combination of knowledge gained from some investigations of my own, various infos picked up from different discussions here and on the NI discussion forums, talks with some people who did probably know more, and some combinatorics. Rolf Kalbermatter

QUOTE (drake27 @ May 4 2009, 01:13 AM) There isn't a common way to note the author of a VI. Some place a comment in the diagram, others on the front panel, others yet again on the VI description and last but not least there is the VI Property "History.Entire Text" that returns the names and comments of all the changes made to the VI, IF and only IF the user had this feature enabled, which most don't since it is a pain in the ######. In general a lot of VIs do not even contain information about the author at all. Rolf Kalbermatter

QUOTE (deniz @ May 1 2009, 10:14 AM) The LLB is simply an additional hierarchy level in the path to the VI and has absolutely nothing to do with your problem here. You have some problem in how you call those VIs and/or when, but the fact that it is in an LLB changes nothing, except maybe if the VI assumes internally that it can write to a file in the same directory as where it resides itself, but from what you describe it is not clear if that might be a problem here. I also don't understand why you are using the Invoke Node instead of just simply putting the icon into the diagram. Usually condensing down everything into a simple example that you can upload here will help much more than 10 pages of hard to understand explanations of what you think you might be doing. Rolf Kalbermatter

QUOTE (santi122 @ Apr 30 2009, 01:28 AM) You can even keep the error wire wired to the TCP Close function. All Close functions in LabVIEW "should" (and usually do) close the refnum they are given, independant of the error in. There were a few LabVIEW versions in the past where one or the other did have a bug and did not properly do so but that was usually fixed very quickly. Rolf Kalbermatter

QUOTE (newTOlabview @ Apr 30 2009, 07:51 AM) I would hope that the NI people have actually done something between these versions other than just bumping up the version number, don't you agree? Rolf Kalbermatter

QUOTE (stevea1973 @ May 2 2009, 09:43 PM) No LabVIEW has to this point no official Unicode support. You can make it work sort of by adding an token to the INI file but it is still not full support for Unicode strings in all LabVIEW strings. But there is a LabVIEW VI library unicode.llb at both on the NI site and also here posted as attachment to some posts (Google is your friend ), that calls into the MultiByteToWideChar and WideCharToMultiByte Windows APIs to do the translation between the LabVIEW MultiByte encoding and Unicode 16Bit encoding. Rolf Kalbermatter

QUOTE (Antoine Châlons @ Apr 29 2009, 10:03 AM) But this returns always the same information for a VI????? What would that be good for? Rolf Kalbermatter

QUOTE (candidus @ Apr 28 2009, 06:36 AM) I think first of all that this is not even doing what you think it does or want it to do. The value of an object refnum is the refnum itself (a 32 bit identifier that identifies the object in the current LabVIEw context), not the data the object contains so what you try to do is assigning the refnum to itself really. Now why the flattened variant of the refnum doesn't convert (unvariant) easily to the refnum again I'm not sure but it may have to do with the fact that a variant does not define the exact datatype as strictly as this function expects. Variants are very dynamic and can in fact represent the same data logically in different ways with different levels of type containement. You would have to analyze the typedescriptor that is returned from the Flatten to String function and compare it with the flattened typedescriptor of the newly created variant to see if there is something special. But considering that this does anyhow not what you want I really wonder if you want to spend more time on this. Rolf Kalbermatter

QUOTE (LVBeginner @ Apr 27 2009, 09:54 AM) Well I can't even access it so I have no idea what it looks like, or what it does. I don't even know that it exists for real when going there with my webbrowser. Rolf Kalbermatter

QUOTE (LVBeginner @ Apr 27 2009, 07:29 AM) And what the heck is hermes??????????????????????????????????????? Rolf Kalbermatter

QUOTE (manojba @ Apr 27 2009, 01:48 AM) If the runtime engine is already installed on the system you can usually just copy the build directory from the application builder step to that machine. But you will need to install the runtime engine no matter what. Up to version 5.1 it was very easy to just copy everything to another machine, drop in the lvrt.dll file from the runtime engine directory alongside the exe et voila. But LabVIEW has since evolved and added a lot of features that depend on additional components being installed on a machine. Those components get installed together with the runtime engine. With LabVIEW 6 and 7 it was still possible to do such a distribution to some extend but it was a lot more trial and error which files you needed to copy from the runtime engine directory into your application directory to make it self contained. lvrt.dll alone definitly is not enough anymore and things like Advanced Analysis functions won't work since LabVIEW 7.1, since they make almost all use of the Intel Math Kernel Library from that version on and that is an external component that needs to be installed on a system in order for the LabVIEW system to find it. With LabVIEW 8.x I have not attempted to do self contained applications so far and do not intend to spend any time in doing so. The whole LabVIEW runtime universe got in the meantime so complicated and interconnected that I see no point in spending time to figure out everything just to avoid having to run an installer application. Rolf Kalbermatter

QUOTE (crossrulz @ Apr 22 2009, 01:33 PM) I think you mix up ordered and sorted. The term ordered means in my book really that there is a certain distinct ordering to the elements which there is through the array index, just as in a cluster through the element order. That does probably not mean that the elements are sorted at all in ascending, descending or whatever else order But then I might be wrong here too and they are in fact saying that arrays are not sorted with that statement and then answer E would be right according to the strange multiple choice system that in the US seems so common. It's just not what in programming terminology is usually meant by the term ordered. Rolf Kalbermatter

QUOTE (Yair @ Apr 24 2009, 03:39 AM) Well cross linking probably isn't the issue here as the Clipboard resides in the global LabVIEW context wheras each project has its own context. I think that Yair has it right that it is a side effect from the project maintaining links to all VIs that it has opened somewhere and that includes VIs placed in the clipboard. On closing of the project all such VIs get closed too. Is it a bug? Well strictly speaking I would say no. Could it be made to make an exemption in the case of clipboard code? I have really no idea. At first glance it would seem possible but I might just as well oversee a big pitfall in doing so. Rolf Kalbermatter

QUOTE (TobyD @ Apr 7 2009, 01:22 PM) I think you are right but that might have other implications somewhere they tried to fix by ordering the operations like this. With such things it is often very hard to fix something without breaking something else, and even harder to think of possibilities what might break by the fix. Rolf Kalbermatter

QUOTE (Aristos Queue @ Apr 24 2009, 09:03 PM) He probably means that it is not anymore possible to drop in a single node that does the entire conversion for all datatypes automatically. With those VIs you might have to create a VI that makes explicit conversion in a case structure based on this enum and that will then not work for a new datatype in the next LabVIEW version without modification. Rolf Kalbermatter

QUOTE (candidus @ Apr 24 2009, 02:37 PM) Nothing. The new 32 bit typedescritors LabVIEW uses internally are not exposed in any way. Rolf Kalbermatter

QUOTE (candidus @ Apr 24 2009, 01:46 PM) Well for strict typedefed refnums yes, which can be recognized from the little star in the refnum icon. QUOTE But what's about the change in the class hierarchy? In LV8.0 XYGraph seems to be a subtype of WaveformGraph, at least the RefNum looked like that and I noticed it changed when just opening the VI in LV8.0 . I'm correcting myself: In LV7.1.0 XYGraph seems to be a subtype of WaveformGraph. Not sure about this one. A change in the location inside the class hierarchy should not have an influence on the datatype but only on the inherited properties from its ancestor classes. Rolf Kalbermatter

QUOTE (normandinf @ Apr 24 2009, 11:16 AM) Actually they can have at least two formats for single plot and multi plot waveforms each and I believe even more if you get fancy. Rolf Kalbermatter

QUOTE (candidus @ Apr 24 2009, 04:26 AM) Hmm, you definitly mix up something here. XY Graphs exist as far back as LabVIEW 2 and in the form and dataformat they have today since LabVIEW 3. Rolf Kalbermatter

QUOTE (LVBeginner @ Apr 23 2009, 02:46 PM) When I browse to that server I get a dialog box that only IE is allowed to go there. When I use IE I get a login page. Now looking at the HTML code there seems to be some scripting done for this functionality. So it seems you would have to not only send a User Agent but in fact a very specific User Agent. Trying with the OpenG VI a bit I can see that you need to use at least following information: GET \ HTTP/1.0\r\n User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; WWTClient2; OfficeLiveConnector.1.3; OfficeLivePatch.0.0)\r\n Host: www.plexus-online.com\r\n \r\n to get a valid response. You probably can get rid of some of the software versions about .NET and Office in the User Agent string. But that response contains JAVA scripting so there is the next problem!!!! I don't think you want to implement Java script in LabVIEW Rolf Kalbermatter

QUOTE (jdm @ Apr 21 2009, 02:43 PM) Well I do not know that library but most likely HIDInterface is a structure. And it probably contains pointers and such. So there is no easy way that you could access information in that structure directly from within LabVIEW since LabVIEW itself does not have pointer datatypes. There are two possibilities: 1) You do not really need to access any of the information in that Cluster (structure) directly. In that case you can configure the pointer to the structure simply as a 32 byte integer in all functions that have this parameter.Then you pass that integer around on the LabVIEW diagram to the various Call Library Nodes that need to operate on that structure. This requires that you have a a function that you can call that will return to you a preconfigured HIDInterface pointer so that you would not have to access the elements in that structure directly. There is a hid_new_HIDInterface() function in libhid but your MCC library hoefully has a higher level function that calls this function but fills in all the fields of that structure. Also there needs to be some sort of close function such as hid_close() that takes this parameter and makes sure all internal resources are deallocate. 2) your MCC library does not provide enough functions to allow configuring that structure without needing to access elements in that structure directly. In that case you really will have to extend the MCC library to export some additional functions that allow passing in all the paremters that you need to assign to that structure and the function then initializes/accesses that structure accordingly. Rolf Kalbermatter