ShaunR

Hmmm. If that is true. How is it reconciled with the events of front panel controls which surely (neck stretched far) must be in the UI thread. I could understand "User Events" being able to run in anything, but if bundled with a heap of front panel events; is it still true?

Where do they run then? In the execution system of the vi properties?

Indeed. Events have been screaming for an overhaul for some time. I'm not sure, but I think they may also run the the UI thread which would make them useless for running in different execution systems and priorities (another reason I don't use them much....just in case). I would also add to your list being able to feed VISA sessions straight in so we can have event driven serial (pet dislike of ine )..

There's lots of info on the SQLite API For Labviews performance here. There's also a lot of the development history too since LAVA was its birthplace.

This sound like a more polished/advanced evolution of the Dispatcher in the CR (I like the use of events here although I ran into issues with them and decided TCPIP timeouts were more robust). Many of the features you highlight here (like auto-reconnect, system messages, heartbeat etc) I've been meaning to add along with a more bi-directional architecture (although the version I have in my SVN also has control channels as well as the subscriber streaming channels). But on the whole, your stuff sounds a lot more flexible and useful (I'd love to get a peek at your error detection and recovery )

That is really what events are for. However. I have a dislike for them since they cannot be encapsulated easily and maintain genericism. There are a couple of other options though (with queues). You can peek a queue and only dequeue the message only if it is for it (has the downside that if you don't dequeue an element-it stalls). Or my favorite of each "module" has a queue linked to the VI instance name. To close all dependents, you only need to list all VI names and poke (enqueue at opposite end) an exit message on all of them (just a for loop). This becomes very straight forward if all queues are string types and just compare (or have a case) to detect EXIT,STOP,DIE or whatever to terminate. Some people however prefer strict data types. But I think you are right. In the absence of events, notifiers are the next best choice for 1 to many messaging. I think that most people prefer to have one or the other rather than both in a loop though. And if a queue is already being used, it makes sense to try and incorporate an exit strategy using it.

I'm probably in the minority here (again ) but you don't need a software tool-chain to create an architecture. You are only using the LabVIEW IDE as your editor instead of (say) Microsoft word. The NI exams are specifically designed to be challenging in the time frame provided. However. If people feel the architecture for these fairly simple systems require a tool-chain just to realise it. Then perhaps the proposed architecture is over-complicated for the task (KISS).

Or just supply a marker and we can draw on other peoples T-shirts.

I use +-3 standard deviations from the mean (or zero) to set a dynamic threshold for peak detections of varying signals.

Well. A quick search hasn't revealed any drivers others have written. It' seems to be a USB device so you have 2 options. 1. Write a labview USB driver from their documentation (very hard and time consuming) 2. Use their toolkit to write a high level Labview Instrument driver (I'd go for this). Either way. Unless someone has already done the work or, the manufacturer has supplied some, you will have to write an interface and option 2 would be the fastest and easiest, but still time consuming. Their toolkit it seems to encompass two flavours. DLL based and active X. Personally I would go for DLL based but that is only because I hate active X with a vengence. It specifically states Labview 5.1 (..gulp...) and they have examples, so you could start by hacking and modifying those.You won't be able to use LV5.1 VIs if you are using a LV version grater than 6 or 7 (I think) so lets hope they have more recent versions.

Nothing clever. If your device doesn't echo then you just pre-pend the command string. But the main problem has been solved, simple and took me about 10 mins (Note I am using the term char to only update the display once a whole string has been received) -->The property node in the read loop us really a local variable. It gets converted when posting a snippet. You could put the read vi(s) straight after the write (after the event structure) and it would work fine most of the time and be fully synchronised. But since you don't want the UI to look unresponsive whilst waiting for data; asynchronous reading is generally preferred. State-machines come into their own when you have multiple states that can be operated in an arbitrary order. So where you might want to use one is, for example, when a response from the device dictates the next command to send.e.g authentication challenges. But for most implementations where user interaction is involved,. then an event structure is preferable since all user interaction is handled for you.

There are alternative methods such as sending the data via queues and using a database amongst others. It really depends on how fast (what is the acquisition rate?) and how fresh he data needs to be (would the user really see if data was delayed 100ms as long as it was continuous). Besides. There are not enough pixels on a screen to represent 20,000 data points, so you don't need all of them to display to the user. Of the two choices you have given, I would probably go for the global with a single write and limited readers (data-pool). That is the old method before things like queues/events and doesn't limit you to running the acquisition in the UI thread. But queues are the most commonly used since they also break the coupling between the UI and the acquisition and are very efficient. There are some examples shipped with LabVIEW that demonstrate this technique for waveforms.

Receive in a separate loop. The Event structure is your "command" loop and the receive loop is the "response". And for extra brownie points; do all of the commands with 1 write vI.

Don't normally go in for this sort of thing....but Front slogan: Class - Simplified Rear slogan: Simply Class Or maybe thr other way round..

Use an event structure and just send the heartbeat in the timeout case (wire a value to the timeout). Your commands will map to an event case, so just send them in the appropriate case. That will achieve what you want with very little effort and you can always pull it out into a more elaborate approach later, (you will still probably use the event case for the UI regardless). A state-machine seems a bot overcomplicated for your current spec.

Confirmed (2010 x64 Win64). No problems on 2009 x64/x32 on win64. Fantastic sleuthing to have tracked that one down.

Was the assembly tested on a windows box with a Chinese or Japanese localisation? My first thoughts with Asian-only issues are the problems (and Labviews issues) with Unicode string handling. The problem you have (as Rolf is saying) is you have a black-box that is't happy and no way to tell why it isn't happy (Labview can only tell you it isn't happy). Presumably the author of the assembly has a test harness of some description. Can you send that out to China and see what error log it produces (if any).

Firefox can also be used. FF4 is shipped with web sockets disabled but it can be enabled from the config page Enable Web Sockets For internet explorer you need an additional (experimental?) plugin which isn't really any better than NI's approach and a real pain since it is still the dominant business browser. IE web sockets plugin

Yes. Absolutely. All the VIs you have downloaded are based around uploading the firmware to the PIC. If you have this already then once you have programmed the PIC with the USB commands that you want it to respond to you can use the LabVIEW serial comms VIS (VISA) to communicate as if it was a normal serial port (see the simple serial example shipped with LabVIEW). See here about using PICS with virtual serial ports.

I'll reiterate. DLLS are for the windows platform. So no. It won't work. there are 2 aspects to using pics. 1. Uploading the firmware (bootloader and your program either using a PIC programmer or specific software). 2. Communicating with the firmware once you achieve No1 (usually as a serial port) To achieve No1. You have to use the toolchains supplied from the manufacturer (I use HiTech as it happens) or some open source equivalent. The VIs you are downloading are merely wrappers around the manufacturers API for communicating with their PICs that are "blank" so have no USB support as you would consider it. (LabVIEW is not a PIC programmer). Lots of people have windows and microchip supply the DLL for windows and some people have written the wrappers to use this DLL for uploading the bootloaders and firmware rather than using one of the myriad of other tools people have written.. For the MAC they (Microchip) would need to supply a "framework" or dylib which would enable you to do the same on a MAC with LabVIEW. Maybe this page on PICs with the MAC and Linux will help.

Good video. This is basically how all my software works.

I've never experienced this problem so this is a wild guess. But spurious issues in "ini" files can be a symptom of excessive path lengths. Try deleting the line for "RecentFiles.pathList", "NewDlgRecentMainTemplates.pathList" and the quikdrop ones.

DLLs are for the windows platform. If you are using the MCHPFSUSB, I've never seen Microchip support for the MAC, but you never know.

Ok. Just for you I mean a Multicolumn List Box (which is a table to a simpleton like me ) rather than a Table Control. So yes you are right a "Table Control" does work. Not all table-type controls do though.