ShaunR

Thanks for the input, but I'm unsure if this will work.

There is no written specs for this app, and I even plan to use in in a whole family of setups. That's why I dedicate a layer to the 'componentizing'.

One worst case estimate would be running the meaurement over the weekend at 500kS/s. With processing I get an estimate 1S/s (from literature, my processing is better, so I'll certainly hit other limitations; well they can be overcome as well and then ....).

But a hybrid solution could work, do the signal pre-processing with producer-consumer pattern and push the reduced data into the DB. Then do the physical calculations as a post-processing. The more I think about this, the more I like it to use a DB... I'll add it to the feature list.

Felix

I don't want to hijack Daklus thread.(too important).

I have to do acquisition stuff all the time. I used to do the classic acquire-process-display or producer-consumer. Now I just run acquisitions daemons direct to the DB and completely decouple the acquisition from the processing and reporting. Much more flexible and means you can swap reporting modules in and out (even while live acquisition is taking place) without having to manage the transitions or worrying about filling queues, memory or synchronising. However, direct streaming is only feasible up to about. 500 samples per second, reliably, without (as you rightly say) some intermediary processing and buffering. But that is part of the daemon so you don't lose any of the benefits.

I think your proposal would work extremely well since you can decide how much processing you want to put on either side of the divide (it could be staged and split).

The DUT is excited by n-channels. I only measure a single response signal.

Each of the excitation channels is modulated by a unique frequency.

Each of those n processing loops will filter out the response at one of these frequencies. Each of these channels will be also presented seperatly.

Ahh, things will even be more complicated, as I measure other channels as well, do the same kind of processing.

With all this data, now I'll do some physical calculations. Now I get some more data sets to present, both n-channel and 1-channel.

But I have a clear directional data flow, as opposed to a messageing system where the objects talk in both directions. So certain stages of the processing could be done better by traditional procedural chain wireing of vi's with some for-loops.

But then again this is tricky when it comes to the filters, as they need to keep the history of the signal. So I'll need to keep their state seperately for the different channels. Well, nothing I really want think too much about sunday morning.

Felix

Thats fairly painless with a database.

Log all the raw data to the DB. Make your filter re-entrant (notch/bandpass filter?).and just operate it on Selects from the database as many times as you like - in parallel with different settings. Any channel, any number of data points, any frequency - 1 re-entrant filter (simple case of course). Compare channels, cross correlate,,,you name it. You also don't need to keep state information or bung up your memory with a huge history.

Just a thought.

Just curious.......

In terms of code metrics. How much is framework and how much actually does something in the physical world (e.g read/writes from an device, updates a display, plays Mozart on a xylophone etc)

Any program needs it's infrastructure (of course). I'm just wondering what the trade-off is (you don't want to write 100 VIs just to turn an LED on/off for example).

You should start looking into OO programming :-)

Text Output Object

You could attach a callback to the status event and invoke your dialogue with the one of the status changes.

Here's an example of hooking the status event.

You might have to browse for the WMM activeX control again if you are using LV32 (I'm using x64)

I will say that I never run will the LabVIEW project explorer open, I really provides nothing for me

cheers

Ditto

Really? Then what do you call something that looks like this?

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.

Hey, that was one time, and...

I know. 'twas a bit below the belt. Especially because there is a very good example of it in the SQLite examples.

I'm using LV2010 on Windows XP (although I saw the same thing with LV2009). It takes at least 10 seconds after I drop a VI (and other things too) on my diagram before I can do anything else in LV. Is there some setting that will fix that. Is it maybe recompling every time? This is getting really old.

George

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.

Have you never responded to more than 10 events on FP and had to wire data through each case?

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

I agree with most of what you posted and tend toward keeping the number of cases low (in state machines) but the number is not the critical factor but rather the State Transition Diagram (STD) that is realized by the code. I suspect someone out there knows the theory behind it but the point at which STD get confusing is when it can no longer be drawn in a single plane, i.e. the transition lines have to cross over others. That is what I concider my "stop and re-write" point durring the design process. But before I let the diagrams get to that point I will start creating sub-STDs with a cohesive function and replacing the calling STD's code with the new "state". These are generally characterized by "single line in... single line out" structure in my STDs.

But that is off-topic now so I should stop.

Ben

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.

Hi

Is there simple way to get tcp/ip parameters (IP,Mask, DNS,WINS) ? I have try with netsh cmd, but it's a bit confuse for me.

Eric

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).

Is it okay if I disagree with you?

Dragging shift register wires from one side of a diagram to the other, having to hop over other code that may be in an event case (for example), now THAT gets messy. For pure mess-reduction, local variables are the best way to go.

But obviously it's not all just about mess-reduction, which is why local variables are generally used sparingly if at all.

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?

Hi Shaun,

Your Vi is very useful in loading the webpages.My next step is to click the button shown on the webpage. I know that I need to use some events like 'OnClick'. But I dont know how to use it with the functions inclusded in the VI. If I simply add onclick event- my labview crashes.

Or does the functions mentioned in the attachment VI support only for browser related events(whatever we in the property window)?

Could somebody help me...!!!?

Thanks for your time..!!!

Sharon.

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.

No luck for me. Still 1097. I'm on Win7 64-bit. You?

Br, Miha

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

I tried to make this work, but I always get error 1097 when calling recv. Did anyone manage to get this working? Here's my VI, if you want to try it yourself and maybe spot an error.

Thanks and br, Mike

This works for me:

Ok, I see that I will have to elaborate. I mistakenly thought my question was clear enough.

I have actually a TCP connection open in LabView, but I would not like to read from it, I would like to call some VI that would block (with the timeout set by me) until data is available. Then I will call another VI that will actually read from the connection and do something with the data.

Or to be specific - I am using STM, but STM only has one parameter. The timeout can be set when reading a message, but unfortunately this timeout isn't used only when waiting for the data. It also seems to be used internally. The effect is, that if I set the STM timeout too short (lets say 100ms), then STM stops working because the timeout is too short to compose the entire message. So the timeout needs to be larger, about 1000ms. But I don't want to wait for 1 second for a new message. I want to wait for it just for 100ms. If it arrives, I will read it, if not, I will do other things.

And since I don't want to modify the STM library and break compatibility with NI, I decided to look for some other function that would wait for new data without removing it from the connection. If the data comes, then STM will be used with its default settings to read the message.

I hope my intention is clearer now.

Thank you for any pointers, Mike

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.

The workflow I had envisioned, would go like this: someone checks out the Main project from source control. He then creates a separate project for his plugin (based on a template). He can then go and write his plugin, save the plugin code into his own version control, etc. However, the Main project doesn't change (the plugin files are not added to the Main project file), so I avoid having to deal with lots of commits from other people in the group.

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.

This looks awesome. Can't wait to play with it.

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?

Sorry, here's the manual.

I tried using the string "$MODE ?\n" which "\ display" format changes to "$MODE\s?\n" and selected the "query" button, but it just reads the same string back to me: "$MODE ?" I tried without the space and got (without the space) the samething "$MODE?"

$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

This is what I'm talking about:

Looks very familiar