ShaunR

This is NOT A SCAM. We need to do something before an "Eruption of the Yellowstone Supervolcano Destroy the United States as We Know It". Is ALGOR available?

Wouldn't bother me

Although it's a bit worse than that because its an extinction level event. In that case It just means I'll die a few months after those in the US And those in Australia a little after that.

But if things work out right it might counter Global Cooling when they decide thats the next money maker and companies are paid to pump CO2 into the atmosphere

And here's the events version (stealing JCarmodys boolean logic ).

The advantage of Jcarmdys is that it works anywhere on the screen whereas the events version only works on the FP of the VI that has the code. The events versions only advantage is that it is a little more efficient in terms of CPU.

The really old way (before events, queues etc) might be easier to visualise.

It used 2 global variables (data pools). The UI would write to one of the globals to configure and control the acquisition and all the acquisition stuff would write to the other to update the data in the UI. (Completely asynchronous. Non blocking and damned fast - not to mention built in system wide probe..lol) So the UI was completely decoupled from the acquisition spending most of its time just polling the UI global to update the screen.

But basically all it means is removing execution dependency between the UI an other parts of the code usually via an intermediary interface. The inverse I would imagine would be something like a sequence structure with the acquisition in the first frame an the indicators in the last frame.

This is going to be painful . Not so much that you are re-factoring code (many of us do that all the time). But you are switching paradigms so it's going to be a complete rewrite and you won't be able to keep perfectly good, working and tested code modules (even the worst programs have some).

But the good news is. There will still only be 1 person that understands the code only it won't be the other guy

I usually find one of the hardest initial steps is where to start. I strongly recommend you don't do it all in one go, but rather use an iterative approach. Identify encapsulated functionality (e.g a driver) and rewrite that but maintain the same interface to the rest of the code (to begin with). This way you will be able leverage existing test harnesses and, once that module is complete; still be able to run the program for systems tests. Then move to the next.

At some point you will eventually run out of single nodal points and find that you need to modify the way the modules interact to enable to realise your new architecture. But by that point you have gotten over the initial learning curve and will be confident enough to make much riskier changes whilst still having a functioning application.

The big bonus of approaching it this way is that you can stop at virtually any point if you run into project constraints (run out of time/budget, another project gets higher priority, you contract a serious girlfriend etc) and still have a functioning piece of software that meets the original requirements. You can put on the shelf to complete later but still sell it or move it into production or whatever you do with your software.

I'm still waiting for the 2009 SP2 Go Paul.

I don't have LabVIEW 2010 installed so I can't open your VI, but I've found that you can only edit cells that already have text in them; you can't add text to new cells. You also have to click in exactly the right place at the right time in order to edit cell contents. I prefer to use a table control if the user needs to be able to edit values. If you want to be fancy about it, create a table indicator instead and add a few individual controls for different data types. When the user clicks on a cell in the table, get the cell location (the table control has a method for this). If the user is allowed to edit that cell, make the control appropriate to the datatype of that column visible and move it to the the cell that was clicked. When the user finishes editing the value, copy the control's value into the appropriate cell in the table and hide the individual control. It takes some work but you can build a very nice-looking interface that lets you mix and match datatypes in the same table, and also have some columns that can be edited and others that cannot. With more work you can have the tab key operate properly, moving from one column to the next. Here's an example of this from one of my applications; the first column is values from a Ring control that is populated at run-time, the second column is a floating-point value, and the third column is an enumeration. The remaining columns are calculated and populated as the user fills them.

Thats what the MCL should be as a control (your picture) without us having to jump through hoops and use hacks to emulate proper controls.. It's about time NI stopped faffing with blue sky stuff and put more effort into the core stuff that's been needing development for the last 5 years that everybody uses (controls, events, installer, more integrated source control support (svn, mercurial) .... et al.)

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.