ShaunR

List of bug fixes in LV 2011

New crash reporter But it definitely feels more responsive than 2010.

I guess it won't help then. Rolfs got a point, but immediate really puts a burden on the CPU since you've got to (wo)man handle characters as they arrive. Then concatenate and terminate the loop on whatever it's supposed to terminate on (number of bytes or term char). This is the sort of thing: As you can probably see from the snippet. there is a (small) possibility that the first 4 bytes are garbage or maybe you read 1/2 way through a string and therefore expect a huge number. So are you using character terminated or pretending a payload size? You haven't said much of the inner workings. Example perhaps?

Well, that's not a huge amount. Even the default LV examples should be able to cope with that. The default windows buffer is 8192 (if I remember correctly-don't have the getsockettoption....maybe later in the week). There are a few ways of calculating the optimum size dependent on the network characteristics, but I usually just set it to 65356 (64K) unless it's a particularly slow network (like dial up). It really makes a difference with UDP rather than TCP (datagram size errors). Note, however, that it only makes a difference if you are setting the "Listener" connection. It has no effect on "Open". It''s strange that the C program doesn't exhibit the same problem. If you are doing the usual write size, write data then you can try and combine it into one write operation (just concatenate the strings) but I haven't run into a problem with the former. If you have the C code then you can take a peek to see if they are doing anything fancy with the sockets....but I doubt it. Are you trying to send and receive on the same port? (Cmd-Resp) or do you have two separate channels; one for sending and one for receiving. If the latter. What part disconnects? The receipt of the data or the send of the data (or arbitrarily both) and what is the error thrown (66?). If you get timeout errors on a read, then you should see that in the network monitor (task manger) as drops but you say that it "lopes" (had to look that one up..lol). That's normally indicative of a terminated messaging scheme where the terminator gets dropped for some reason..

What sort of throughput are you trying to achieve? You could try and give LV a bit more time to service the TCPIP stack by increasing the buffer size.

Ooooh. You like living dangerously eh? .

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