Rolf Kalbermatter

QUOTE(brent99 @ Feb 22 2008, 05:08 PM) No definitely not! The entire UI widgets have been written for LabVIEW 3.0 from scratch based on the drect windowing API of the spcific platform (X11,Windows GDI and Mac OS QD) and that hasn't changed at all until now. The only real modification was with the adding of the 3D types of controls in LabVIEW 6, but they are based on the same proprietary object model that is used for the other built in LabVIEW widgets. QT appearently only is used for the Multiple Variable Editor that is part of the LabVIEW Data Logging and Supervisory Toolkit, but since the LabVIEW installations contains that anyhow (but the according license is necessary to enable that functionality) it comes with every standard LabVIEW installation and since it is in the executable directory, Windows will always prefer to load those libraries if some component such as the SCC API provider for said system needs to load those libraries with that specific same name. Rolf Kalbermatter

QUOTE(orko @ Feb 21 2008, 01:00 PM) No! This really works for any program that uses VISA to communicate with the port (serial, GPIB, and whatever). NI Spy in fact simply intercepts all VISA API calls and monitors them. Of course standard Windows applciations using directly the Windows Comm API can't be monitored in that way. Rolf KAlbermatter

QUOTE(Khodarev @ Feb 7 2008, 07:35 PM) Xmit is sometimes the name of the transmit line on the serial port. Rolf Kalbermatter

QUOTE(orko @ Feb 21 2008, 09:34 PM) Cool down orko And yes if she doesn't know, who would. She created the whole IVision Toolkit after all! Rolf Kalbermatter

QUOTE(psufleish23 @ Feb 21 2008, 03:40 PM) File mapping should work for use as shared mamory in theory and did so in the past for me but: no, if you update the file instead of a mapped pointer to the file I don't think this is gonna work. Also you should not try to copy the name string for the MapFile but instead the returned pointer from MapViewToFile. Another suggestion would be to use UnmapViewFromFile and CloseHandle afterwards to properly close of all resources. Also as has been explained on the page you linked to access to mappedFiles can generate exceptions. LabVIEW has an exception handler around Call Library Nodes but that will popup an user error dialog. To handle those exceptions yourself you will have to create an external DLL as custom exception handling is not supported by LabVIEW. I would say go for UDP/TCP instead. Much more robust, remote capability built in and easy to do in LabVIEW. Rolf Kalbermatter

QUOTE(mballa @ Feb 21 2008, 11:43 PM) No! 8.5.1 is due sometimes soon. It's a bug fix release! But now please don't call those poor customer sales representatives for an update shipped to you. Because if you have an MSP you will get it anyhow and otherwise.... well we'll see if they put an upgrade installation on their web site for download. Of course if you don't have an MSP this might be the time to think about it again. Rolf Kalbermatter

QUOTE(orko @ Feb 21 2008, 05:58 PM) Very good point, orko! But our beloved crelf (I mean his ahem collegue) probably has his obscure reasons. Rolf Kalbermatter

QUOTE(Darren @ Feb 21 2008, 03:59 PM) A those double negatives!!! One should not assume :-) Well rereading it I see what you really meant, probably need to go to bed. It's been a long day. Rolf Kalbermatter

QUOTE(tcplomp @ Feb 13 2008, 09:19 AM) Ton you are right as far as LaVIEW's use of the socket library is concerned. But unfortunately it's not as simple as adding IPv6 capable sockets to the system. An application needs to initialize a socket with a network family before it can use it to tell the socket what protocols it should use. This is also for IPv6 necessary since the socket needs to be able to recognize the adress parameter for the network adress. For IPv4 this is a 32bit integer but for IPv6 this is in fact a 128 bit entity. As far as the LabVIEW nodes are concerned the only ones that need really some adaption on the Diagram side of things are the IP To String and the String To IP as they will need to support a 128 bit network adress. But for the adress string on those nodes as well as the various Open Nodes there will be some modifications necessery under the hood. They will need to regognize the new IPv6 adress format xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx as well as being able to resolve string adresses to IPv6 adresses. All in all not a very complicated addition but also not something you can just go and mess around with since you absolutely and under no circumstances can allow old functionality to break. Rolf Kalbermatter

QUOTE(Zerobite @ Feb 12 2008, 03:41 PM) It's not that trivial. The VI format is really a lot like the Macintosh resource file format. And that means the offset of particular information can be more or less anywhere in the file, depending on the order of how the resources were written. Admittingly if the VI was safed from scratch in a particular version, then the relative locations of those resources will be all in the same order, but for upgraded versions that is definitely not necessarily the case as new resources might get added during the upgrade and they may end up behind the already stored resources. However the other suggestion of using ResEdit on the Macintosh is probably not very likely to fly either. ResEdit expects the resources to be in the resource fork of the file, but since that doesn't exist on other platforms than the Mac LabVIEW puts its resources into the data fork. Also the LabVIEW resource format is very similar to the Macintosh resource format but it is not exactly the same. So even if you get ResEdit to pick up the data fork I'm not sure it could read that information without choking on them somehow. Also I'm surprised by Darrens suggestion that he suspects the file to not change much between versions. It's a binary format after all and even a single byte change somewhere is quite likely to be fatal when LabVIEW tries to load a VI. So no just changing the earliest possible LabVIEW version resource in a way is a quite likely case of messing up the VI so badly that it can not be loaded anymore by LabVIEW. Darrens suggestion however is also the only sane one in that respect. (Except of course the other ones like using source code control and such, but that is sometimes not very helpful after the facts ) Rolf Kalbermatter

QUOTE(NickyD_83 @ Feb 13 2008, 04:57 PM) The only thing I could think of is to write a shell extension to add this functionality to Explorer. And that would have to be done using COM and therefore C++ (although you could techically speaking do it in Standard C if you know your way around COM). Rolf Kalbermatter

QUOTE(ashwin @ Feb 6 2008, 07:09 AM) Sorry, I can't do much with that library. I have no idea why stopsampling would not work, but do think that you got something wrong with the parameter types despite you claiming otherwise. That or you are not initializing a parameter called by reference properly. The library is one big mess and 300% to complex I think. It could be done with just about 6 or so VIs and some helpers maybe. ActiveX is most probably unnecessary. Your use of queues seems not right and makes everything to complicated. But I can't see how to do it better, since I do not see anywhere the API prototypes of the DLL, nor can I see the VB code of the ActiveX DLL, nor do I understand the involved architecture of this seemingly simple driver. Rolf Kalbermatter

QUOTE(TG @ Feb 3 2008, 10:35 PM) Not just that. The average level of question is very basic on the NI forums in comparison with LAVA. And if you exclude the questions from a few very specific users on LAVA, you can consider the average level of almost every question to be professionel, and the answers as you say even more. On LAVA I often do not post since I don't know the answer good enough to feel I can add something. On the NI forums I usually don't post since I don't feel any desire to spend even one second in answering a particular question and knowing there are many others that will eventually step up anyhow. Rolf Kalbermatter

QUOTE(alukindo @ Feb 4 2008, 01:09 AM) Or you can usually put the column identifiers into square brackets to allow the SQL parser to recognize them as one entity. But not using spaces in column names is actually good practice. Rolf Kalbermatter

QUOTE(anima @ Feb 4 2008, 01:36 AM) What do you consider few data? And what is slow in that respect for you? How do you query it, row by row or as a result set? If it is really simple (a single row for instance) or you query them as a result set then the problem must be in the Oracle connector that the ADO Toolkit connects to and you will have to look for support from some Oracle centric support channel. If your result has several rows and you are not already using the method to query the data as result set try that first. When you say you tried with the Toolkits available for LabVIEW 7.1, what do you mean by that? The Database Toolkit from NI is at version 1.0.1 or something like that since a VERY long time and there was no specific release for LabVIEW 7.x or such. How does your VI to query very few data look like? A picture of the diagram or (God beware) a little VI would say 1000 times more than what you have told us so far. From the questions in this reply you do hopefully understand that the information you provide is still very minimalistic. Why do you think we should spend lots of our time to guess and second guess what your setup and specific implementation is, when you don't even take the time to sit down and consistently describe your problem as thorough as you possibly can? It is you after all that wants our help so doing some effort to get that help should not be to much asked. Rolf Kalbermatter

QUOTE(anima @ Feb 1 2008, 09:49 AM) My crystal ball is out of order, so I can't see what you did and why you think it is slow. Just try to explain clearly and if possible show us some code. There is a lot one could do wrong but without having more specifics everyone here is simply dabbling in the dark. Rolf Kalbermatter

QUOTE(vronto31 @ Jan 31 2008, 12:43 PM) I haven't used it with SAP yet but another company wide database management system called BAAN. This used to be a rather popular system here in the Netherlands but is going to get replaced more and more by SAP it seems. However BAAN was built on top of the Oracle database engine and therefore the Oracle ODBC access proofed perfect for what we needed. Don't tell your IT guys that you are using LabVIEW, just ask them how to access their system from any client application through either ODBC or ADO. Once you know the specifics such as what ODBC/ADO driver to use and what parameters to use to connect and query the database you can just go about it much the same as you did with Acess. Rolf Kalbermatter

QUOTE(Aitor Solar @ Feb 1 2008, 03:53 AM) I can only second that. It's an esoteric function enough that I would guess that people using it in such ways do know what they are doing and otherwise are prepared to live with the consequences. I don't see a LabVIEW noob even knowing that it exists , let alone using it. As my workaround for the LuaVIEW Toolkit shows, treating the refnum as a 4 byte number and copying it into the 4 bytes of a strict typedef VI refnum still works correctly. So typecasting refnums at least in LabVIEW 8.5 is still simply a datatype change but does not change anything in the underlaying memory representation. I did assume that it might have been in preparation for more significant changes to the refnum system in LabVIEW in the future, that might break with simple typecasting. But your idea that it might be more something about guaranteeing that a strict typedefed VI refnum points to something to be sure in memory might be also a good guess. Rolf Kalbermatter

QUOTE(Aitor Solar @ Feb 1 2008, 02:34 AM) Well, I see. It still might be a problem in the future, or the refusal to typecast to a strict typedefed VI refnum is maybe a bug?? Na, I don't think so. Rolf Kalbermatter

QUOTE(R.Alves @ Jan 31 2008, 08:12 AM) No for processing images later you would definitely need some image analysis library such as IMAQ Toolkit from NI or the IVision Toolkit from Hytek Automation. Rolf Kalbermatter

QUOTE(souske @ Jan 31 2008, 10:21 AM) No sorry. It's some time that a played with the LabVIEW Embedded Module, and that was with LabVIEW 7.1 too. Also I didn't incorporate any external code at all. Just played with the provided example framework for the Linksys WRT-54L router. But no I didn't mean the Code Interface Node or CIN. As I have written many times here and in other places, CINs are legacy and NI is not going to go into any trouble to support CINs on newer platforms. They maintain them on the platforms where it is already working but for the rest CINs are dead. If and how the Call Library Node can work on your system is also a big question. If there is a clear and well defined standard for shared libraries on QNX it is quite possible that LabVIEW supports it. But I never went as far as using external shared libraries for LabVIEW Embedded so I'm not sure how they would support that. It looks likely to me that this would have to be part of the extra code one needs to write to interface LabVIEW Embedded with the external toolchain, but on the other hand I'm not sure how LabVIEW Embedded would provide hooks to do just that. What I meant is that I think to remember that LabVIEW Embedded should have a C Code structure. It would sit on the diagram, look like a Formula Node and allow to type in C code that is then interfaced to the variables at the border. This C code will then be passed to the external C code compiler and of course could also contain calls to library functions present on the target system including your own shared libraries or object modules. I'm not fully sure that exists, never used it, but believe that I read once something about it. It is in that way much like the VHDL Structure for LabVIEW FPGA where you can write in VHDL code to be passed to the FPGA compiler. Note: Ok I read on the NI site about it and it is called there the "Inline C Node". Rolf Kalbermatter

QUOTE(souske @ Jan 31 2008, 04:32 AM) How do you get your QNX system to work with LabVIEW? To my knowledge there is no direct support for QNX by NI other than possibly through LabVIEW Embedded. If you use LabVIEW Embedded there should be the C code node (a bit similar to the Formula Node) that allows you to link to external code by writing calls to external libraries. Those libraries of course must have been created outside of LabVIEW with the toolchain for your target. How you do write these libraries and device drivers is entirely outside of the scope of LabVIEW. It does not care nor could it! So for your main question you will have to take it up with the QNX support people for sure. If you are not using LabVIEW embedded, the only way I see that your LabVIEW software could communicate with your QNX system would be a server application on the QNX system that access your Hilscher card and provides an RPC interface through TCP/IP for instance to your LabVIEW application. Only LabVIEW Embedded could possibly produce code that could directly run on your QNX target. But unless NI provides a ready made example for integrating LabVIEW Embedded with your specific hardware plattform and OS however (they obviously can't and won't create this for every possible target system out there), providing the necessary glue code to integrate your platform and OS into LabVIEW Embedded is a tedious job that takes up some serious time even if you are completely familiar with both your target plattform and LabVIEW Embedded (and if you are not, expect even a lot more time to be needed). Rolf Kalbermatter

QUOTE(Harvey @ Jan 31 2008, 04:20 AM) You sort of could write one, by converting a carefully selected timestamp into a string and then searching the specific positions and separation characters. The problem however is that this will never be able to solve all problems. This is because the DB engine and the according ODBC or ADO connector can or can not use the local date/time format on the machine they are running. I do know that the MS ODBC/ADO connector always observe the local format of the client machine and the SQL server can be configured to do that or not. Other SQL database engines will most likely have their own ideas about if and where to adhere to local format settings. There is supposed to be an ODBC standard format for date strings, but I had at least with SQL Server trouble to get that working between different computers. The solution in that case was to use the SQL Server CONVERT() function in the SQL statements to tell it explicitedly the string format the date was in. QUOTE Other problem is with the numbers point or comma '100,00' Converted into '10000' Same issue really. All MS ODBC/ADO client connectors will recognize the local decimal point. So for them you would use the standard LabVIEW formatting functions making sure "use local decimal format" is enabled in the Options, or using the Format Into String nodes add a %; to the beginning of the format string to tell it to use the local decimal fomat. Other database client libraries however may or may not observe the local decimal format. Rolf Kalbemratter

QUOTE(R.Alves @ Jan 29 2008, 02:28 PM) Duplicate post! Look http://forums.lavag.org/Package-for-Ip-cameras-t10006.html' target="_blank">here. Rolf Kalbermatter

QUOTE(Neville D @ Jan 30 2008, 03:49 PM) Which RT system has a GigE interface? Without it won't work anyhow. Rolf Kalbermatter