Rolf Kalbermatter

As Michael said you can't really get a higher resolution than 1ms under Windows or any other Desktop OS. Under Windows and other Desktop OSes even specifying 1ms will seldom get you exactly 1ms delay but can vary with several ms and at least under Windows with a network card installed and one or more other applications running can sometimes exceed 100ms. You might be able to get a 1ms resolution quite reliably with a timed loop but for better you will have to go real time without any doubt. Rolf Kalbermatter

Are you sure the coef array never contains more than 21 elements? You index it before you error out if it would contain more! You can't just set the dimSize of an array without making sure it is big enough to hold that many information. Before setting the size you should at least use the LabVIEW memory manager function NumericArrayResize or something like that. Rolf Kalbermatter

Maybe if you would (re)install NI-DAQ they might be suddenly there? Rolf Kalbermatter

I'm not sure how C#, GDI+ and .Net apply to PDA development. I have a feeling that at least some of these parts are not available at all on a PDA target. Rolf Kalbermatter

You forget one thing here! People who answer your question here are NOT paid at all to do so and take the time from something else they may maybe just as much need to pay attention to. By making it unnecessarily work intense for us to give you some good answer you deprive yourself from many possibly good answers. If you think that this is alright then don't scream when your request hasn't been answered at all after 24 hours! By making an urgent signal you most probably annoy most people (it definitely annoyed me) and just get even further from your goal of getting a helpful answer. And that talk about ardour man and such, well I think you have no right to talk in such a way to someone like Chris. He has proven to give very useful answers to many posts here on LAVA and on other LabVIEW related channels and God knows where else, and I feel very much with his statements to your post and your defensive answers. If you don't want to understand this that is your cookie but don't ask me ever to eat it. Rolf Kalbermatter

Unless you happen to have linked explicitedly to a LabVIEW 7.1 VI to load the SCF file or even simply start the tag engine. I could imagine this to happen if your development project is on a different volume than your LabVIEW installation and with some carelessness when opening the project in LabVIEW 8 you are in that situation. Rolf Kalbermatter

And prompted by http://forums.ni.com/ni/board/message?boar...ssage.id=184494 I digged up one of my VI libraries IPtools.llb that happens to give you also some of this information and improved it a bit. Incidentially it does not use any .Net and therefore will run even under Win98 and NT 4 At least if you use some older LabVIEW version, of course. The lib itself is in LabVIEW 6.1 so there should be almost anybody able to use it. Rolf Kalbermatter Download File:post-349-1147472635.llb

There is a good chance that the dual boot would work and some virtualization solutions (but definitely not everyone) might work too. However don't expect anything other than TCP/IP (and maybe serial but that is doubtful) to work for IO. NI-DAQ (and probably any other NI-XXXX hardware drivers) is simply out of question. It plugs deep into the Windows kernel to access the hardware and that part simply can't be virtualized properly enough to allow this to work. Rolf Kalbermatter

In that case you should have taken the time to really explain what you are trying to do. If it is so important and your boss is chasing you it is even more important to invest some time on your behalve. Your original request could have meant anything and nothing and while I would probably have known an answer to what you were looking at, I was simply flabbergasted at what it might be that you would want to achieve and having only limited time at my hands I decided to move on rather than try to second guess your intended operation and write a lengthy response with the about 5 different possible things I came up your request could mean while reading your post. Usually it is much more productive to invest some of your own time upfront if you want other people to spend some of their time for you, rather than reposting and needing to explain afterwards in numerous reposts what you really wanted to achieve. And with a good explanation of what you wanted to do you could have gotten a useful response here as well as on NI Developer Exchange probably in a lot less than 24 hours! Rolf Kalbermatter

This is something that is not absolutely possible. As long as the device is on the same subnet you could use ARP to actually get at the MAC address but MAC address resolution is not done over subnet borders. Some devices may support a specific TCP/IP protocol to get that information from them but as far as I know, is the TCP/IP network not designed to get at this information outside of the own subnet. Any router in the network able to pass the packet to the destination address or at least another router that should be able to reach the destination directly or indirectly will simply answer the ARP request with its own MAC address, and when the packet arrives route it further according to its own route tables, replacing its own MAC address with the next one in the chain. Rolf Kalbermatter

This sort of devices are usually CNC controlled. While they nowadays have and use Ethernet ports to communicate between each other and the master control software, the used protocols are seldom public protocols and most often proprietary ones without any documentation whatsover. I have no experience with your machines but used to commuincate with Heidenhain CNC systems in the past for one project. Their protocol is called LSV2 and on the Heidenhain site I did find a document buried deep in the document hierarchy that usually does not show up in their normal search. I managed to develop a driver to get the file hierarchy and information on a machine over that protocol but even that document itself wasn't sufficient. It was not before I used Etherreal to sniff on the actual messages send between the official Heidenhain tool and those machines that I was able to write VIs to actually do a reliable communication. Without any document explaining at least the basic format of the protocol trying to develop such a VI driver is however almost impossible. So your first action should be to contact the manufacturer or distributor of those devices if there is a protocol documentation and if that fails try to investigate if somewhere on the internet is some protocol documentation available in the form of a document, some example code in C or another programming language or possibly some more or less obscure scripting environment. I've in the past had to learn a bit of Perl to actually get at some protocol documentation of some sort. Rolf Kalbermatter

wsock32.dll is the 32 bit implementation of winsock and that is the major provider for all network related protocols other than netBIOS. As such last time I checked it is just a normal DLL without any ActiveX involvement. In fact Winsock used to be a Microsoft port of the Berkeley network socket library, but according to Microsoft sources they have in the meantime developed their own code since they had an issue or two about not mentioning that they did use the Berkeley library in the first place, which is just about the only requirement you have to follow if you are using that source code in your own product. The Pharlap OS should come with its own implementation of wsock32.dll since this is THE interface to use under the 32 bit Windows environment to do any TCP/IP or related network access and LabVIEW will link to that library too for its TCP/IP and UDP functionality. Rolf Kalbermatter

Not sure what the problem would be. I can write a small demo VI that does the equivalent of rm -r / (obviously for unix ;-) and post it and anyone not being smart enough to check the VI diagram before executing it would be deleting his entire harddrive. So what? Of course this would be different if I hide the diagram code behind a password, but then it may be a good idea do know from whom you get the code before even attempting to run it! Rolf Kalbermatter

Since putty is a command line tool you will want to control it through its standard IO. This can be best done by redirecting its standard IO to pipes and communicate through them. LabVIEW for Unix platforms comes with a pipe library that allows to do this. I have attempted to develop a similar solution for Windows and made it available on OpenG. But it is still in Beta stage and probably has some issues but works for more simple solutions. It is not yet released as OpenG package so you will have to get the DLL and VIs from the sourceforge CVS server or its web interface at http://cvs.sourceforge.net/viewcvs.py/open...it/pipe/source/ Rolf Kalbermatter

By declaring "const array3* v;" you only declare a const pointer to the struct but do not allocate any storage for that structure at all. So when you try to dereference that pointer it points into nirwana and crashes. What you want to do is more along the lines of: typedef struct { double x, y, z} array3; const array3 v; double my_value; my_value = v.x; Which of course is still not very useful since v.x will contain some random data (usually 0 but not all compilers will initialize const data to 0). Rolf Kalbermatter

The most simple solution is to simply add the R, G, and B parts together and divide it by 3. This has however likely the effect of not exactly giving the result you would expect since the human eye sensitivity is different for the different colors. So you would have to weight the different colors accordingly before adding them. I think you will end up with weighting factors around 0.8 .. 1.3 for the different colors, but I haven't the exact information ready here. Looking on internet about color to grayscale conversion should give you the details easily and you may find that there are actually different weighting factors depending on your intended application. Rolf Kalbermatter

Chris has pointed out that the original only states an observation and doesn't actually maky any characterization. But to get back to your reasoning, it is actually not about mentioning Nazi or Hitler that is the bad thing, it is about using those terms to compare some perceived or real action of someone with it. Those words are very loaded and using them to compare anything with, is usually simply a way of trying to say someone is an a**hole without actually using the word. And as such extremely unpolite, totally uncalled for and most definitely not helpful in the bigger context of a discussion. If you want to talk about genozide, race discrimination and despotisme, then I do not see why you couldn't use Hitler or Nazi in that context but you shouldn't try to use them out of context for something else. Rolf Kalbermatter

For this you need a reference to the Block Diagram. Then one of the properties of the Block Diagram is "Highlight?". And this seems LabVIEW 8.0 only. So you will have to tinker with the Object Creator tool posted elsewhere on this board. Rolf Kalbermatter

I said BEFORE :laugh: and I verified it's before 7.0. So what you were experiencing is probably anothere issue. You can check the issue by typecasting the refnums into int32. If the value of a refnum changes between repetitive executes of the VI then it is a refnum that needs to be closed explicitedly in order to avoid memory leaks during execution of the VI. Note that LabVIEW does dispose of refnums anyhow as soon as the top level VI goes idle so if you are not creating refnums over and over again in a loop you are not exactly in deep shit, it's just not a nice and welbehaved application. Rolf Kalbermatter

Image processing on PDA is mostly like Formula 1 racing in an old VW "K

It all depends on LabVIEW versions too. Before 7.0 (or 7.1 I'm not exactly sure at the moment) it was imperative to close all references always no matter how you got them. Since then you need to close explicitedly opened references only but as a matter of good style closing all references anyhow properly is always a good idea. LabVIEW will know about those that don't need to be closed explicitedly and just execute a NOP instead of the close operation. This saves you the headache of remembering (or experimenting) what needs to be closed and what not. Rolf Kalbermatter

Not sure if it serves your karma well, to try to get him to pest other boards . But I've added an alfa filter to my perception already so not sure what you are replying to exactly. Rolf Kalbermatter

LabVIEW is highly parallel in execution. Unless you do not provide data dependency the execution order of code is totally random. In your case this means that the Read function can execute before the Write function is executed. In that case you never will be able to read the value you just wrote! Another problem is probably the amount of data you read with the count character! You typecast an int32 which will result in 4 characters being written and then you should read 4 characters too. Last but not least the serial port settings will terminate by default on carriage return on read. Since you are writing binary data the decimal 13 character can happen anywhere in the data stream and the default setting will sometimes terminate on that character on Read instead of returning all 4 characters. Rolf Kalbermatter

Not that fish & chips is considered top notch culinarian in the rest of Europe And the few times I've been to England and tried it anyhow to test if it was still true, I never was very much impressed by it. To soft and tangy chips! I mean it is usually eatable but not something I would make a trip for. For that I would need something lake Clam Chowder and of course in San Francisco Or should that be some delicius fish meal in Cairns? Of course the French and Italian cuisine is never to be forgotten and nice tasty spare rips in Austin are also great. Rolf Kalbermatter

Having done some work in Wine and knowing the structure of the Wine code a bit I have to say that having a full source installation of said has helped me quite a bit. Not necessarily easy to find a particular function if you do not know where to look for but about how to achieve a lot of things. Wine code is usually good structured and rather high quality so learning from there is definitely not a bad thing. Rolf Kalbermatter