ShaunR

Wow, It's work ShaunR.

Thank you very much.

Sweet. Those old USB drivers should be taken off the NI site.

I've just noticed I forgot to "Dispose" the IMAQ image reference. Not a big deal in this case

but this is how memory leaks start.

like the Event Structure or the IPE or OO -- are not common user requests.

I think you'll find that a way of handling Events was being called for for quite some time. Not necessarily an event structure but a way of handling UI events as all the other visual languages could.

Well, my specs usally say:

10. software: customized software wirtten in LabVIEW.

Yep, no more. And I can live with it. The customer hase to design the feature (write more detailed specs) and at some point I can say 'that's out of scope/budget/...'. This seems to be a completely different situation that NI has, but in parts, it isn't.

Once I have a feature completed and go on to the next customer, all change requests are pure cosmetic.

Well, both situations are completely different. So I try to put it in a much higher abstraction level.

I think that a correctly working software only gets (by request) two kinds of additions:

* new features (so completly new from the scratch, as add-on)

* cosmetic changes (like a cancel button on a dialog)

and this mechanism is user (customer) driven.

but seldom (never)

* improving a sub-feature (performance optimization, Edit->Create SubVI)

* adding a subfeature (e.g. support for abstract classes in LVOOP)

Because this can only be judged by the developers and sometimes the power users; never management or new customers (-> marketing).

Felix

Were a bit off topic. But I'm going to steam ahead anyway since I don't think it'll last long otherwise I would have started a new thread.

We must have the same customers . Its pretty much what I get (initially). Only my approach is for me to write the spec over a series of sit-downs (hand-holding). That way I can include stuff in the spec that perhaps they hadn't considered, but important to their operational situation (back-up and data storage is a common one they overlook). It also means I get a very good picture of the customers "minds-eye" of what they expect the system to be like. I usually also try and get one of their technical people to be actively assigned to the project then you get out of a lot of the "status reporting" 'cos thats his job

Your thoughts about what constitutes a change (and therforre the customer incurrsa cost) is identical to mine. However, you sneakily said "correctly working software", which, is normally the bit that starts arguments. And it needs to be extremely well defined right at the start of the project what and how testing will be done by both parties to ascertain its "correctness". I would go 1 further and say "correctly working system! I take the (some may think draconian) view if its not working "correctly" then its not completed and therefore not released to the customer (expecting customers to do alpha and beta testing is a cop-out). V1.0 is the first time a customer will get the system and Its very rare you will find an up-issue that is a bug-fix release in either software, hardware or mechanics.

Make sure that your camera is working properly in Measurement and automation explorer.

It should auto-detect your camera and In the main window area you can press "Grab" to make sure you get an image.

Use this for capture instead (I've saved a version in LV 9.0 and 8.5)

This I can test an works fine (no flashing, fast frame-rate @ 640x480)

I make pretty complex measurement equipement and I'd like to have the customers questioning the 'though stuff' (how do you implement error propagation, what about the PID controller, how is your internal messaging system designed ...) but in 99% of the cases I get 'I want a cancel button here', 'I want a plot legend there' and I want a 'comment field in this dialog'.

That's because it doesn't matter how you did it. As long as you did it on-time, on-budget and to spec.

Reminds me of a cartoon I once saw where there was a really long paragraph of an engineer explaining how they did something (he was chuffed to bits). The other man said "Yes. But does it work?" To which he replied "No"

Is there any particular reason you didn't use LVOOP for the transport code? This is a natural candidate for a hierarchy of classes.

You make it sound as though thats a good thing

Hi ShaunR,

Thank's for your advices, but the first is still blinking but not fast as the previous one. Is there any other solution?

And for the second, if I remove wait ms. The client side not display any image from the server side. So I decide to reduce the amount from 500 to 160 and it works but the display is not smooth really. Is there any other solution or advice what should I do?

Thank you.

I can't actually run your code to try things because I'm running windows 7. Maybe someone else might have more luck installing it.

But. Try something like this.

Make a copy of the image and transmit the copy.

Hi!

Nice made, did you just seen this one http://lavag.org/top...ish-subscriber/ ?

Seems to be almost the same thing

Regards, Eugen

No I didn't Great minds think alike eh?

You talk about it being in the repository, but I'm unable to find it. Maybe it was lost along with the "The Great Crash" since the posts seem from quite a while ago. I wouldn't mind taking a look. Do you have a link?

The initial idea was born out of being fed up with writing similar things every time I worked with a new company. Although with this incarnation I wanted a more generic nature by removing a lot of the infrastructure dependency (which probably isn't that visible.....yet;)) and have the ability to cluster rather than rely on a central server (i.e. filtering). That way I can transparently use a distributed architecture. It is really just a multi client/server tracker. ( I also wanted a viable light-weight alternative to DCS. )

I see you also talk about "Topics" which suggests (to me) a single server with segmented data filtered for the particular subscribers (classic pub/sub). I think mine is more content-based where each "Topic" is in fact a dedicated server and after registration or subscription, the Dispatcher has little to do with data.

The IMAQ USB library is ancient.. It was a quick fix before Measurement & Automation explorer supported USB and has many issues such as memory leaks and and the installer has issues with win7.

I strongly suggest you use the measurement & automation explorer first and use the image libraries to interface to it.

However.

To stop the blinking you could try selecting "Synchronous Display" by right-clicking on the image indicator and selecting "Advanced>>Synchronous Display".

If that fails then you are probably receiving incomplete/corrupted packets or you are timing out, reading nothing and then updating the display..

The second one is so slow because you have put a 500ms wait in the loop and a receive time-out of 500 ms.Remove the wait ms and use the default time-out (i.e don't wire it)

Perfect. That did it. It also helped with seeing the menus on the toolbar.

George

Sweet.

Did you find a visibility attribute for block diagram nodes? You should have saved this for April.

I'd have forgotten about it by then

No probs - just my luck!

Thought I'd warn others tho.

I saw the diagram before I closed it.

So where did you get it? Or did you script it yourself?

My own creation.

I thought if /f I really must go to all the effort of downloading, installing, activating and navigating the script stuff. I might as well have some fun

Sweet!

I just opened the VI (which is set to run by default) and when I closed it, it crashed my LabVIEW (2009)

I had a project opened too.

Thanks!

Ouch.

Sorry.

Isn't meant to. And I tried it in 2009 x32 and x64 and had no problems.

My 2009 is known for sudden fits of crashing like just deleting stuff off the diagram. Try again?

Diagram looks like this:

http://www.screencast.com/users/Phallanx/folders/Jing/media/6d33f01c-4961-4c88-9944-e3290ab349a0

Remember.I'm not the one promoting a "Design Pattern". I'm only prepared to spend as much effort in discussion as you are!

Yes, grab it from ni labs

And to clarify the challenge, make a sub-VI that takes an array of GObject references input and converts both constants and control terminals into indicators

Why don't you just send me your code and I'll mod it.

Ok then, replicate the code that I have that can handle changing both a control to an indicator and a constant to an indicator.

How many cases would you need for that w/ the string based implementation?

Well. For controls ........none. Since I wouldn't use any of them. I'd use something like this:

I can't remember off-hand how to get th BD reference (cannot seem to find it in the list). I'll have to dig into my old code

for a refresher example (is it only available if scripting is installed and activated?).

Still seem to be missing some dependencies. Of note, I'm getting complaints about MessageQueue.lvclass, Message.lvclass, and ErrorMessage.lvclass.

Seems neat though, can't wait to look more into this!

You need to first install

lapdog_lib_message_library-0.7.0.1.vip

which has that class

Hi Eric

I certainly have been following your work (and with Ton too).

In fact, in the readme above you will see I included you in the acknowledgements (and made a mention in video).

I did see your code where you save the VI but I did not want to do that in this case, or handle new-VI (unsaved) case.

The reason for this tool was that I wanted to speed up my workflow when I insert a state.

This was probably the thing that takes me the longest to do.

Do you have any ideas in mind for other tools with respect to JKI State Machine?

Cheers

-Jon

Maybe worth exploring. But if you edit the case name after insertion (say insert a space then delete it). The broken arrow disappears.

Shaun, I agree that having the Class Available in the case selector would be better and maintain the robustness and flexibility of the pattern, but that requires a new type of stacked frame structure in LV to exist outside of a feature request

It was a trivial point but I think it improves readability immensely. And (probably in the minority again....but) I will choose readability over elegance if performance is not impacted..

No, I'm saying w/ the design pattern, you don't have to make a special unique case for the XYGraph at all because the cast to WaveformGraph will not fail.

But I want it to fail. Because it means I have given due consideration to an unexpected behaviour and therefore is a part of the designed behaviour. In the absence of similar behaviour in other classes, I almost view this as a NI implementation oversight (and therefore all methods more of a bug fix) rather than a design pattern to be used generically for accessing objects. In most cases (where things are as they should be) it's a performance hit since the probability is that you will be trying invalid cases before stumbling onto the correct one is high. If all t saves is 1 case. Then I see no reason to switch from an accepted, proven method to a shiny new method that may have performance hits and is (slightly) less readable. You'll have to give me more than that

(What are the benchmarks comparisons like out of interest? If you don't have time, post an everyday example and I''ll do them)

But as you've seen, not all common properties in class trees are common

All are as I'd expect EXCEPT graphs.

Excuse me?? What?? Um, U B mistaken sir. XYGraph is a child of WaveformGraph

Excused!

Indeed I was. (It was late/early is my excuse and I'm sticking to it )

But my point (perhaps explained better after the sleep) was that I didn't need to create a case for EVERY class and subclass. And my memory from over 11 months ago, was that I didn't have t deal with subclasses. It turns out that was because of the consistency of implementation of the property node (In fact to handle any control in PassaMak only required 4 cases. So that's only 1 more than you have above.....for all of 'em)..

You give me far too much credit sir.

Working in the tower has it's perks, but not the midas touch of LV wisdom.

Although easy access to the 3rd floor is damn nice.

Well. Get banging on the floor, tool up your Pikachu with an Uzi and tell them to sort the Graph class out

SO.... this gets to the heart of your argument and the weakness in my example.

I stand by my example as a good simple case of showing why the string based operation fails and if someone was trying to make some generic code for waveform graphs they would easily miss the XYGraph case and need to go back and re-code

Well I didn't miss it. And I didn't miss digital graphs either

But. The string based system doesn't "fail". If you hadn't thought about the waveform graph or waveform chart, yours would "fail" too. I'm looking at the graph example and all I can see is that you are replacing a nested case structure with an iteratively nested case structure. Perhaps I need a different perspective?.

BUT!!! Where this code really shines is while doing LVScripting, where you end up with an array of GObject often and need to operate on a variety of types which a common ancestor with the needed functions can not be assumed or found.

EXAMPLE:

Hmmm. Now I see no difference between the "string" based system and this one apart from the "string" one will always do it first time, every-time (if it can) but this method has to try a few different ones before either it hits one that works or it runs out of options. Same number of cases because there is no common denominator and each operation has different properties and methods.

It seems to me that the graph example is indeed a one-off scenario where you save 1 case.

By all means, keep using the 'Class Name' based selection of your code, but I believe you will find that, although it potentially meets your needs immediately, you have introduced a point of weakness into your code that unnecessarily would need modification to handle cases not originally though of. But why would you?

How can you handle cases not originally thought of? If that were possible, you wouldn't have to add the extra cases because it can handle stuff you don't think about Moreover. If you haven't thought about them,how do you know it will handle them correctly?

(Wavey lines, Soft fade.....)

Many moons ago, in a galaxy far, far away. We used to use a similar approach for instrument identification. The SCPI spec was fluid and manufacturers all had their own way of identifying their device (to some extent that's still true today).. So we would have a list of all the ident commands for all the instruments we supported and try each one in turn until either we ran out or found one that worked Sales called it "Auto-detection". We called it the BFI method (Brute Force and Ignorance) . It was slow and cumbersome and with hindsight, didn't obtain the holy grail of "future proofing" that many believed. It also had a really annoying habit that if a customer happened to stick on an unsupported device that had the same ident command. it'd make them think it was compatible but fall over because the rest of the command set wasn't the same. Eventually, we decided to make it a maintenance issue and that if they swapped out a device for a different one they'd just select it from a drop down list, It was faster, cleaner, easier to maintain and also meant that "if it 'aint on the list, it 'aint getting in".

Does this have anything to do with The "Any Cast Design Pattern"? Probably not. But but I'm having flashbacks

Do you want to be friends?

OK. Added:D

I agree, that they should not sold as major upgrades. (unless warranted).

But I don't think NI was promoting the 2010 release as: individual ideas = individual major features.

IMHO the major feature was the Idea Exchange itself and how NI has a strong (web based) mechanism in place for collecting customer feedback that is cycled into the product releases.

The new changes were just evidence of this.

At the end of the day, we (the customers) voted for (most of) those features - democratically speaking.

Indeed. The really astounding (is that the right word?) aspect of it is that NI REALLY DO listen to thier customers and the changes are the evidence.

Allright I voted, however I think that NI should not only implement the easy ideas from the Idea Exchange.

Basically all the ideas implemented are 'low hanging fruit', I would be ashamed to name those new 'changes' as the major upgrade feature (as NI is currently doing).

Ton

Oh, I don't know. I think some of the changes are really useful (like clusters as control-type icons). But they all seem to be cosmetic changes. So whilst I like the idea of a cleaner diagram, I would (as I think you are suggesting) prefer to see the more meaty ones implemented that enhance the program rather than the prettiness of the diagram.

Or maybe that's a sign in itself. That we are having to spend too much time making diagrams "look" good instead of making functional code.

But I think Aristos' suggestion is an excellent one (and long overdue). I use it a lot and it would save be bags of time.

I'm in the same boat as jgcode so I'll have to create 3 more accounts and hire a medium

Having slept on it (after all wise words from NI are never to be taken lightly). I thought I'd better to refresh my memory.

Unfortunately I seem to have remembered correctly (what? No crying emoticon?) as this works as I would expect

However, Plot color isn't available, yet it is still common to all plots.

Which brings me back to the summation that you have really highlighted a problem of inconsistency of the property node for waveform types since this also works.

So. You don't have to create a case for every class and subclass. Only the parent (if at all). Apart from some properties of waveforms (there maybe others but waveforms are the only one I've come across).

I think NI should offer a discount to female attendees.

Naaaah. I think they should supply them

Functionally I don't think it's any different, but there's a HUGE difference in readability.

Really? Its easier to read 0,1,2,3... than WaveFormGraph, WaveformChart, XYGraph... ?

(Personally I really dislike nested case structures. The logic is too hard to understand at a glance. If I can I'll usually execute all the logic tests, put the results in a boolean array, convert it to a number, and wire that into the case structure. Then I drop a comment explaining the logic. It's much easier for me to check the code that way.)

I find nested case structures abhorrent. I must admit I didn't even consider the nested error example a solution Even a case structure with many cases causes me to look for an for an alternative. Its the same argument as Sequence Structures. If the case number is small (<6), I'd much rather use a select so its all out in the open. For more then I will try for strings unless its numerical in nature in which case I will do the same as you.

Oh, and without going back and watching the videos again, what was the first word Norm said on all four of the videos?

ummmm. "So"?

You did not see what happened with the XY graph did you?

Thought I did

You would have to account for EVERY possible child string.

EVERY CLASS NAME.

If you had some VI that had a GObject come into it's terminal,

you would need to manually enter the 'Class Name' for EVERY Class Name of EVERY child class that you wanted to handle.

You mean the difference is that instead typing in the class name you wanted to handle you, would just "Copy Case" and change the cast constant instead?

If GObject was the input and you wanted to do a bunch of operations on all, or even a subset, of numerics types,

you would have to figure out every class name possible,

and then type it in perfectly in the case selector,

and then hope and pray that NI doesn't release another item in the GObject tree that now your code won't work with.

Not really. Because unlike graphs the a property node accepts all the numeric classes for the common properties.

It's all about Scalability, robustness & re-usability. You do not get that w/ the string

Certainly waveformchart,waveformgraph and xygraph don't have child classes. Neither do boolean, cluster etc

Numeric types are consistent (whether they be a U16, DBL, slider, knob,gauge or whatever) since all the common properties can be wired to the same property node. The graphs, however (I think) are the exception and it is only because the property node doesn't allow it (which it should) means that you have to handle them differently. I found that out when writing PassaMak.