Rolf Kalbermatter

It's considered polite to put up a link for cross posts. Here is the same text again. It seems not possible to find any detailed specs for this camera on the internet. That means I can not even guess how to access them at all. But since it has a built in web server you can always access the images through HTTP. This could be either done through a IE ActiveX control or similar embedded in your VI front panel or by using the Internet Toolkit HTTP VIs to retrieve the image programmatically. OpenG has some rudimentary HTTP routines too, which should probably just work fine too. Rolf Kalbermatter

QUOTE(TobyD @ Jan 29 2008, 02:55 PM) And if the first is true I wonder if the name is just to try to get more likely help as a HH :laugh: Rolf Kalbermatter

QUOTE(R.Alves @ Jan 29 2008, 02:37 PM) Well, nice idea but there is a problem with that. There is nothing like a single IP camera communication protocol that I'm aware of. If a camera has the possibility to be controlled over IP directly it is sometimes RSTP or a proprietary protocol, that you can access through an Active X control only, and whose protocol is not normally documented or it contains an embedded web server that can be accessed through a web browser. For the proprietary protocol through ActiveX, you would have to integrate it through use of the Active X functionality in LabVIEW and this will be of course camera specific, and the second you could access trough the HTTP VIs that are part of the Internet Toolkit and of course are camera specific too, since the web server structure is also different on each camera type and sometimes varies between versions of the same camera too. RSTP is not very common and only really allows control of the camera itself, but is not the streaming protocol itself. If the camera supports it you can request with the DESCRIBE command an url from which you can retrieve the current image, which will be usually an FTP or HTTP url, and that can be handled with the Internet Toolkit. But considering the NON-standardization among IP cameras such a Toolkit will never be able to support more than a few specific cameras, so it will be hard to justify creating something like that unless you happen to have a specific application, and that means often that one develops them for a specific project and therefore can't just put it up for free download because of right of ownership. There is of course also GigE, which is a standard and I think NI is supporting that already. Rolf Kalbermatter

QUOTE(Tim_S @ Jan 28 2008, 07:53 PM) Why do sara and jennifer post quite similar requests here. I get this feeling that sara learned from the reactions and now got an identity change and tries to at least show that she did a little work before asking questions. Still!! Rolf Kalbermatter

QUOTE(Yen @ Jan 29 2008, 01:23 PM) It won't! The IMAQ Control is not really a fully built in Control but added to the LabVIEW system as an extra through external files. Those external controls do not support the object methods necessary to edit the control. And you can customize sub controls of normal built-in controls! You can't open a customize window for a second control when one is already open, but when there are editable sub controls (such as a digital control in a slider for instance) you can open that in a second editor window. I know from the original creator of the Control Editor that he considers that as a work that was done back at that time which should have been redisiged since a long time. One limitation was that that editor was not really reentrant for instance which made it necessary to disallow multiple editor windows being opened at the same time, except for the case of editing sub controls. Another limitation is that it is fragile at its best. Unexpected edit operations or controls that behave strange in some circumstances can make it go complete belly up together with LabVIEW and all your code. Rolf Kalbermatter

QUOTE(Yuri33 @ Jan 28 2008, 05:28 PM) It works in LabVIEW up to 8.2.1 but fails in LabVIEW 8.5. The typecast function will refuse a refnum connected to it with a broken wire. We found this in our LuaVIEW Toolkit package and had to develop a workaround for it. I sort of understand the idea behind, since a refnum is in fact something like a pointer to an object and messing with pointers can be a VERY bad thing. There is a chance that that new behaviour in LabVIEW 8.5 is in preparation of something that might change the refnum entirely and that might make the workaround we developed for LuaVIEW in LabVIEW 8.5 invalid again in a future LabVIEW version. Rolf Kalbermatter

QUOTE(PeterB @ Jan 28 2008, 05:43 AM) It means that the event structure might be serving an UI event at the moment the user event arrives and hence not be able to react immediately. A Read Queue waiting for an event to arrive will return instantly or at least as fast as possible, considering the contstraints of available CPU power and load only. Rolf Kalbemratter

QUOTE(macbeth @ Jan 21 2008, 03:52 PM) Why not show your VIs? Rolf Kalbermatter

QUOTE(crelf @ Jan 17 2008, 08:36 AM) This dialog should only be triggered when upgrading a pre 8.0 VI. So I'm afraid it is probably more a question of a corrupted VI somehow. For some reasons LabVIEW 8.5 does believe it is a pre 8.0 VI and applies that check but then stumbles over something else that is inconsistent in respect to this assumption. A bug? Well strictly speaking the bug happened either when saving that VI in 8.2 or the VI was corrupted somehow in such a way that 8.2 did not have trouble to read it but 8.5 has. It would be of course fine if LabVIEW 8.5 would just inform you of the inconsistency and continue instead of hanging, but there are miriads of things that can be inconsistent and anticipating them all is not very easy and checking them all is even less practical. I do think that technical support would be interested in this VI to be attached to the CAR so that LabVIEW development may look into the kind of corruption and maybe apply an extra check in the VI loader. Rolf Kalbermatter

QUOTE(silmaril @ Jan 10 2008, 08:26 AM) It may be that you have fiddled with the default fonts in your development environment. Check your LabVIEW ini file for entries like FPFont=, BDFont=, AppFont=, DlgFont= etc. When you change the font settings while you have some control or text setting selected the change applies to that control or text. Without anything selected the change applies globally and will also be written to the INI file if it is not the default setting. An application has its own INI file and by default no Font settings are in there which will cause LabVIEW to use default Font settings. The LabVIEW 8.5 Application Builder does copy some of the INI settings from LabVIEW.ini into an application specific INI File unless you disable that by specifying your own INI file in the build. But I'm not sure if Fonts happen to be among them, as I almost always use customer specific Font settings for Buiild applications. So no, I'm sure it is not a bug, but yes I do think the Font settings and default Font configuration could use some extra explanation somewhere in a prominent spot in the online help. And the Font configuration dialog could be more intuitive. The checkboxes for Panel Default and Daigramm Default are a bit hard to understand in respect to how they influence the INI file and future changes to a VI. Rolf Kalbermatter

QUOTE(ben5248 @ Jan 24 2008, 07:53 AM) Probably just a change in marketing. Those modules were introduced with cRIO but in the meantime are also usable with the new USBDAQ modules NI sells. So I guess they decided to drop the cRIO in the labeling to not confuse users. Rolf Kalbermatter

QUOTE(ashwin @ Jan 27 2008, 04:56 AM) Forget the queues for a moment. You want to call those DLL functions in a loop or something and test it's return value or it's returned parameter until it gives you the value to tell you it is ready. Then you call the function to retrieve the data or do whatever else you want to do. There is no way to use LabVIEW queues or such directly with the DLL. Once you have the DLL calls working properly you can of course develop a VI library that could give you a queue based interface. But I do not think that would have real advantages over a more direct VI library approach directly. Rolf Kalbermatter

QUOTE(PeterB @ Jan 27 2008, 06:34 PM) But they execute in a structure that also handles all the normal UI events that WILL switch to the UI thread for sure. And also might contain a timeout case that will also snoop some time for handling. ONe extra point. Queues are very specifically optimized to NOT copy data at all but instead use the reference to the data instead. User events might not be able to use the same optimization in all cases or even at all, especially if you use multiple event structures to receive the same event. Rolf Kalbermatter

QUOTE(ashwin @ Jan 26 2008, 09:32 AM) You can't. For a driver to inform you of something it must implement some kind of event notification. For DLLs there are two possible solutions, they can either allow you to install a callback function that will be called when an event occurres or they can use OS events to inform the caller about such an event. In any case these are things that are not directly translateable into LabVIEW events so you will basically have to write a wrapper DLL that calls your Device DLL with the event notification method that your driver uses and translates it into something more LabVIEW friendly such as a user event or occurrence. C programming knowledge will be required for sure to do that. Rolf Kalbermatter

QUOTE(Yen @ Jan 25 2008, 06:52 AM) Yen you are right here, but there needs to be some extra clarification since a LabVIEW refnum is a memory resource too, and I have trouble to believe that .Net will have any influence on the life time of that refnum itself, even if .Net has a very smart Garbage Collector. It may invalidate (but probably won't since the LabVIEW refnum holds a reference to the .Net object) the .Net resource that was referenced by the refnum, (and possibly though not for sure, the Not A Refnum node may be able to detect that too), but it most likely will not dispose of the LabVIEW refnum before the Top Level hierarchy that created it goes idle. So Your concerns are fully valid and Big Hanks claims are likely to be not the full story with using .Net in LabVIEW. Rolf Kalbermatter

QUOTE(Jim Kring @ Jan 7 2008, 08:18 PM) Well that last link talks about IStorage file format. So this would mean it is basically an OLE structured document format just as the older MS Office file formats. The difficulty about this is of course that the OLE structured document format only defines the container structure but not the actual contents in the streams. It's much like XML without any schemata. I'm not sure if chm is OLE structured document format but if it is, I think the description in that document is a bit limited. It may work most of the time but assuming that it will be always like this is going a bit to far. The actual layout concerning the different OLE streams could be changed by adding additional, non-standard streams to the document and suddenly the fixed offsets are not so fixed anymore. Rolf Kalbermatter

QUOTE(mballa @ Jan 22 2008, 10:31 AM) Hi Dan, welcome too. mbella: It's always so amazing what Google can do for you http://performancemicrowave.com/sql_LV.html' target="_blank">SQL LV Rolf Kalbermatter

QUOTE(Jim Kring @ Jan 21 2008, 09:10 PM) Not very likely for LabVIEW's UI widgets itself. Porting the existing widget code they build themselves since LabVIEW 2.5 on the various platforms to Trolltech would be a complete horror with many bugs, and functionality they simply can't implement on top of Trolltechs QT. It seems to be related to some of the configuration utilities that got added recently. There is a http://forums.ni.com/ni/board/message?board.id=170&message.id=276416&requireLogin=False' target="_blank">thread on the dark side about it, where someone had troubles with it since his external code (Surround SCM) was using a different version of QT that clashed with the one LabVIEW was using. Apparently the Multi-Variable Editor is the whole story why QT is used and that is in essence a DSC feature only. However as that thread shows the QT libraries are loaded into the LabVIEW process independant if the DSC system is used or not. Why they wouldn't write the Multi-Variable Editor as LabVIEW Vi is a bit beyond me though. LabVIEWs widget tools are quite up to par with QTs. Rolf Kalbermatter

QUOTE(sara @ Jan 21 2008, 04:43 PM) How about reading the LabVIEW manuals concerning LabVIEw controls, datatypes and especially strings and arrays? Rolf Kalbermatter

QUOTE(sara @ Jan 21 2008, 02:51 PM) Well you will have to store it somewhere. A poor mans choice would be a tab separated spreadsheet file to start with. Doing it more complicated would be nice but start out with something that you know you can do. Rolf Kalbermatter

QUOTE(tcplomp @ Jan 16 2008, 01:53 PM) This is no problem for the VI server. It can handle multiple client connections in parallel.There are some application properties (private I think) where you can monitor the connections and I think limit or even drop some of them yourself, but normally it can handle multiple connections. As to the original request, I'm afraid there is no way you can retrieve the remote address and remote port from an existing Application Reference. Injecting a VI into the remote side that you can then execute to retrieve the remote sides local parameters would be the only idea that I have. However I don't think any of the VI server stuff allowing to execute VI code that exists as a memory stream will be accessible remotely because of security concerns. So you would have to get that VI on to that computer in some way that requires physical access to it. Rolf Kalbermatter

QUOTE(tcplomp @ Jan 15 2008, 12:10 AM) That is a very good remark. As it seems to me Mikail has some sort of test application. This is in most cases the ideal application to use dynamic execution of the test steps as in some sort of plugin architecture. Also what I suspect is that he maintains the data in a front panel control/indicator or something through locals. If he would use shift registers, Request Deallocation would not have any influence since the shift register needs to maintain its data between executions. On the other hand shift registers allow programmatic clearing whenever desired. This means that for using shift registers which among other modern constructs like queues is the way to store intermediate data, Request Deallocation is getting rather useless. I feel that Request Deallocation makes no sense in 99.99% of the cases for a properly designed application. Rolf Kalbermatter

QUOTE(TiT @ Jan 14 2008, 04:18 AM) They do work but they do not return or modify the actual time in DST and non DST format but the current switch over time to start DST and end it. Rolf Kalbermatter

QUOTE(NateO @ Jan 10 2008, 04:34 PM) While VxWorks is used for the NI-RT targets such as newer Fieldpoint Modules or CRIO controllers I do not think you can just go and install any VxWorks OS and then use that from LabVIEW-RT. The RT OS on those targets definitely has been customized to allow LabVIEW RT to directly work with them. The other option that is more likely to work is the Pharlap OS. NI sells the LabVIEW Real-Time Deployment License for Standard PC's- ETS RTOS which is based on this OS. There you have official support to install a LabVIEW RT supported RTOS on your own computer hardware although there are some specific requirements such as for the network interface. The only other solution I see if you want to use LabVIEW is LabVIEW Embedded. But there you have to customize the environment to interface to the tool chain for your target system, if you dont happen to use a target that is already supported and I'm not aware of an already existing PC104 target. Rolf Kalbermatter

QUOTE(guruthilak@yahoo.com @ Jan 14 2008, 01:29 AM) You can but it is not a magical wand that makes your programs go faster or work better just like that. In fact it is likely it will make them much much slower. Request Deallocation tells LabVIEW to deallocate all memory that is not currently in use. And that will deallocate memory that a VI that is currently idle may just need 1ms later again to do its work so it has to allocate it again instead of being able to reuse it. Request Deallocation only makes sense when you have a VI that uses lots and lots of memory and only runs once or maybe every two weeks in the lifetime of your application. Doing a Request Deallocation right after executaion of that VI may (or may also not) improve the memory consumption of your application. Otherwise this function causes more trouble than it would solve, which is why it isn't very prominently made available. Rolf Kalbermatter