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

QUOTE (mesmith @ Apr 23 2009, 11:06 AM) Well HTTP proxy is really a whole layer above TCP/IP so there is no way the LabVIEW TCP/IP nodes should or even could support HTTP proxy functionality. That has to be built on top of those TCP/IP nodes and that is in fact fairly easy. As I have written elsewhere here, there is a non-released HTTP library on OpenG that supports proxy access and has worked fine for me in the past. Non-released means you can't get the library through VIPM but have to get the actual VIs from the OpenG Toolkit CVS repository on Sourceforge. You can do that by using a CVS client such as Turtoise CVS or by using the Sourceforge Web Browser interface to their CVS service. VIPM actually uses those VIs to access the code repositories! Rolf Kalbermatter

QUOTE (crelf @ Apr 23 2009, 09:07 AM) I stated my stance a few times and think that's enough Rolf Kalbermatter

QUOTE (Cat @ Apr 15 2009, 02:28 PM) Well, a LabVIEW exe itself actually never writes to its ini file, except when it is not there, in which case it creates an empty ini file. The way I do this is by always adding an ini file into the build. This ini file contains a few default settings such as to suppress the secondary task bar button for the hidden root window, specific font settings for the different LabVIEW default fonts and possibly VI server settings. All the actual configuration settings for my applications are not stored in that ini file but in a seperate ini file either located under Documents and Settings\All Users\Application Data\<app name> for settings that are used for any user on a particular machine (hardware configuration) and under Documents and Settings\<user name>\Local Settings\Application Data\<app name> for settings that are user specific. Works fine even in environments fairly strictly locked down by IT departements. And for what I know it should even work for Vista, which I luckily had not to deal with yet. Rolf Kalbermatter

QUOTE (crelf @ Apr 5 2009, 03:08 PM) :laugh:

QUOTE (Cool-LV @ Apr 3 2009, 04:39 AM) It is a separate license but there is no article number on the NI site for it and no scripting license you can buy. It is only for internal use within NI and maybe very selected strategic external contacts. The license Manager is here used to protect that feature from being easily used by us mere mortals. Rolf Kalbermatter

QUOTE (shoneill @ Apr 8 2009, 08:10 AM) At that age at least Later it tends to equalize and a year also tends to mean less and less. QUOTE Way to go off-topic. That is always as threads get longer. But fortunately we seldom get Godwins law invoked here. Rolf Kalbermatter

QUOTE (shoneill @ Apr 8 2009, 08:10 AM) At that age at least Later it tends to equalize and a year also tends to mean less and less. QUOTE Way to go off-topic. That is always as threads get longer. But fortunately we seldom get Godwins law invoked here. Rolf Kalbermatter

QUOTE (Kubo @ Apr 7 2009, 10:41 AM) PPP connections are usually handled by RAS (Remote Access Service) under Windows. There is a Windows API and I once did a LabVIEW interface to that but can't distribute it. But there is also a command line tool rasdial.exe to control RAS connections that you can call using the LabVIEW System Exec function. Rolf Kalbermatter

QUOTE (Jolt @ Apr 9 2009, 02:54 PM) All these things are one of the reason to not use ActiveX or .Net for things that can be solved otherwise. The HTTP protocol on the client side is not that terribly complicated to not implement it directly in LabVIEW. LV_FPGA has posted his code. In the CVS repository on OpenG are some HTTP Vis too, that haven't made it into a released OpenG package yet. Rolf Kalbermatter

QUOTE (Steen Schmidt @ Apr 7 2009, 03:50 PM) I haven't done much with vXWorks and certainly not used any resources in such a project so I can't say with authority but I don't think the VxWorks build system actually knows something like that. The Pharlap system uses simply a PE (portable executable) image format and such DLLs can contain resources but if you can't use a VI calling the Windows APIs to retrieve the file version, the Pharlap OS probably lacks proper API support to deal with the resource part of a PE image. At least for headless systems such as the LabVIEW realtime controllers this seems like a very sensible decision as it makes not so much sense to support a fully fledged resource access API when most of those resources are mostly used for UI purpose only. Rolf Kalbermatter

QUOTE (jcarmody @ Apr 7 2009, 09:54 AM) How would you want to do that? LabVIEW is strongly typed and the only way to do what you want to do is using variants, but the internal C interface to them is not documented anywhere (though I have to admit I never inquired if it could be gotten in some semi official way anyhow such as what we got for the old scripting API that is also used in the script node interface of LabPython). But even using variants you usually have to convert the data back to some datatype in the end although you could of course go for strings if it is only about displaying them. If you only want to convert to strings I believe you should be able to do so already since the used Python API should actually be able to return string format for all its datatypes but it's a long time ago that I have played with this and it could be that there is somewhere a problem that makes this fail. Rolf Kalbermatter

QUOTE (greatwall @ Apr 6 2009, 11:04 AM) There are basically three possibilities. The first type of pointers are scalars passed by reference such as your first parameter (int* name) is. This is not a problem in LabVIEW. The second are arrays passed to the DLL such as a (char *buf). These have to get allocated by the caller in all cases and you can do that in LabVIEW also using for instance the Initialize Array function. The third are arrays passed by reference (char **buf) both allocated by the caller or the DLL. Since LabVIEW doesn't have a pointer datatype it can not really represent such a datatype itself. And if the DLL allocates such a pointer things get even more complicated since LabVIEW has no way of knowing what type of heap manager allocated them but it has a very specific expectation of how memory blocks are allocated. If you can change the DLL (even if you have the source code that is not always an option) you can adapt the functions to play with compatible LabVIEW datatypes or use the LabVIEW memory manager functions from extcode.h to create functions that accept directly LabVIEW native datatypes. You would then configure the corresponding parameter in the Call Library Node to Adapt to Type. Doing this last option requires both a very good understanding of C in general as well as about the use of those LabVIEW memory manager functions. If changing the DLL is no option you can always create an intermediate DLL that does translate between whatever the original DLL requires and what works best for the LabVIEW interface. Here too you have the choice to either use LabVIEW compatible C datatypes or use the LabVIEW memory manager fucntions to deal directly with the native LabVIEW data buffers. Rolf Kalbermatter

QUOTE (Aristos Queue @ Apr 7 2009, 12:48 AM) Very right here. Sometimes I wonder if starting up my PC might not already be some violation of some license agreement I somehow, sometime clicked away without really bothering to read it . Not that this would bother me to much as I have good hope that such a license agreement would not be enforceable in any way, but still. While I also loved to know how software worked back then I usually only went as far as getting things apart to the point where I could see how I could go around whatever protection there was. At that point the attraction somehow went away to go further but I had some friends that for sure did it for the hack itself and wouldn't be satisfied before they could distribute a tape (C64 ) with the cracked software and at least a screen hacked into the game somewhere with their alias in it. My brother and me instead took older C64 apart and rebuild them to control the light show in a disco club. You could say the first attempts at embedded development and it was cheap too, if you didn't account for the hours , which at that time wasn't a fully paid job anyhow. Rolf Kalbermatter

QUOTE (crelf @ Apr 6 2009, 05:11 PM) Ah but last time I checked the shortcut menus of build-in LabVIEW objects seemed still to be straight coded up in the LabVIEW C source code and not some hidden LabVIEW VI somewhere. So that seems like a problem to me :headbang: Rolf Kalbermatter

QUOTE (xavier30 @ Apr 6 2009, 08:36 AM) Or the libraries g++ 3.4 uses are buggy. It has happened before. Open source doesn't mean bug free! Or using g++ 3.2 only hides the problem for now and there is still a bug in your shared lib. Just because a shared lib is not crashing does really not mean to much about it not having illegal pointer releases or accesses. It could just happen to occurr in a situation that does not crash for the moment and semmingly small changes in the code or even in the LabVIEW app can trigger the crash. Rolf Kalbermatter

QUOTE (Neville D @ Apr 3 2009, 03:54 PM) At least someone cleaned them up in the meantime aligning the nodes wires and added error clusters. The old code when it was acquired by NI definitely was about how NOT to write proper LabVIEW code. It violated just about every style guideline that was ever released about how to code LabVIEW VIs. I wonder if the original C code behind it was just as messy, but doubt it as it would be almost impossible to make such a big and complex piece of SW work at all then. Rolf Kalbermatter

QUOTE (Klompmans @ Mar 31 2009, 10:02 AM) Well I have to say that in the old days I was wishing this too a lot. Before starting with LabVIEW a long time ago, I had worked with a graphical aditor called ged. This was a Unix graphical editor usable for all kinds of things but in our case we were drawing schematic designs with it. It had a pretty fixed UI: a big drawing area, a button bar on the right border with clickable commands (configurable with a configuration file as to what exact command they should do), and a command line on the lower edge where you could also type in all the commands from the button bar as well as many more. The design was stored on disk as a ASCI file and could then be used as input to various other tools such as a PCB editor or an ASIC development toolchain. I was rarely using the buttons on the button bar but almost constantly typing the abbreviated commands. Sure it required some time to get used to the commands but once you knew them there was no way someone using the mouse could even get close in speed :laugh: . When starting to work with LabVIEW I loved almost everything about it except the lack of such a command line interface. However that was in the days of LabVIEW 3 and there was no way one could get access to the LabVIEW interna like it is possible now with the scripting interface. There was supposedly a much opener C interface to the LabVIEW kernel (anyone remember tools like SurfaceVIEW or the predecessor to the Vision Toolkit developed by Graftek, or the first version of the Picture Control, who all made use of methods in that C interface not exposed in such a way anymore since a long time) but to be able to use that, one had to basically be intimate with a lot of the LabVIEW interna in a way that was impossible for someone not having worked in the LabVIEW development team. I think QuickDrop is a good addition but in my case it is about 10 years to late . I'm not sure I still feel like memorizing keyboard shortcuts for various operations that have gotten so ingrained in my cerebral system that I only have to think about them when something about them has changed between LabVIEW versions :laugh: . That is also why I hate it so much (loat it actually) that the function palettes get reshuffled with almost every new version. Rolf Kalbermatter

QUOTE (EHM @ Apr 3 2009, 02:57 AM) No problem here with that URL when I use the OpenG HTTP VIs. I'm not using a proxy but this shouldn't really be a problem. Go get those VIs (there is no HTTP OpenG package yet so you have to get them from the sourceforge CVS repository) and look at them. Rolf Kalbermatter