Bob W Edwards

I used AutoIT extensively to automate test reports in Word, cutting and pasting tables and graphs from the EMC test software used to control our emc lab. However, I suspect automating Labview controls and indicators requires a more special technique, see this article. This comes from the book Practical Laboratory Automation published by Wiley.

This recent article reviews 10 automation tools, the key feature you need seems to be support of Windows UIA. If the Automation system comes with a Spy tool, then that makes identifying LabView controls and indicators easier.

Bob, retired EMC engineer, ham radio callsign G4BBY

It's the old dilemma. If you rely on one or just a few pieces of software to make a profit annually, how do you get people to buy it over and over again, especially after twenty odd years? I suggest that unless, we the users, ask for features we would really find useful, then there is the risk that the void will be filled with less relevant stuff, to help promote this years version. Making 'loose coupling' and 'tight cohesiveness' more concise seemed like a good goal, given that NI is bound to keep adding the bells and whistles year on year.

So, very interested to see Jeff Kodosky's GLA 2020 presentation on youtube on A Visible Actor Framework. I hope it gains traction, as it would do much to lower the 'difficulty curve' when attempting to write large applications. Simple reusable actors where OOP is optional, not mandatory, would be great.

Aristos,

Thanks for the insight into the status of Actor programming within NI. The case for building Actors into the language would have to be compelling given the amount of work involved. I was just curious to know if a more elegant feature was imminent. For now I'll continue with Messenger Library in my little retirement project (a software defined ham radio).

Bob G4BBY

This question aimed at NI: There are many frameworks some stable and others still emerging for building an application from messaging Actors - which is great. They all of them suffer from one overriding issue, that of being more complex than one could wish for. One of the basic aims of LabVIEW was to allow non-programmers to achieve their goals with a minimum of fuss. None of the existing frameworks can claim this, so the user stays focussed on the application and doesn't get diverted by the complex syntax.

Is it likely we'll see a baked-in messaging Actor feature with a simple api in LabVIEW sometime? OR are we better off continuing to refine the above frameworks for a little while longer?

Regards, Bob (Being retired I use home LabVIEW at the moment but looking forward to the free community edition next year)

The signal path in my software radio is a complex number double waveform at 96ksamples/s in a range of buffer sizes of 1024, 2048 - 16384 set to suit the users needs. Highest CPU load is with 1024 sample buffers, where a buffer needs to run through the dsp to the speakers every 10.666mS. My prototype receiver uses ordinary LabVIEW queues to transport the data between soundcard daemons and the dsp vi.

Should I message the signal path around the place or should I stick with normal queues and message all the rest? Currently the desktop computer loafs along at 7-10% cpu load, but the target tablet is higher at maybe 30% so I'm mindful of not increasing that if it can be helped.

I guess the answer is really to try it and see!

Cheers Bob

I've added the 'JSON based config load / save' to one of the Actor templates which is working well - the top level Actor ends up with it's config data + that of all subActors and subsubActors and so on in it's internal data - and back the other way too, to initialise controls and internal data. A few questions relating to config file storage preferences:-

1. Do you make top Actor do the actual file save / load or are there benefits in having a dedicated Config subActor take care of that (and maybe more)?

2. Where's the accepted location for such config data to go these days in Windows 7 onwards? I don't want to use the registry.

3. How best to manage configuration of an app whose subActor population can vary from run to run. My software radio needs to support a number of different hardware platforms so will load driver Actors to suit the hardware chosen. The user will want the configuration he's chosen to reappear next session. I guess the subActor responsible for loading the hardware drivers has a little more to do than blindly sending JSON config 'down the tree'. The data may not match those Actors currently loaded.

Using Messenger Library so far - good fun.

Sorry, I may have busted the link in the Wiki by editing the programmer's notes above. Could you fix it again and I'll leave it alone ? 

Bob

Good idea, go ahead.

Dr James,

I'm learning Messenger Library to see if it suits a software defined radio retirement project. To remind me of the basics, I've made a 47 page programmers note. It's free to you if that's useful, otherwise I will keep it private. 

Any luck with LibreOffice 5.0.3.2 ?

I'm only use 32 bit Windows for now - I guess that means LibreOffice, the SDK and LabView were all 32 bit.

Best regards, Bob

Just trying the 'Uno_test.vi' example on Labview 2014 / Windows 7 / LibreOffice 5.0.3.2. Having trouble right off with error code 1172 from the 'Bootstrap' invoke node in  'Create Factory' vi. This is being fed with a .net reference set to 'uno.util.Bootstrap'. If I try and create a similar node, I don't get that resource in the drop-down list.

Sounds like I haven't installed or set all I need to with LibreOffice. What did you install and set (paths etc) on your computer please?

I'm interested in this because I wrote a small test executive that uses Excel for all data storage. I got pretty good creating my own Excel interface and would like to add LibreOffice support to that. I'd attempted to do that via COM but never got it installed right / LibreOffice doesn't support COM - I never fully fathomed that out.

Regards, Bob