ShaunR

Ok, now I understand it. So you have a sender task for each publisher (service) on the dispatcher side. Why not one for all? My dispatcher does all, registration, unregistration an sending in one loop, but each service has own receiver loop. I think this is the biggest difference between our realisations of this pattern. The second less difference is you use functional global variable for the client list, but I don't.

For all, I think it's very interesting pattern, which can be used for dynamic applications, where many publishers and subscribers can communicate to each other.

Thank you

Mainly load balancing and performance. The performance is dictated by the computers resources rather than the dispatcher. With the filtered method you have a congestion point that affects ALL "Topics" and gets worse by a factor of subscribers x topics as you add more topics.

Lets say (for example) you are sending 100MB of data on 1 topic which takes (say 10 ms) to transmit to 1 subscriber (we'll ignore filtering overhead). The Dispatcher is able to service all subscribers to that topic every 10ms. If we now add a subscriber to that topic. The time to service all subscribers is now 20 ms. 3 subscribers...30 and so-on. Now we add another topic that also takes 10ms to tx 100MB of data to 3 more subscribers (keep the maths easy). The time now required to service all 6 subscribers on both topics is now 60 ms. 3 Topics, 90ms.......

However. with the service handler, each service handler is only handling 3 subscribers so in our theoretical example, each handler is servicing all 3 of the subscribers every 30 ms still. Increasing the number of topics doesn't change the time to service all clients. So whereas before the time to service all subscribers was a compound of the number of subscribers AND topics. Now it is only the number of subscribers.

Additionally, whilst the dispatcher is servicing the clients, it is effectively "deaf" to incoming connections which also gets worse as you increase topics and subscribers. Having the dispatcher only handle connections means that this "deaf" time is not dependent on the number of subs/pubs. You can use a queue as, I have, and build a list of connection request but you then have to consider the trade off between handling data or handling a connection request. With significant network lag you can get halts in the data whilst the dispatcher is creating a connection. In my example, the Dispatcher only handles connections (its very responsive to connection requests). Therefore the dispatcher can take as long as is necessary without interrupting the data streams.

I was able to get the original file zip that you posted yesterday. I able to open it again, run it, it works then I close it, try to open again and the error comes out.

And then I try to create my own programs based on your VIs diagrams, it works but when I open, the error comes out again.

But let me try your VIs diagram that you just post, I think there is something different from your previous VIs. I will let you know if any progress.

By the way, thank you for assisting me here.

Yes you are right. Apart from adding the "Dispose" I also removed the conversion from an image to an array (and visa versa) as I indicated in my previous post. Although I don't think it will solve your problem (but we can hope )

Yes, it was lost after updating LAVAs software (I think). Here you can download my version:

http://labviewportal...hp?f=19&t=9#p19

Sweet. I'll take a look!

But, sorry, I don't see where you send your data from one publisher to many subscribers. TCP/IP is one to one connection, so you have to send your data twice if you have two subscribers. I can't see any for-loop in TCIP Write.vi.

Indeed. That's where the "Disp Service Handler.vi" comes in.

This dispatcher uses a similar method to a web server where each incoming connection is negotiated to a different port and a process is spawned to handle that client. However. This spawning only happens for the Publishers. If you look in the Registration part of the Dispatcher you will see I dynamically launch the service handler (whos front panel is hidden). The publisher writes to the service handler, not the clients and the handler deals out the data to the clients. There is a service handler for each publisher and when a subscriber wishes to connect, the Dispatcher sends a new subscriber list to the handler for that service.

Very cool indeed. Usually things like this can be found out by using the highlight execution but this one does nothing.

You can however find the wires by when the mouse changes to a pointer. (to the left of the wait function is one) Odd that it hides the wires but still allows you to select them by clicking them, but not by going to Edit >> Select All.

Indeed. Also If you cut and then paste back again, it will reveal the terminals. 'twas just an idle moment whilst rummaging around the script stuff. But in doing so I did find also that using this "feature" I could remove the thick border around terminals and variables which was one of requests from the idea exchange.

Is it because I'm using version 8.5?

I read from NI forum tells the errors comes from 8.5 bugs, so I need to move on version 9.0 SP1. Is that correct? I haven't try yet, so any other opinion?

It's difficult to say why. But as NI have reported this as a bug in 8.5 for loading vi's saved to a previous version then its likely to be the case.

As you were able to load it the first time.I would suggest you over-write the vi from the zip. Then reboot to make sure memory is clean, and open the VIs again.

You should now be in the same position as when you downloaded the file originally (hopefully).

If you are able to load the VI again, save it to a different location so that it is not a "converted" vi. Hopefully by doing this whatever the issue is with loading converted VIs will be removed.

I have also posted the VIs diagrams below (they aren't difficult). It would only take a few minutes to re-write them.

x86 for me:

Running 32-bit LV2009.SP1 at the moment.

x86 32-bit or 64-bit?

I have both installed under win7 64-bit. It takes about 15seconds just to launch 32-bit LV. About 5 seconds to launch 64-bit LV. Disk IO is particularly sluggish using WOW 64

[LV2009]

Whenever I open an installer build spec, that is for a med + size app, I have to wait ages for the dialog to appear, then wait a bit more for it to become editable.

(Way more than for a executable build spec, and sometimes that takes a bit)

Sometimes I find its easier to edit the XML directly then to wait, (off the top of my head, I can't remember 86 being as bad)

Its like its doing a bunch of checks, but nothing really changes between opening it from the last time.

I am talking minutes... ...anyone know why?

Cheers

-JG

You running LV x32 on a Win x64?

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