ShaunR

Ditto

Well. If "idle" has a plethora others (which I strongly suspect -how many?). I'd call it a mess But from the list I'd go for SM with event structure in the same sense that I'd go for a SM with an emergency stop, SM with foot switch and, indeed, any input stimulus to the actual state-machine. I know. 'twas a bit below the belt. Especially because there is a very good example of it in the SQLite examples.

I found a mass compile of the Labview directory sorted out most of this problem in 2009 and, generally, the 32bit to be a complete slug compared to the 64 bit - on a 64 bit machine. Mass compile doesn't do anything for 2010. It's still a slug on valium.

An event structure isn't a state machine Oops I forgot. You ab use it as one by firing off ValSig (Been known to do that myself on occasions....lol). But Linked tunnels work on it too

Not really off topic. The OP did ask about state-machines and what other people use. I'm with you on the sexually transmitted disease STD. I was generally referring to those that save a file using 20 case frames instead of just having "save" (because a certain tool makes it easy to do ). I've never found a need for more than 10 in control systems (well, I think there was a 12 once, but I eventually got it to less than 10). Simply because I do as you. The state-machine goes across the diagram and INTO the diagram (I think that's what you are saying). OK some state transitions aren't "kosha" (to get back the next level it might rattle through a few basically bypassing and doing a doing a NOP). But thats data-flow for ya. I actually find Labview pretty good for realising multi-planar machines where I equate each plane as a level in the VI hierarchy - Seems intuitive to me. Sure a few implementation problems. But much easier to debug a single branch in isolation than a fat, wide one with 100 states.

Simple? Define simple The IP address you can get using the function in the palette. The others (including the IP) you will find in the registry under "SOFTWARE\MICROSOFT\WINDOWS NT\CURRENTVERSION\NetworkCards". However the "proper" way is to call WSAIOctl with the SIO_GET_INTERFACE_LIST flag or it's .NET equivalent. (there's probably a WMI equivalent too).

Linked tunnels mean you don't have to keep wiring them through. But even without them, I would never have more than 10 cases (yes. I'm looking at you JGCode...lol) so it wouldn't be a big deal. I also don't generally hop over code. I wire through sub-vis as I like to only have only sub-vis in each case frame rather than raw code - much cleaner and gives you the opportunity to make them subroutines. Locals (and globals for that matter) I try to avoid since you cannot sequence them with error wires. If it doesn't matter about UI updating affecting performance, I prefer to use a property node (because of the error terminal). But that's nothing to do with state-machines But then, I'm me. And that's a bad thing

You think you've got problems with snow?

I'm no expert on .NET. I avoid it like the plague. .I think it is possible to get things like mouse-hover, clicked object etc (I've vaguely remember seeing the event). But I have never tried it. - perhaps someone else knows more. What I have done in the past though is to ensure the web page is "old-style" i.e very little javascript. This means that a button (for example a "Submit") causes the page to refresh and therefore once pressed, your DocumentComplete event fires again with the page refresh.. If however the page is mainly javascript, that doesn't necessarily happen as it's all handled by the browser.

I usually use shift registers. Normally 2. One for the control/status etc. And one for data. Local variables get very messy very quickly.

Win 7 x64 LV2010 x64. Change the socket parameter to a "pointer sized integer". it wont work if you are using lv x32 with a u64

This works for me:

If you set your TCPIP read function to "IMMEDIATE". IT will wait for the time-out period if nothing is received and return immediately if some bytes arrive. Alternatively. If you open your TCPIP connection using the VISA functions instead of the TCPIP functions; you can you can then use a property node to read the number of bytes at the port before reading. It will also enable you (if I remember correctly) to set different time-outs for the read and write functions. If you are using a native labview STM driver, you can always go in and hard-wire the time-outs manually.

This is why we need a project manager (read project/class/lvlib manager) that can nest projects like any other language can. At present, we can only include sub-components at one level down the dependent tree. This means that in your (and my) cases if your component also shares reusable code, that code cannot be used higher up the hierarchy (or so it seems). We have lost one of the big benefits of LV in that if a VI is in memory, it is automatically used (without winge-ing that x owns y or breaking VIs). If you want easily distributable (slim) components. Don't use the project manager or lvlib -. Use a VI tree.vi.

Me too. . I'm going to mod Dispatcher this weekend and have a play

Sweet. that's my (sad) weekend filled. A little food for thought to maybe kick off a discussion.....With a small spattering of ajax to show/refresh an image and detect where in the image the user has clicked, and you wouldn't need all the extra libraries and widgets and you can standardise the deployment (even via CDN) I think the real boon in websockets is purely for web browsers (not much difference for LV-LV client/servers). With a websocket, polling is no longer required and the server can stream data to the client. something that without websockets has always been a bit cumbersome and very limiting (requiring the user to refresh the page and use a intermediary webserver). My thoughts here are along the lines of Google Maps (but for VIs) where we can have an ajax browser API that "seamlessly" interacts with a LV front end - A remote-panel that is more effective and configurable (not to mention open source) than NI remote panels whilst being able to leverage already established technologies (KML, SVG and the like). No dedicated, pre configured servers. Just VIs and browsers. Wouldn't it be nice to just put a link in to your webpage to download the script from the NI CDN and, hey presto, your front panel appears in the <div class="NI"> tag with a websocket stream straight to/from your VI?

$SCALE ?\r

1. Where's the code then 2.FF4 and Opera are going to disable websocket support in future releases, over security concerns (rather foolishly). 3 Websockets are the future.

Yup. Sounds very familiar. You have remembered correctly. You have not attached the manual, but. Assuming MODE doesn't stand for something else (like a number) try setting the string control to "\" Codes Display and sending $MODE ?\n

Looks very familiar

Simple PID controller just set the derivative to 0.

Why not just pass the VISA com reference to a normal VI and just track the com reference instead of the vi reference.

Well. Assuming signal names out is being populated correctly. Right click on the case structure and make sure "case-insensitive" is checked.

OK. I'll get serious (just for a moment ). It depends on what you are trying to do. As far as I'm aware (under windows at least) there is no native labview way to "hook" a TCPIP connection. In fact, without a kernel level driver not many other apps can either (they use WinPCap). I know RolfK did a load with TCPIP which got into the nuts and bolts of TCPIP and UDP (they're on LAVA somewhere). But I only looked at them briefly - maybe something in there for you. If you just want to detect if something is active, you can ,however, just open the port. If it fails; "something" has it. Quick and dirty if that's all you need to know. The other way is as a proxy handler. Where, each end-point connects to ports in your software so you become the "man-in-the-middle". you can then pretty much do what you like with the streams form that point but you stipulate "without reading" so I guess that's out. Labview tries to alleviate the programmer from really low level stuff, so it's not surprising there is nothing "off-the-shelf". You are probably better off using wire-shark, logging to a file, then reading it in LV (I don't know if Wire-shark has an API or not).