Leaderboard

A quick look at the html source shows me it's old-school HTML, not XHTML. That 'X' is very important as it implies the content would be valid XML in addition to HTML. The LabVIEW DOM functions operate on the XML DOM, be it XHTML or any other XML, and demand valid data structures. If you want to parse (non X) HTML you'll probably have to do search and replace string operations. Either that or work some sort of browser engine into your code which can interpret HTML and allow you to operate on the HTML (not XML) DOM.

According to my tests on AF this behavior is normal. AF is just not the fastest messaging framework that can be implemented in LabVIEW. It has two components that make is relatively slow: Uses priority queues. It makes sending atomic messages(messages with little or no data content) about 2 times slower. More on this: https://decibel.ni.com/content/docs/DOC-24589 Uses dynamic dispatch. Once per message a dynamic dispatch VI is called. It has an overhead and it makes atomic messaging 3 - 8 times slower. Read more on this: https://decibel.ni.com/content/docs/DOC-13709#comment-31559 Please don't take my numbers seriously as accurate measurements, but approximately these are what I measured at least on my PC. If you read all the links you will understand the reason for AF being slow. I think you can get some speed by leaving out priority queues and use normal queues, but I see no immediate solution for the dynamic dispatch problem. I have a similar system in work, and what I do is to use as much data in a packet as my GUI's refresh rate requires (so for a 1kHz signal to achieve 25 fps you can send arrays of 40 data points). I see that you use this trick for the Controller, but use it for the Hardware actor also.This way the user still experiences "real-time" behavior, but you spared with messages. Hope it helps a bit. [this reply was first posted on AF forums, as I didn't notice the discussion already started here]

I don’t know where the bottleneck is, but you’ll have problems pushing 50k to 200k messages per second between actors. For display operations you should definitely have a flush queue in there somewhere, so updates can run at a slower rate than arriving messages. If you do go with a shared reference, I wouldn’t use a DVR; instead share a data queue like the one you use in your Plotter Actor Core. Create that in Plotter and pass it by message to Hardware. Then you have a direct, low-overhead stream that you flush a few times a second. — James BTW, I don’t know the details of you application, but I would be tempted to make basic plotting of raw data a feature of the Hardware Actor itself.

Interesting task, some VIs are missing though (from your user.lib), but I get the critical part now. As far as I know there is no way to pass a delegate from LabVIEW to a function (as there are no raw delegates in LabVIEW). Also, even though the parameter is called 'asyncCallback', it is not an event callback, but just a parameter you could pass (any?) delegate to. The delegate could be registered as an event by the caller. I searched the internet and found a similar topic: http://forums.ni.com/t5/LabVIEW/How-do-I-configure-NET-SOAPSender-AsyncCallback-in-LabVIEW/td-p/284364 The first answer states: I think this is still true. The only option I see for this is to write your own wrapper that internally handles the delegate and provides an event for LabVIEW to register to. Of course you would also have to wrap the method you want to call in order to provide a method without the delegate parameter. I'm quite sure I've seen a similar topic here before... I guess...

I've seen people add LabVIEW to their resume with less experience then that.