ShaunR

Ah yes now that you mention it I see what you mean about doing all the SQL queries yourself with the SQLiteVIEW toolkit. Anyway I'll send a query off to them to find out what are the advantages (if any) of using their package of the SQLite API - maybe it has better performance or something - thanks.

Chris

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.

• A multi-connect server and single-connect client that maintains persistent connections with each other. That means they connect, and if the connection breaks they stay up and attempt to reconnect until the world ends (or until you stop one of the end-points ).
• You can have any number of TCPIP-Link servers and clients running in your LabVIEW instance at a time.
• Both server and client support TCP/IP connection with other TCPIP-Link parties (LabVIEW), as well as non-TCPIP-Link parties (LabVIEW or anything else, HW or SW). So you have a toolset for persistent connections with anything speaking TCP/IP basically.
• Outgoing messages can be transmitted using one of four schemes: confirmation-of-transmission (no acknowledge, just ack that the message went into the transmit-buffer without error), confirmation-of-arrival (TCPIP-Link at the other end acknowledges the reception; happens automatically), confirmation-of-delivery (you in the receiving application acknowledges reception; is done with the TCPIP-Link API, the message tells you if it needs COD-ack), and a buffered streaming mode.
• The streaming mode works a bit like Shared Variables, but without the weight of the SVE. The user can set up the following parameters per connection: Buffer expiration time (if the buffer doesn't fill, it'll be transmitted anyway after this period of time), Buffer size (the buffer will be transmitted when it reaches this size), Minimum packet gap (specifies minimum idle time on the transmission line, especially useful if you send large packets and don't want to hog the line), Maximum packet size (packets are split into this size if they exceed it), and Purge timeout (how long time will the buffer be maintained if the connection is lost, before it's purged).
• You transmit data through write-nodes, and receive data by subscribing to events.
• Subscribable system-events are available to tell you about connects/disconnects etc.
• A log is maintained for each connection, you can read the log when you want or you can subscribe to log-events. The log holds the last 500 system eventsfor each connection (Connection, ConnectionAttempt, Disconnection, LinkLifeBegin, LinkLifeEnd, LinkStateChange, ModuleLifeBegin, ModuleLifeEnd, ModuleStateChange etc.) as well as the last 500 errors and warnings.
• The underlying protocol, besides persistence, utilizes framing and byte-stuffing to ensure data integrity. 12 different telegram types are used, among which is a KeepAlive telegram that discover congestion or disconnects that otherwise wouldn't propagate into LabVIEW. If an active network device exist between you and your peer, LabVIEW won't tell you if the peer disconnected by mistake. If you and your peer have a switch between you for instance, your TCP/IP-connection in LabVIEW stays valid even if the network cable is disconnected from your peer's NIC - but no messages will get through. TCPIP-Link will discover this scenario and notify you, close the sockets down, and go into reconnect-mode.
• TCPIP-Link of course works on localhost as well, but it's clever enough to skip TCP/IP if you communicate within the same LV-instance, in which case the events are generated directly (you can force TCPIP-Link to use the TCP/IP-stack anyway in this case though, if you want to).
• Something like 20 or 30 networking and application related LabVIEW errors are handled transparently inside all components of TCPIP-Link, so it won't wimp out on all the small wrenches that TCP-connections throw into your gears. You can read about most of what happens in the warning log if you care though (error 42 anyone? Oh, we're hitting the driver too hard. Error 62? Wait, I thought it should be 66? No, not on Real-Time etc.).
• The API will let you discover running TCPIP-Link parties on the network (UDP multicast to an InformationServer on each LV-instance, configurable subnet time-to-live and timeout). Servers and clients can be configured individually as Hidden to remain from discovery in this way though.
• Traffic data is available for each connection, mostly stuff like line-load, payload ratio and such.

Cheers,

Steen

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 )

Ok, I'm getting this feeling that I'm kind of missing the point here and probably being hopelessly naive, but...

Isn't the two parallel loops exactly what notifiers were invented for ? Ok, yes they're lossy, but if you are just using it to stop two parallel loops and you know the last message every to posted on the notifier is the 'stop now' then it doesn't matter surely ? The problem surely with any queue based design is that you're stuffed if someone else grabs the queue and takes your message - or if you want to stop N loops in parallel where N is only known at run time.

What would be handy for multiple loops distributed over indeterminate numbers of parallel running vis would be a one to many queue with priorities - so that you could enqueue an element with an arbitrary priority and have that element delivered to multiple waits and have the elements presented to the wait sorted first by priority and then by enque-timestamp. Thus each dequeue node could pull entries safe in the knowledge that it wasn't affecting any other dequeue node, could choose to discard elelemts if it wanted, but would process them in an order determined by the enquer that wasn't necessarily FIFO. Nut I don't see this is necessary for the stated problem...?

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 would be happy with the following change - any free for commercial use code (i.e. free, not just trial mode) software that can be downloaded from the LabVIEW Tools Network should be allowed in the CLA exam. It is really frustrating to experienced developers when they can't use their standard tool-set (and one that is ultimately managed by NI) on the CLA exam. It definitely takes critical time away from creating an architecture when you are compelled to recreate architecture components (or even their interfaces) from scratch, especially when you already use them every day.

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).

Look, if it's going to be weird, shouldn't it say this around under the armpits? Or over the shoulder?

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.

Hello again, I have been away due to exams but now I am working very intensively on this project again and I need some help (again).

My problem is that the control of my Multichannel Analyser (ORTEC's ASPEC-927) cannot be done through TTL pulses after all and I have to find a way to do it through labview. I have been searching a lot in the internet but all I have come up with is either a publication "LABVIEW-BASED MCA EMULATION SOFTWARE FOR ORTEC MULTICHANNEL BUFFERS" or some reference to ActiveX usage for such a task. All I need is to trigger the counting, stop it and input the data in labview. If someone has knowledge on the matter, I would like to know what is achievable and what is not. I have no knowledge of ActiveX programming whatsoever by the way.

ps.I haven't found anything relative to the communication of labview with Maestro 32 which is the default software provided with the MCA card nor "reading" the .chn output files from labview so I assume it is out of the question.

thank you in advance

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.

The toolkit has two options for programming. For programmers familiar with Dynamic Linked Libraries (DLLs), it provides DLLs

and supplemental Windows applications programming interfaces, which can be called from C, C++, or Visual Basic. For

programmers using ActiveX Controls, all the functionality can be accessed more conveniently through ActiveX methods,

properties, and events. The ActiveX capability makes it easy to program the ORTEC products from LabVIEW (Version 5.1 or

later), Visual C++, and Visual Basic. Simple example programs are supplied with both programming options.

thanks for the response, I had already taken a stab at just throwing in a second loop like you did there, except i used "bytes at port" feeding into a case structure where 0 does nothing essentially and default does the read, which works as far as talking out of the serial port like i'd like, but the problem i'm having is syncing the trace window on my FP. in your example you just have the reads showing up in the read buffer indicator, but I'm trying to have the Tx echo in the same indicator also. That's where I was thinking originally i'd need like a qsm or something, unless there is some clever way to echo a write to "read buffer" in your bottom loop in the example you posted.

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.

Thanks, for the tip, but if i put my heartbeat in the timeout event, where should I be monitoring the port for received messages? I would have just put a short timer on the timout event and listened for bytes at port, and wrote them to my terminal as I saw them, is there a way to create a "bytes at port event"?

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..

Hi everyone, I'm new to the board and pretty new to labview. I have a simple serial messaging protocol. I need to create a tool that will essentially be a terminal tool with buttons that will send out 5 or 6 manual commands. The commands have start character and end characters. It will also need to send a status message at some interval and be able to send the same status message on demand.

I was thinking about using a state machine for this, however the adjustable rate heartbeat message and how to handle that in statemacine is kinda jamming me up and maybe i'm trying to be too cute or am just going down the wrong path in general. also searching around i was unaware of visa events, would this be an appropriate use of visa events for the message reading or am i better off just inspecting each byte and acting accordingly?

any tips would be appreciated.

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.

Hi Rolf - thank you for the reply. The C# programmer tested the DLL pretty thoroughly, including downloading LabView 2011 and making sure LabView could call the DLL. That test passed at the development site in Mexico. But when the developers in China tried to call the DLL they get the error. I'll forward your comments to both teams (in Mexico and China) and if they have any questions or comments in response, I will post them here.

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 and Opera disabled websockets. Server-Sent Events is still enabled in Opera.

You can enable websockets in Opera by going to the following url "opera:config#UserPrefs|EnableWebSockets" then scroll down and save the changes no restart needed.

Websockets can be enabled on Opera Mobile with the same url as the desktop version.

They both plan on bringing back websockets when the security problem is fixed.

It looks like Google and Opera are working on it. http://www.ietf.org/...t/msg07296.html

Also you might want to use BufferedRendering for SVG, it helps speed things up.

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

Maybe i wasnt explaning my self or i could be wrong so hear i go i understud that dll or not sopported by mac, Im doing a DAQ hardware and labview is my controler in software is there a way where i can use my pic on mac to comunicate to labview to send and recive info thanks sorry for my bad spelling..

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.

Hi i found this files on a other fourm to be able to call the pic from labview can any one tell me if this could work on mac im still trying to make my project work cuz all i have is a mac and realy hate windows thanks.

DLL in labview

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.

If you take a look at this awesome video tutorial I posted on my VI Shots blog. You can see an example of using reentrant VIs to create multiple user interfaces that look the same but handle different data. It doesn't contain any classes but it's a small change to add classes to this design pattern.

Click here to watch the video.

Good video.

This is basically how all my software works.

I don't see what is problematic, so any idea is welcome.

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.

Hi to all im trying to make my demo board i found in this page Ston10.com and trying to connect it to my Macbook but it dosent soport the dll file given by microchip it says error the file you selected is not a valid library, can any one help me thanks ill send the VI im using.

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.

No, more like details -> Tables will default correctly using the IN (you said they wouldn't above).

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.

Not fool-proof is exactly the problem.

However the API is quite interesting. Any chance you have a pre-2009 version lying around? (8.x would be nice!0

Wow. For once LabVIEW didn't crash when saving to a previous version.

I need to get the HW serial number from the chip. I have seen posts about it and some talk about example code, that's why I thought someone in the LV sphere could have already done it.

I flirted with it a while back (its on here somewhere). The issue is Admin rights. I never got around to revisiting it.

Yes! I kept reading over and over on LAVA about this wonderful thing called "plug-in architecture", finally researched it, and discovered it was something I'd been doing for quite some time -- I just didn't know the fancy name for it. I will admit to some concern over potentially being stuck by not knowing "correct" terminology when/if I ever get around to taking any of these certification exams.

Perhaps we should design a BS Bingo game for LabVIEW

Get that on the LabVIEW Idea Exchange! Unless it already is, and in that case: link me to it!

I don't know if it is there or not. I don't visit the NI sites much any more since it kept asking me to verify my details-so I don't bother now. But we have over a year to argue about it before it is likely to be considered

That is not quite correct.

Tables will be cleared (or rather, set to Default) using that IN as their datatype is a 2D Array of Strings.

Combo-boxes have a String datatype so that will Default the 'selected item' (which is what the datatype refers to) not the actual list data in the combo-box which is persistent and accessed through e.g. Strings[] PN.

IMHO this behaviour is expected and should not be changed.

Well. We are about to argue about semantics.

I didn't say what it should do, just that I find it irritating that it doesn't and pointing out that if the OP uses it, it probably won't do what they (and I) expect for those controls.

Note that this invoke node will not clear tables or combo-boxes which I've always found infuriating